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

I don't think it should be a problem for assertions.

Shalom

> -----Original Message-----
> From: Seligman, Erik
> Sent: Wednesday, December 29, 2010 5:33 PM
> To: Bresticker, Shalom; Little Scott-B11206
> Cc: Korchemny, Dmitry; sv-ac@eda.org; Francoise Martinolle
> Subject: 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?

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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