RE: [sv-ac] Proposal uploaded for Mantis 2654 (Ballot Comment #93)

From: Eduard Cerny <Eduard.Cerny_at_.....>
Date: Fri Apr 24 2009 - 13:59:45 PDT
Hi Tom,

I thought that we would add a comment somewhere before the start of the figures that use sampled values to say that the figures show sampled values. Even if the figure shows it in the middle of a cycle, it is OK because $sampled is not on a clock, but on a time step. This fix might be simpler and make the concerned figures consistent with each other.

Best...
ed

> -----Original Message-----
> From: Thomas.Thatcher@Sun.COM [mailto:Thomas.Thatcher@Sun.COM]
> Sent: Friday, April 24, 2009 4:32 PM
> To: Eduard Cerny
> Cc: Lisa Piper; sv-ac@eda.org
> Subject: Re: [sv-ac] Proposal uploaded for Mantis 2654 (Ballot Comment
> #93)
>
> Hi Ed,
>
> Yes.  However, when I look at a waveform viewer I never see the sampled
> value of a signal.  I only see the signal.  The text and diagrams will
> be much more clear if they show actual signal values.  Note that Figure
> 16-3 shows actual signal values changing in the middle of the cycle as
> well.
>
> I have uploaded a new proposal which makes fixes to 16-12 and 16-13.  I
> believe that both these figures are within the scope of this comment.
> Fixes for 16-14, 16-15, and 16-16 will have to wait unless there is
> another comment covering them.
>
> Tom
>
> On 04/24/09 11:33, Eduard Cerny wrote:
> > Hi Tom,
> >
> > Fig 16-14: if it shows sampled values, then I do not think the figure
> is wrong, it is missing the failures, but the success is correct. The
> figures rely on the fact that sampled values are shown.
> >
> > ed
> >
> >
> >> -----Original Message-----
> >> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
> >> Thomas Thatcher
> >> Sent: Friday, April 24, 2009 2:24 PM
> >> To: Lisa Piper
> >> Cc: sv-ac@eda.org
> >> Subject: Re: [sv-ac] Proposal uploaded for Mantis 2654 (Ballot
> Comment
> >> #93)
> >>
> >> Hi Lisa,
> >>
> >> The other diagram don't just LOOK off.  They are wrong!
> >>
> >> In Fig 16-13, the same waveform changes need to be made that I made
> for
> >> Fig 16-12.
> >>
> >> Fig 16-14 is just plain Wrong!  If you look at the property:
> >>
> >>      property data_end;
> >>         @(posedge mclk)
> >>         data_phase |-> ((irdy==0) && ($fell(trdy) || $fell(stop))) ;
> >>      endproperty
> >>
> >> In the waveform given in 16-14, the property succeeds in cycle 7,
> not
> >> in
> >> cycle 6.  However, the Property Fails in cycles 3, 4, 5, 7, 8, and
> 9!
> >> This is not shown in the figure.
> >>
> >> With this example, it might be better to just reverse the
> implication.
> >> The property as written doesn't really make sense.  i.e.
> >>
> >>         ((irdy==0) && ($fell(trdy) || $fell(stop))) |-> data_phase
> >>
> >> Figures 16-15 and 16-16 are wrong as well.  In Figure 16-15 the
> >> sequence
> >> data_end_exp should match in cycle 7, and data_end_rule should
> evaluate
> >> to true in cycle 9.  Figure 16-16 repeats the error from 16.14.
> >>
> >> However, since the comment only mentioned one figure, we probably
> don't
> >> have authority to change all four diagrams.  I will change both 16-
> 12
> >> and 16-13, as they are part of the same example.
> >>
> >>
> >> Our options:
> >> 1.  Make the change I suggested, moving the signal transitions to
> the
> >> middle of the cycle.
> >> 2.  We could pull the signal transitions all the way to the previous
> >> cycle.  If we did this, I would add the "the sampled value" to the
> text
> >> explanation below, like this:
> >>
> >>         Because the sampled value of signal burst_mode is hight at
> >> clock
> >>         tick 1 and low at clock tick 2 . . .
> >>
> >> 3.  We could leave the signal transitions alone.  If we did that, we
> >> would need to edit the figure anyway to move the match indications
> one
> >> cycle later.  We would then need to edit the explanation text to
> change
> >> the cycle numbers.
> >>
> >> Tom
> >>
> >> On 04/23/09 18:53, Lisa Piper wrote:
> >>> Hi Tom,
> >>>
> >>>
> >>>
> >>> The problem I have with this solution is that it makes other
> diagrams
> >>> look off too.  For example - Figure 16.13 and 16.14. I thought
> >> someone
> >>> (Ed??) was going to look at clarifying that the signals shown in
> the
> >>> diagram are actually depicting the sampled values of signals, in
> >> which
> >>> case the change would be to say:
> >>>
> >>>
> >>>
> >>> "Because the sampled value of signal burst_mode is high at clock
> tick
> >> 1
> >>> and low at clock tick 2, $fell(burst_mode) is true at
> >>>
> >>> clock tick 2."
> >>>
> >>>
> >>>
> >>> Lisa
> >>>
> >>>
> >>>
> >>> Ps Figure 16.14 is misplaced too in my copy
> >>>
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: owner-sv-ac@server.eda.org [mailto:owner-sv-
> ac@server.eda.org]
> >> On
> >>> Behalf Of Thomas Thatcher
> >>> Sent: Wednesday, April 22, 2009 12:59 PM
> >>> To: sv-ac@server.eda.org
> >>> Subject: [sv-ac] Proposal uploaded for Mantis 2654 (Ballot Comment
> >> #93)
> >>>
> >>>
> >>> Hello Everyone,
> >>>
> >>>
> >>>
> >>> I have uploaded a proposal for Mantis 2654 (ballot comment #93).
> The
> >>>
> >>> solution for this comment was simply to edit Figure 16-12, and move
> >> the
> >>> signal transitions forward to the middle of the cycle, before the
> >> clock
> >>> edge.  I re-created part of the figure to illustrate the change.
> Let
> >> me
> >>> know if I need to do something more to help the editor with this
> >> change.
> >>>
> >>>
> >>> Thanks,
> >>>
> >>>
> >>>
> >>> Tom
> >>>
> >>>
> >>>
> >>> --
> >>>
> >>> This message has been scanned for viruses and
> >>>
> >>> dangerous content by MailScanner, and is
> >>>
> >>> believed to be clean.
> >>>
> >>>
> >>>
> >> --
> >> This message has been scanned for viruses and
> >> dangerous content by MailScanner, and is
> >> believed to be clean.
> >
> >

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Fri Apr 24 14:00:34 2009

This archive was generated by hypermail 2.1.8 : Fri Apr 24 2009 - 14:00:48 PDT