Subject: Re: [sv-ec] Clocking Domains
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Thu Jan 30 2003 - 10:00:22 PST
> From Shalom.Bresticker@motorola.com Thu Jan 30 02:02:09 2003
>
> Kevin,
>
> Quoting mac, I don't want to beat this to death.
>
> I meant the following:
>
> 1.
> @(posedge clk) q <= clk ;
> will give you 1.
>
> 2.
> always @(posedge clk) q <= d1;
> always @(posedge clk) d1 = d2 ;
> is indeterminate because the 2nd block may execute first and update d1 before it is sampled in
> the first block.
>
> Shalom
Yes, but I think you just make my point:
always @(posedge clk.new) q = d1;
always @(posedge clk) d1 = d2 ;
isn't indeterminate. Using .new gives better control of data sampling, and is
potentially more efficient since you get to use blocking assigns for everything.
.new is also cheap to implement and doesn't add any new phases to event
processing.
Kev.
> Kevin Cameron wrote:
>
> > Shalom.Bresticker@motorola.com wrote:
> >
> > > If I understand correctly, and I am not sure that I do,
> > > it does not seem completely equivalent to an NBA.
> > >
> > > In always @(posedge clock) q <= d,
> > > d is not sampled until after posedge clock, not immediately before posedge
> > > clock.
> > >
> > > Shalom
> >
> > They're just functionally equivalent. This sample code shows that 'd' is sampled
> > at the posedge rather than after:
> >
> > module foo;
> > reg d,q,clk;
> >
> > initial begin
> > clk = 0;
> > d = 0;
> > q = 1;
> > #1;
> > clk = 1;
> > #1;
> > $display("d = %d, q = %d\n",d,q);
> > end
> >
> > always @ (posedge clk) begin
> > q <= d; // delayed assignment
> > d = 1'bX; // immediate
> > end
> >
> > endmodule
> >
> > Gives:
> > d = x, q = 0
> >
> > The ".new" methodology does the opposite of the NBA i.e. with the NBA you
> > sample at the clock and delay the assignment to q, and with ".new" you advance
> > the sample and do the assignment on the clock.
> >
> > I'm proposing ".new" to create a user-definable verification phase, i.e. rather than
> > wait for stuff to be stable after a clock, you can just create yourself an event
> > before the clock when things should be stable.
> >
> > Note: you can add a rule that it is illegal to assign a new value to a signal while
> > it's ".new" is being processed to avoid instability.
> >
> > Regards,
> > Kev.
> >
> > On Mon, 27 Jan 2003, Kevin Cameron x3251 wrote:
> >
> > > Date: Mon, 27 Jan 2003 16:07:35 -0800 (PST)
> > > From: Kevin Cameron x3251 <Kevin.Cameron@nsc.com>
> > > To: sv-ec@eda.org
> > > Subject: Re: [sv-ec] Clocking Domains
> > >
> > >
> > > Another "implicit" signal I'd like to put up for consideration is ".new".
> > > It would be a signal driven with the new signal value when the base signal is about
> > > to be updated by the simulator, i.e. when a write to a value with an associated
> > > .new is descheduled the new implicit is written first. You would be able to use it
> > > to create "preponed" processes for data sampling e.g. for a D-FF:
> > >
> > > always @(posdege clock.new) sampled_d = d;
> > >
> > > always @(posedge clock) q = sampled_d;
> > >
> > > always @(posedge clock) d = new_data;
> > >
> > > As with VHDL implicits you would be able to derive another implicit from the implicit
> > > and thereby create multiple phases for verification/synchronization within a delta.
> > > E.g.:
> > >
> > > always @(posedge clock.new.new) assert(sampled_d == q);
> > >
> > >
> > > I'm open to suggestions for another name if "new" seems confusing.
> > >
> > >
> > > Note the alternative encoding of the block above requires an NBA -
> > >
> > > always @(posedge clock) q <= d;
> > >
> > > - which hides the scheduling of an event into the next delta and the use of a temporary
> > > variable to hold the scheduled value, so computationally there isn't any extra
> > > overhead in using the ".new" methodology.
> > >
> > > Regards,
> > > Kev.
> > >
> > >
> > >
> > >
> > >
> >
> > --
> > National Semiconductor, Tel: (408) 721 3251
> > 2900 Semiconductor Drive, Mail Stop D3-500, Santa Clara, CA 95052-8090
>
> --
> Shalom Bresticker Shalom.Bresticker@motorola.com
> Design & Reuse Methodology Tel: +972 9 9522268
> Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890
> POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478
>
>
>
>
>
This archive was generated by hypermail 2b28 : Thu Jan 30 2003 - 10:01:50 PST