Hello Hillel, John,
I am not sure if the newly updated text that is associated with AC-196 is up
to date, but given what is there and the discussions on the reflector, we
can see the following potential problems:
- the tf_port_list for assertion would have to be named differently as it
requires fewer items (direction only ref) and many things are optional.
- in passing by value, it is not clear what "at the time of activation"
means. For example, if it is a variable, is it at every clock tick, or at
the first tick the sequence is activated or at the first tick of the
simulation? Furthermore, if the argument passed in is to be used in ## or *
it has to be a compile-time constant. What does activation mean? How about
formal tools, what should the interpretation be in that case?
- when passing by value vs. passing by reference a design variable, is it
always sampled in the preponed region? Or does it differ?
- when passing by value or by reference a local variable, is there a
difference what value is used? And what if it is assigned in the sequence?
- for backward compatibility, untyped formals must be allowed as we agreed.
However, can you mix the two forms? In an earlier email, we suggested that
the untyped formals must be first in the list, so that they can be
distinguished from the types ones. This creates a difference from the
"normal" interpretation of implicit type, but at least syntactically it may
work. The alternative is as Adam (?) proposed, use one or the other but no
mixing on the same list. That would not work when both sequence and int
parameters are to be passed.
Given the time frame of 1800, it seems to us, that the simplest solution
would be as follows (at least until new types like sequence and property can
be introduced):
- only data type can be specified, no direction,
- it is used strictly for type checking but no value or ref interpretation,
- if the actual arg matches the type, substitution is done like in the
untyped case,
- untyped args precede the typed ones on the list.
We appreciate the goal of making formal argument specification compatible
with SV. However, it requires much more time to define semantics correctly
for these extensions. We are open to continuing to work through it off-line
to see what may work right.
Best regards,
ed&surrendra
Received on Wed Nov 17 14:04:31 2004
This archive was generated by hypermail 2.1.8 : Wed Nov 17 2004 - 14:04:39 PST