User Defined IO Rules

Proposal Details

• Who Updates:Main.KevinCameron
• Date Proposed:
• Date Last Updated:
• Priority:
• Complexity:
• Focus:

Current Situation

The keywords in, out and inout currently bid to ports, but the behavior is really an aspect of the type of drivers and receivers, e.g. for the std_logic type the user has an expectation of behavior for a leaf architecture which has processes that drive and receive values on wires, and that behavior is also understood by tools. However, architectures that are strictly structural really have no reason for having port directions.

Requirement

The direction keywords should have no effect in structural architectures, i.e. they bind to the processes not the ports of the entity/architecture: an in port can only have receiving processes, and an out port only driving processes in the associated architecture.

The type declaration should include instructions as to how the in/out rules are applied - the default being the current rules, and new keywords/attributes being added to change the behavior.

Implementation details

Allow a list of io rules on the end of a type declaration.

Code Examples

type my_logic is ( 'U','X','0','1','Z','W','L','H','-')

out : allow read, -- driving process can read signal value

in := inout; -- treat in as inout

Use Cases

Arguments FOR

Simplifies a lot of user code by eliminating need for intermediate signals and unnecessary inout usage. Avoids tedious arguments in committee about what behavior should be. Direction can be ignored in analog cases where it is meaningless.

Arguments AGAINST

General Comments

Io direction is an aspect of a particular style of modeling, and is not an aspect of real hardware (the electrons don't care).

Supporters

Add your signature here to indicate your support for the proposal