Forcing Outports

Issue Information

• Reporter: John Shields via VHDL-200X reflector
• Contributors: Jim Lewis, ...
• Date Proposed: 2012-January-4
• Date Last Updated: 2011-February-16
• Priority:
• Complexity:
• Related Issues: None
• Competing Issues: None
• LCS: LCS-2016-I12

Issue Summary

What does it mean to force an out port with "in" mode?

• a) it is an error,
• b) it is allowed and the mode is ignored (maybe a pedantic warning is desirable), or
• c) every out port must maintain both a driving and effective value to allow for forcing each independently.

Current Situation: From JohnShields

Copied from reflector

There is a VHDL 2008 feature to support reading of out ports and another to support forcing of ports. There is reasonable doubt that the LRM and its framers have clarified all the interactions. I have a suggested clarification to discuss.

First, the intent to allow reading of out ports is meant to allow introspection of the driving value of the port. An out port only had a driving value and one was not allowed to read it in the past. Allowing allows for assertions of correctness to be made, reporting its value as a debug aid, and the like. Of course, read access is general, it can appear on the right hand side, you can pass it to a subp, as an actual in an instance, etc. Regardless, you are reading its driving value. There was recognition that if you wanted this to have a structural effect on the behavior of the model, the proper language construct to use was a buffer port, but that was not something to be enforced by the language.

Forcing allows one the flexibility to provide stimulus, debug, or patch one’s design. The feature allows you to force ports. A port that is an inout port has both a driving and effective value and the force command allows you to qualify the force mode as "in" or "out" to designate which value is to be affected. The problem lies in the fact that an in port only has an effective value, an out port only has a driving value, and an inout has both. What then does it mean to force an in port with "out" mode or an out port with "in" mode?

I believe it should either be an error or, if allowed, only affect the value that the port has, driving or effective, as the case may be. It seems for an "in" port, it is an error. For an out port, it seems it is not an error. If fact, it is not even clear if the intent is that an out port must be modeled with 2 values in order to allow forcing of its read value as distinct from its driving value. The possible clarification is that a) it is error, b) it is allowed and the mode is ignored (maybe a pedantic warning is desirable), or c) every out port must maintain both a driving and effective value to allow for forcing each independently.

I prefer a) or b). c) implies a simulation penalty, but the real issue is what the out port represents has been confused by the interaction of these features. Should we be saying that an out port has an effective value at all? Is it distinct from its driving value or is it always the same as its driving value? LRM terminology needs to be aligned with the interaction of these 2 language features an clarify them. Anything is possible, but clarifying the LRM is necessary.

-- DavidKoontz - 2013-09-26

The penalty you ascribe to c) is illusory, it results from evaluating a signal to determine it's effective value, which can be the result of say resolution for multiple drivers. The effective value is either the driver value for a single driver net of an unresolved type or the resolved value for a multiple driver net of a resolved type. You could note there is no particular difference in determining the effective value based on port mode. It's a function of net topography and is associated with a port actual and not formal.

Reading 10.5.1, 14.7.3.2 and 14.7.3.3 it appears the intent of force mode for a force was to distinguish between a driver force and an effective value force, borrowing in and out to conserve keyword space.

Port mode out versus buffer has no particular bearing, reading an out port a matter of formal driver value and not effective value of the actual.

The question is whether or not the syntax (and resulting semantics) of specifying an effective value force on a port signal formal of port mode out should be allowed versus requiring the alternative of an effective value force on the port signal actual.

You could note that the effective value of the actual isn't visible within the design entity declaring the port formal of mode out support interpretation a) (an error).

From January 5 2012 Meeting

• What would we do for the next revision?
• Peter thinks interpretation A is a reasonable interpretation. Martin and Jim concur.
• David believes that the intent of VHDL-2008 was to make out and buffer identical. Jim concurs.
• What does a designer need it to do? What are the use models/methodology?

Supporters

Add your signature here to indicate your support for the proposal

-- JohnShields - 2012-05-18 redundant though it is, I signed to acknowledge the discussion.