Re: [oc] Re: Opencores Design Guidelines

["llbutcher" <llbutcher@veriomail.com>]

Rudolf:

I need to get a look at the text you identified as confusing.

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.

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


----- Original Message -----
From: "Rudolf Usselmann" <rudi@asics.ws>
To: <cores@opencores.org>
Cc: "llbutcher" <llbutcher@veriomail.com>
Sent: Sunday, November 11, 2001 12:45 AM
Subject: Re: [oc] Re: Opencores Design Guidelines


>
> Damjan,
>
> the text looks good, EXCEPT for the synchronizer_flop reference.
>
> Let me explain why:
> 1) The synchronizer flop is a single RTL flop.
> 2) The intention, as I understand it, is to use this RTL model to
> replace synchronizer flops in a gate-level simulation to avoid
> unknown output when setup/hold timing is violated (which can
> occur during synchronization).
>
> I feel that this sync flop thingie is VERY confusing.
>
> Lawrence, perhaps you can clarify this somewhere and document
> what the real intention is, and warn people that a single flop will not
> do the job ...
>
> Thanks,
> rudi
>
> On Sunday 11 November 2001 10:31, you wrote:
> > Rudi,
> >
> > is this ok:
> >
> > Strong Recommendation: Signals that cross different clock domains
> > should be sampled twice in destination clock domains (double sampling is
> > a MUST). See synchronizer_flop in OpenCores CVS in module common.
> >
> > Prevents meta-stability state.
> >
> > To make netlist verification easier, you should use one module (i.e.
> > sync.v, sync.vhd) that will have in, out and clock interface and the
> > first flip-flop should
> > have a unique name as this flip-flop will have timing violation. If it
> > has unique
> > name, it is easier to trace it and "change" it to not pass X's.
> >
> > Also it should be clear that you pass ONLY the control signal and not
the
> > data
> > bus etc.
> > <<
> >
> > For the record, I did not write 3.3.1. If above is not ok, send me a
text
> > that you want to see as 3.3.1. The only thing I ask to refer to
> > synchronizer flop in the CVS.
> >
> > regards,
> > Damjan

--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml