[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [oc] Re: Opencores Design Guidelines



On Monday 12 November 2001 16:08, you wrote:
> Rudolf:
>
> I need to get a look at the text you identified as confusing.

I guess I didn't see any description for the flop. My concern was that 
people would assume that this is how to do syncing between clock
domains.

> That's exactly my intent.
>
> 1) I am tired of gate-level simulation coming up all X's because
>     some RTL flip-flop in an always block had a setup or hold
>     violation, and that flop is ONLY THERE to remove metastability
>     when signals cross from one clock domain to another (like the
>     grey-code address wires from the write side of an async FIFO
>     being watched in the read side.

Exactly, it's for gate level simulations only !

BTW: Another way to do the same thing is to turn off timing check in
your verilog simulator. For Cadence NCverilog, just specify +notimingcheck 
on command line, and you should have no unknowns due to timing
violations !

Cheers,
rudi

> 2) I feel that it would be best to set constraints from these special
>     sampling flops.  Specifically, the receive clock constraint will
>     normally be a full clock period, but since these special flops
>     will exhibit metastable behavior (inevitably) the designer has
>     to ask synthesis to make there be extra slack between the
>     sampling flop and the flops which use the resulting data.
>
> 3) I feel that the design is more testable if there are constraints
>     between the SOURCE clock and the SAMPLING clock, even
>     though these clocks are asynchronous.  I feel that it is important
>     from a scan perspective to have the signal delay from the source
>     to the destination flops be less that the period of the faster of
>     those two clocks.  In test mode, the clocks will not be running
>     asynchronously, and the constraint will make sure that the
>     signal crosses the clock domain boundry in 1 clock.
>
> So the thing I do is
>
> 1) Manually instantiate specially named flops for these special
>     synchronization flops in the design.
>
> 2) Bring the synchronization clock to the top level, where it is
>     connected to the receive clock source.  It is actually on the
>     normal receive clock tree, because they are connected at the
>     very top of the design.
>
> 3) By having a different named clock up to the top level, I hope
>     that synthesis constraints can be written which specify constraints
>     from Source to ynchronization clocked flops, and from Synchronization
>     to Receive clocked flops.
>
> I don't know how to write these constraints.  I think it would be good
> to have example constraints files in an example of the use of this
> synchronization flop technique.
>
> Anyone know synopsys well enough to pop out an example?  3 clocks,
> clock 1 having period A, clock 2 and 3 having period B, BUT tight
> constraints between clock 1 and clock 2 as if they were the same
> frequency, and tight constraints between clock 2 and clock 3?
>
> Blue Beaver
--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml