Re: [sv-ac] Q: fix for rule (b) in 16.15.6 to allow inferred clock when expression appears in procedural assertion

It does seem like a good idea to have the final proposal reviewed
by the svbc. There are occasions where something from one committee
gets extended or generalized by another.

Neil

On 05/04/10 08:48, Seligman, Erik wrote:
> Thanks Shalom.
>
> So if we look again at the last proposal I sent:
>
> ----------
>> b) No term in expression1 appears anywhere else in the body of the
>> procedure, except in an assertion statement, expect statement, checker
>> or covergroup instantiation, or sampled value function.
> ----------
>
> Would it be reasonable to say that if we want to use these rules to auto-detect reset, this is OK, since a true reset would almost always be used directly rather than inside one of the constructs above?
>
> BTW-- I had one other thought about this whole discussion-- while it came up in the context of assertions, this is really a more general aspect of the language, since we're discussing a rule change here for general procedures. Does this mean we have to move the issue to sv-bc rather than proposing a final resolution ourselves?
>
>
> -----Original Message-----
> From: Bresticker, Shalom
> Sent: Tuesday, May 04, 2010 2:40 AM
> To: Seligman, Erik
> Cc: sv-ac@eda.org
> Subject: RE: [sv-ac] Q: fix for rule (b) in 16.15.6 to allow inferred clock when expression appears in procedural assertion
>
> I believe the intent was to emulate normal synthesizable RTL semantics for flip flops and distinguish the clock from the reset. That is, the basic synthesizable flip flop form is roughly:
>
> always @(posedge clk or posedge rst)
> if (rst)
> out <= 0;
> else
> out <= in;
>
> That is, the event control contains the clock and the asynchronous reset. One of the distinctions between the clock and the reset is that the clock does not appear inside the procedure body whereas the reset does.
>
> (One might want to consider other non-design logic statements in which the clock could legitimately appear, such as in a $display statement.)
>
>> But perhaps I'm missing some reasoning here. Does anyone
>> remember the motivation for the original rule? Was it due to
>> difficulties implementing tools that could handle this, or
>> some insight into the usual intent of such code?
>
> Regards,
> Shalom
>

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