RE: [sv-ec] input skew

I ran the example on two simulators.
One gave Neil's result:

                   5 4 4 0
                  15 14 14 5

The other gave the following:

                   5 4 4 0
                  15 14 14 10

Regards,
Shalom

> -----Original Message-----
> From: Neil Korpusik [mailto:neil.korpusik@oracle.com]
> Sent: Thursday, June 23, 2011 5:02 AM
> To: Daniel Mlynek
> Cc: Bresticker, Shalom; Jonathan Bromley; sv-ec@eda.org
> Subject: Re: [sv-ec] input skew
>
> Hi Daniel,
>
> The default #1step input skew is most useful when there are more than one
> timescale specified, each of which is different. When there is one timescale
> for all of the source files, the need for #1step is reduced. Using #1step
> allows code to continue to work as expected, even when a new timescale is
> added to parts of the hierarchy.
>
> As for your example, I would expect to see the following output:
>
> 1st line: 5 4 4 0
> 2nd line: 15 14 14 5
>
>
> Neil
>
>
>
> On 06/22/11 04:48, Daniel Mlynek wrote:
> > I got diff between 1step and #1 where unit != step.
> > But what if unit == step?
> > Lest have an example
> >
> > `timescale 1ns/1ns
> > module top;
> > bit clk;
> > int a,b,c;
> > assign b=a;
> > assign c=a;
> > initial repeat(20) #5 clk = ~ clk;
> > clocking cb @(posedge clk);
> > input a;
> > input #1 b;
> > input #10 c;
> > endclocking
> > initial begin
> > forever #1 a++;
> > end
> > always @(cb)
> > $display($time, cb.a, cb.b, cb.c);
> > endmodule
> >
> >
> > What would be the 1st line of output:
> >
> > KERNEL: 5 4 3 0
> > or
> > KERNEL: 5 4 4 0
> >
> >
> >
> >
> > What would be the 2st line of output:
> >
> > KERNEL: 5 14 13 4
> > or
> > KERNEL: 5 14 1 4 5
> >
> > From text I would say that 2nd results are ok, but from common sens I
> > would say that 1st one
> >
> > DANiel
> >
> > On 6/22/2011 10:46 AM, Bresticker, Shalom wrote:
> >>
> >> Jonathan, please note Mantis 1247.
> >>
> >>
> >>
> >> Regards,
> >>
> >> Shalom
> >>
> >>
> >>
> >> *From:* owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] *On Behalf Of
> >> *Jonathan Bromley
> >> *Sent:* Wednesday, June 22, 2011 11:32 AM
> >> *To:* Daniel Mlynek; sv-ec@eda.org
> >> *Subject:* Re: [sv-ec] input skew
> >>
> >>
> >>
> >> h Daniel
> >>
> >>
> >>
> >> I think you may be confusing "time unit" and "time step". However, I
> >> agree that the phrase "the time step skew time units prior" is quite
> >> hard to parse. In that phrase, "skew" is a placeholder for the value
> >> in the #skew sampling delay, so we could rewrite it as "the time step
> >> that occurred _skew_ time units prior to the clocking event".
> >>
> >>
> >>
> >> Consequently, input#1 sets the skew to one time UNIT, whereas
> >> input#1step sets the skew to one time STEP.
> >>
> >>
> >>
> >> The intent of #1step is to sample values as they were _immediately
> >> before_ the current moment in simulation time. Since a time step is a
> >> point in simulation time where there are some events, it's clear that
> >> there can be no activity (no value changes, no events) between the
> >> previous timestep and the current time step. So it doesn't matter at
> >> what absolute time the previous time step occurred. It could be as
> >> recent as one time-resolution before the current time, but it might be
> >> long before that.
> >>
> >>
> >>
> >> In any case, #1step sampling requires the clocking block to sample
> >> values in Postponed of the immediately previous time step. This is
> >> exactly equivalent to sampling in the Preponed region of the current
> >> time step, because there can be no value changes in the time between
> >> those two timesteps. That's quite satisfying, because it means
> >> input#1step sampling reliably gives the same values that are seen by
> >> assertions. [Question for VPI experts: is there any way that VPI
> >> callbacks could break that equivalence?]
> >>
> >>
> >>
> >> Another question for everyone: I used to think that there was a subtle
> >> distinction between "time slot" and "time step", but in the 2009 LRM
> >> they appear to be used interchangeably. Neither term appears in the
> >> Glossary. "time slot" is explained pretty thoroughly in clause 4, but
> >> "time step" doesn't appear to be defined anywhere. The assertions,
> >> coverage and VPI clauses seem to favour "time step", whereas clause 4
> >> predominantly uses "time slot". Is there a case for making an
> >> editorial change to use the same term everywhere?
> >>
> >>
> >>
> >> Jonathan Bromley
> >>
> >> ------------------------------------------------------------------------
> >>
> >> *From:* Daniel Mlynek <danielm@aldec.com.pl>
> >> *To:* "sv-ec@eda.org" <sv-ec@eda.org>
> >> *Sent:* Wednesday, 22 June 2011, 7:52
> >> *Subject:* [sv-ec] input skew
> >>
> >>
> >> /LRM senstences:/
> >>
> >> /1. A 1step input skew allows input signals to sample their
> >> steady-state values in the time step immediately before the clock
> >> event (i.e., in the preceding Postponed region)./
> >>
> >> /2.If the input skew is not an explicit //#0//, then the value
> >> sampled corresponds to the signal value at the Postponed region of
> >> the time step skew time units prior to the clocking event/
> >>
> >> /sugest that #1step and #1 input skew are the same/
> >>
> >> /So is clocking event occurs in time 10.
> >> Then sampled value is taken from postponed region of time 9 in both cases
> >> Is it how it should work If so then 1step is redunand./
> >>
> >> /
> >> DANiel/
> >>
> >>
> >> --
> >> This message has been scanned for viruses and
> >> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> >> believed to be clean.
> >>
> >>
> >>
> >>
> >> --
> >> This message has been scanned for viruses and
> >> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> >> believed to be clean.
> >>
> >> ---------------------------------------------------------------------
> >> 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* <http://www.mailscanner.info/>, and is
> > believed to be clean.
---------------------------------------------------------------------
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.