RE: [sv-ac] proposal for erratum 230

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 13:32:23 2004