Re: [sv-ac] proposal for erratum 230

Ed:

You are right about 194--the discussion we had in an earlier meeting
clearly said we would disallow clock flow into an instance to which
ended or matched is applied.

Unfortunately, there was no LRM change in 194 to make this condition
explicit. Oops.

I think we need to add a statement in the clock flow section that
says that clocks do not flow into such instances. We should probably
also add a statement that says clocks do not flow into the reset
condition of a "disable iff".

Regarding declarations within an always block, they are not legal.
Therefore, a contextually inferred clocking event will never have
a sequence or property declaration in its scope. It can have
instances in its scope, though.

Best regards,

John H.

>
> Hi John,
>
> I mentioned that because in another earlier errata 194 forbids flow of clock
> into ended. If we change it then that errata must be changed too. No?
>
> Regarding clock flow - we could allow flowing through ended and matched.
> What about triggered?
>
> Regarding always blocks, I meant not declaring a sequence or property inside
> an always block. I.e., your modified example:
>
>
> always @(posedge clk) begin
> sequence s;
> a ##[1:5] b;
> endsequence
> a1: assert property (c ##1 b |-> d);
> end
>
> a2: assert property(s);
>
> I think that this is not allowed by the LRM or the new clock flow. Right?
>
> ed
>
>
> > -----Original Message-----
> > From: John Havlicek [mailto:john.havlicek@freescale.com]
> > Sent: Tuesday, November 23, 2004 3:58 PM
> > To: Eduard.Cerny@synopsys.COM
> > Cc: john.havlicek@motorola.com; sv-ac@eda.org
> > Subject: Re: [sv-ac] proposal for erratum 230
> >
> > Hi Ed:
> >
> > I don't think the 3.1a LRM is very clear on this point--you
> > might consider it undefined.
> >
> > In the section on clock flow (17.7.3), it says that a
> > clocking event flows into an instance of a named sequence or
> > property. It does not say whether it makes any difference if
> > an instance of a sequence has a method (ended, matched,
> > triggered) applied.
> >
> > My feeling is that we should stick with the simple rule that
> > a clocking event flows into an instance, whether or not there
> > is a method applied. If the declaration of the sequence has
> > no leading clocking event, then the instance will inherit the
> > incoming clocking event. Otherwise, whatever clocking event
> > applies to the declaration will supersede the incoming clocking event.
> >
> > Then we would use the new rules about default and
> > contextually inferred clocks applying as leading clocks to
> > assertion statements and let them flow.
> >
> > I don't follow why you think inferring a leading clock from
> > an always does not make sense. Consider:
> >
> > sequence s;
> > a ##[1:5] b;
> > endsequence
> >
> > always @(posedge clk)
> > a1: assert property (c ##1 s.ended |-> d);
> >
> > I think this should be legal and the instance of s should be
> > clocked @(posedge clk).
> >
> > What do you think?
> >
> > John H.
> >
> >
> > > Reply-To: <Eduard.Cerny@synopsys.com>
> > > From: "Eduard Cerny"<Eduard.Cerny@synopsys.com>
> > > Date: Tue, 23 Nov 2004 13:42:49 -0500
> > > Organization: Synopsys, Inc.
> > > X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
> > > Thread-Index: AcTRgiIGjFGa2kg2SIG8V/CNoRRHhgACdmmw
> > >
> > > Yes, I agree with that.
> > > Question, though: What about sequences that are used only
> > with ended,
> > > matched or triggered. How is the clock determined there?
> > Does it have
> > > to be explicit in the sequence as we discussed some time
> > ago? Or,. can
> > > it acquire the default clock ? (I do not think that
> > inferring it from
> > > always makes
> > > sense...)
> > >
> > > ed
> > >
> > >
> > > > -----Original Message-----
> > > > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On
> > Behalf Of
> > > > John Havlicek
> > > > Sent: Tuesday, November 23, 2004 12:30 PM
> > > > To: sv-ac@eda.org
> > > > Subject: [sv-ac] proposal for erratum 230
> > > >
> > > > All:
> > > >
> > > > Doron and I have been proofreading and discussing the
> > proposal for
> > > > erratum 230.
> > > >
> > > > After reading over the current text of 17.14, we found that the
> > > > proposal makes a change of substance that I did not notice before.
> > > >
> > > > My understanding of 17.14 in the current 3.1a LRM is that
> > a default
> > > > clocking event applies only to concurrent assertion
> > statements that
> > > > are not otherwise clocked. It does not apply to sequence or
> > > > property declarations.
> > > >
> > > > The proposal for erratum 230, as we discussed in yesterday's
> > > > meeting, says that a default clocking event applies to
> > all sequence
> > > > declarations, property declarations, and concurrent assertion
> > > > statements that are not otherwise clocked.
> > > >
> > > > It seems to me that we do not need to apply the default clock to
> > > > sequence and property declarations, since the default clock will
> > > > flow starting from the concurrent assertion statements. Also,
> > > > increasing the scope of the default clock to include the
> > > > declarations is not backward compatible with 3.1a.
> > > >
> > > > Therefore, I am changing the wording of the proposal for
> > erratum 230
> > > > so that the default clocking event applies only to concurrent
> > > > assertion statements.
> > > >
> > > > Please send any comments or concerns as soon as possible.
> > > >
> > > > Best regards,
> > > >
> > > > John H.
> > > >
> >
>
Received on Tue Nov 23 15:02:58 2004