[sv-ac] RE: Discussion of 2804 (inferring clocking event within procedure)

Shalom, Ed-- thanks for your comments. It's still a little unclear to me though, which of these were motivations for the original rules:
- just to enable proper inference, in which case any new rule that provides deterministic inference criteria should be fine.
- or to rule out complex clocks that are nonimplementable in tools.

For example, are you saying there are practical difficulties to enable tools to implement code like this (ignoring for the moment whether it's legal yet)?:

event ev1;
assign ev1 = (posedge clk1 or negedge clk2);
always @(ev1) begin
    assert property foo; // 'ev1' should be inferred as clock for the assertion
    assert property (bar & clk2); // 'ev1' inferred as clock AND subexpression of clock used in body
...

-----Original Message-----
From: Bresticker, Shalom
Sent: Wednesday, December 29, 2010 3:10 AM
To: Seligman, Erik; Little Scott-B11206
Cc: Korchemny, Dmitry; sv-ac@eda.org; Francoise Martinolle
Subject: RE: Discussion of 2804 (inferring clocking event within procedure)

Hi, Erik.

As I remember, the original objective was to support the basic synthesizable subset for RTL. Anything that would be supported beyond that would be nice to have, but not essential.

The basic form has an event control with one or more event expressions, one of which is a clock, and the others are asynchronous resets.

There are extensions to that, but they are not in the minimum synthesizable subset.

Then the question was how to distinguish between the clock and the resets.

And all of this had to be done without mentioning the word "synthesis".

Disallowing the clock to be used in an expression was a way to distinguish a clock from an asynchronous reset.

There may also have been a desire to restrict the clock inference so as to get it working for the minimum synthesizable subset, but wait till a future revision with more flexible rules that might require deeper analysis.

Regards,
Shalom

> -----Original Message-----
> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
> Seligman, Erik
> Sent: Wednesday, December 29, 2010 12:36 AM
> To: Little Scott-B11206
> Cc: Korchemny, Dmitry; sv-ac@eda.org; Francoise Martinolle
> Subject: [sv-ac] RE: Discussion of 2804 (inferring clocking event
> within procedure)
>
> Hi Scott--
> I had assumed the previous restrictions were due to the difficulty of
> correctly inferring the clock when complex expressions are allowed, or
> when expressions in the always statement also appear in the body.
> Since we couldn't be sure what the user intended, it's best not to
> infer a clock. If this is the correct rationale, then in cases where
> the new rule provides a clear answer, we should be OK.
>
> If, on the other hand, the previous restriction was due to some
> implementation challenge of using a complex event expression to clock a
> procedure, or of using a procedure clock subexpression in the body, we
> need to revisit this.
>
> Does anyone recall the reasoning behind the original rules disallowing
> a complex event expression to be used as a procedure clock, and
> disallowing the clock to be used in an expression?

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