Hi,
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.
Regards, John
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed Jan 4 14:08:12 2012
This archive was generated by hypermail 2.1.8 : Wed Jan 04 2012 - 14:08:46 PST