Subject: Re: [sv-ec] Clocking Domains
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Thu Jan 30 2003 - 13:34:55 PST
> From mac@verisity.com Thu Jan 30 12:19:34 2003
>
> Kevin Cameron x3251 writes:
> > 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.
> >
>
> 1) How do you sythesize this '@(posedge clock.new)'
From a synthesis perspective it's much the same as @(posedge clock), it
occurs in the same delta i.e. there is no time delay between them, only
the processing order is fixed. Since the processing order is better
defined it's less likely there will be race conditions and synthesis
should be easier.
> 2) Can't you unambiguate this already by:
>
> always @(posedge clk) q = d1;
> always @(posedge clk) #0 d1 = d2 ;
>
> 3) or even better:
>
> always @(posedge clk) begin
> q = d1;
> d1 = d2;
> end
>
> -mac
>
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.
While I don't think this approach would be a problem for synthesis I was
mostly aiming at creating a hook that you could hang "verification"
processes on as an alternative to creating a new verification phase in
the event processing.
Kev.
This archive was generated by hypermail 2b28 : Thu Jan 30 2003 - 13:35:42 PST