Subject: Re: [sv-ec] Clocking Domains
From: Shalom.Bresticker@motorola.com
Date: Tue Jan 28 2003 - 00:27:36 PST
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
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.
>
>
>
>
>
This archive was generated by hypermail 2b28 : Tue Jan 28 2003 - 00:28:25 PST