[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