RE: [sv-cc] Re: [sv-ec] RE: [sv-bc] RE: [sv-ac] New keywords in SV-AC proposals

In reviewing the Mantis item 1503, prepared by the SV-AC
team for review by the SV-CC, I have already been exposed
to the fact that "The assertion portion of that language
already has untyped formal  arguments which you seem to
associate with 'substitution/macro' like assumptions,"
as Mark has noted.  For what it's worth, I didn't like it
either, but there it is.

As to the impact on VPI, yes, there is one.  I am still
not comfortable with the revised proposal for handling
these 'substitution/macro-like' arguments; it does not
fit with the rest of VPI.  But even more, formal arguments
and local assertion variables in general have behaviors
that vary distinctly from other value-bearing
objects in VPI and for that matter in the rest of
SystemVerilog.  For example, a single assertion variable
can be cloned and coalesced many times in the processing
and termination of "attempts".  The VPI object model is
just not equipped to handle this.

Again, the VPI object model now generally assumes that
formal arguments can have data types.  While assertion
properties are moving so as to allow that, that has
not historically been the case, and one can freely
substitute arbitrary expressions for the untyped
formals and use them in the instantiated properties
in a pass-by-name sort of way.  But again, it is not
necessarily a single pass-by-name, as parts of the expression
can be cloned independently of others during the
generation of attempts, according to my admittedly
limited understanding.

So, I agree with Mark that these aspects of checkers are
not new to SystemVerilog, but I also agree with Gordon
that they are semantically at variance with the non-assertion
parts of SystemVerilog, including within the context of VPI.

Regards,
Jim Vellenga

--------------------------------------------------------- 
James H. Vellenga                            978-262-6381 
Software Architect                     (FAX) 978-262-6636 
Cadence Design Systems, Inc.         vellenga@cadence.com 
270 Billerica Rd
Chelmsford, MA 01824-4179
"We all work with partial information." 
----------------------------------------------------------  

]-----Original Message-----
]From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On 
]Behalf Of Gordon Vreugdenhil
]Sent: Thursday, March 20, 2008 6:41 PM
]To: Mark Hartoog
]Cc: Steven Sharp; stuart@sutherland-hdl.com; sv-bc@eda.org; 
]sv-ec@eda.org; sv-cc@eda.org; sv-ac@eda.org; 
]shalom.bresticker@intel.com; Eduard.Cerny@synopsys.com
]Subject: [sv-cc] Re: [sv-ec] RE: [sv-bc] RE: [sv-ac] New 
]keywords in SV-AC proposals
]
]
]
]Mark Hartoog wrote:
]> Gord wrote: 
]>>> Steven Sharp wrote:
]>>>>> From: "Eduard Cerny" <Eduard.Cerny@synopsys.com>
]>>>>
]>>>>> For my information - the system functions like 
]$inferred_clock are
]> 
]>>>>> processed during compilation / elaboration and are 
]replaced by the
]> 
]>>>>> actual expressions from the design.
]>>> Ed, I think you are *assuming* that would be what one would do.
]>>> I understand that is a nice "macro like" model for the 
]special case, 
]>>> but isn't clear to me that one would necessarily be
]>>> *required* to do so.  In fact, it seems that such a requirement 
]>>> would end up conflicting with vpi assumptions about being able to 
]>>> recreate (non-macro expanded) source and navigate around the
]> expreessions.
]> 
]> Processing of $inferred_clock during compilation/elaboration does not
]> imply a
]> a "macro like model".
]
]Hmm - Ed said "replaced by the actual expressions".  If one
]says "is equivalent to the inferred event" or similar, no
]problem.  The "replaced by" certainly makes it sound to
]me like a macro-like processing step.  If not is not the
]expectation, that is fine (obviously).  The vpi and other
]related issues are then also not an issue although I would
]wonder how one would access the *actual* inferred expression
]via vpi.  I know that is arguing both for and against my
]earlier question but I know that some people are very
]concerned about source-faithful vpi expression access and
]if both that AND the replacement (or "determined sensitivity")
]are needed, that should be covered.
]
]
]> 
]> module #(type T = int) m (input T x);
]> logic [$bits(T):0] y;
]> endmodule
]> 
]> One could say that during compilation/elaboration, the type parameter
]> 'T' is
]> replaced by the actual type, and the $bits(T) function is evaluated. 
]> Does that make modules into macros ?
]
]> Nothing in the statement that $inferred_clock is "processed during
]> compilation/
]> elaboration" would require a conflict with the vpi assumption. 
]
]I agree -- "processed" does not.  "Replaced by", particularly
]given earlier "rewriting" approaches into generates that AC
]suggested and which are problematic, do make me take note.
]
]Gord
]-- 
]--------------------------------------------------------------------
]Gordon Vreugdenhil                                503-685-0808
]Model Technology (Mentor Graphics)                gordonv@model.com
]
]
]-- 
]This message has been scanned for viruses and
]dangerous content by MailScanner, and is
]believed to be clean.
]
]

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.