Subject: Re: [sv-ec] Clocking Domains
From: Kevin Cameron (Kevin.Cameron@nsc.com)
Date: Tue Jan 28 2003 - 10:28:23 PST
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
This archive was generated by hypermail 2b28 : Tue Jan 28 2003 - 10:28:34 PST