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

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".

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. 

>> This again is where the "substitution/macro" like assumptions in a 
>> bunch of the proposals bothers me because people are clearly assuming

>> behavior that isn't really in alignment with the rest of the LRM.

It is simply not true that these proposals are not in alignment with the
rest
of the LRM. The assertion portion of that language already has untyped
formal 
arguments which you seem to associate with "substitution/macro" like
assumptions. 
These have been in System Verilog since the 3.1 LRM and are part of the
IEEE
approved 1800-2005 LRM. Checkers are an enhancement to the assertion
portion 
of the language and the untyped formal arguments are completely in
alignment 
with the way sequences and properties are already defined. 

You seem to have assumption about the way Verilog is defined that are
not in 
alignment with the whole 1800-2005 LRM. 

>> Gord.


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