Subject: Re: [sv-ec] Clocking Domains
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Thu Jan 30 2003 - 14:39:29 PST
> From: "Steven Sharp" <sharp@cadence.com>
>
> >Date: Thu, 30 Jan 2003 13:34:55 -0800 (PST)
> >From: "Kevin Cameron x3251" <Kevin.Cameron@nsc.com>
>
> >The point was to create a signal that can trigger processes just before
> >the clock changes - when all data should be stable - rather than to have
> >a delayed process waiting for the design to stabilize after the clock
> >event. My initial thought was to sort the sensitivity list somehow, but
> >I think the ".new" approach works better.
>
> But the reason the data becomes unstable when the clock changes is that
> processes triggered by the clock change the data. If you trigger processes
> at this .new time, the data becomes unstable then instead. Where is the
> gain for this extra complexity?
>
> Steven Sharp
> sharp@cadence.com
There isn't much complexity involved, and it's up to you whether you do
assignments in a process triggered by a .new signal. The intent was to
create a hook on which you can hang a process that does assertions about
the design before anything changes (aka a verification phase).
That fact that you can get a more stable design description with ".new"
is just a bonus. This code would be deterministic:
@(posedge clock.new) q <= d
@(posedge clock) d = new_d;
- the value of d gets sampled before the clock and is assigned to q after
the clock.
Kev.
This archive was generated by hypermail 2b28 : Thu Jan 30 2003 - 14:40:16 PST