Dealing with syncronizers

[Qwerty112233]

Hi,
I am working on a design that has a handfull of clocks, there are some syncronizers for certain clock crossings. What is the approach recommended for syncronizers?

a) I find them in the design and use max delay commands on their inputs? this should relieve some pressure on the timing? What are the risks here?

b) Do you recommend knowing clock relations and then using set_clock_group -async -grp <> -grp <> -name command?

Risk with option B is that i kill any paths bw those, even if the syncronizer was missed in the RTL?

Eager to hear your thoughts

 

[ThisIsNotSam]

if the clocks are really independent to each other, clock groups is the elegant and correct solution. think about a test clock and a functional clock that are guaranteed to never exist at the same time.

the danger of this command is that it is strict. it disables any and every path from being timed between groups. it has to be used with a lot of care. if you can't be certain, then synchronizers/fifos are the way to go.

 

[FvM]

Definition of appropriate synchronisation means comes first. If you are sending a multi-bit signal consistently over a domain boarder, DCFIFO is the usual means, if data rate is onyl a fraction of slowest clock, a handshake synchronizer may be sufficient. A single bit signal may be e.g. transferred by a toggle synchronizer, a slow changing state bit by a DFF chain.

Timing constraints for the synchronizer comes second. If you are using ready made synchronizer IP like DCFIFO, the constraints are usually automatically generated, they'll work no matter if the clocks are explicitely specified asynchronous or not. A toggle synchronizer can be also packed into a module that generates timing constraints automatically.

 

[Qwerty112233]

if the clocks are really independent to each other, clock groups is the elegant and correct solution. think about a test clock and a functional clock that are guaranteed to never exist at the same time.

the danger of this command is that it is strict. it disables any and every path from being timed between groups. it has to be used with a lot of care. if you can't be certain, then synchronizers/fifos are the way to go.

Thanks for getting back. So the design has syncronizers implemented, and i am unsure of how to write constraints around those. Challenge there is that these 2 clocks are really from the same source PLL. But RTL does have a N stage sync for this crossing.

Do i write constraints to false path timing coming into these syncronizer flops ( i know the reference name of these cells)

Is handling these with clock groups safer? If i write a async clk group for these, then i will miss timing even on cases where RTL might be missing syncronizers (bugs)

--- Updated Sep 21, 2023 ---

Definition of appropriate synchronisation means comes first. If you are sending a multi-bit signal consistently over a domain boarder, DCFIFO is the usual means, if data rate is onyl a fraction of slowest clock, a handshake synchronizer may be sufficient. A single bit signal may be e.g. transferred by a toggle synchronizer, a slow changing state bit by a DFF chain.

Timing constraints for the synchronizer comes second. If you are using ready made synchronizer IP like DCFIFO, the constraints are usually automatically generated, they'll work no matter if the clocks are explicitely specified asynchronous or not. A toggle synchronizer can be also packed into a module that generates timing constraints automatically.

"

the constraints are usually automatically generated,

Well..the behavior i see is that the tool times this clock crossing path like any other flop. So, i feel i do need a set max delay or set clock grp command to get rid of these.

 

[FvM]

The first question hasn't been answered yet. What is the actual relation of clocks and do they need synchronizers?

 

[Qwerty112233]

Clocks come from a PLL (2 diff dividers) , so they are generated clocks of the same pll. they have a 2:1 relation. But since the crossing happens in a huge block physically and there's no need to have timing between them since they are 2 different domains..there are syncronizers that i see in the design.

 

[kaz1]

Clocks come from a PLL (2 diff dividers) , so they are generated clocks of the same pll. they have a 2:1 relation. But since the crossing happens in a huge block physically and there's no need to have timing between them since they are 2 different domains..there are syncronizers that i see in the design.

On a different note (applies to FPGAs at least):
Since clocks are related nicely as 2:1 then you can view them as such and you don't need synchronisers. You can set both to same phase and apply multicycle if timing fails.

 

[Qwerty112233]

On a different note (applies to FPGAs at least):
Since clocks are related nicely as 2:1 then you can view them as such and you don't need synchronisers. You can set both to same phase and apply multicycle if timing fails.

Thanks, yeah I think it's best if I MCP fails due to sync nature and don't do anything on ones that meet timing

 

[Qwerty112233]

MCP vs set max delay ?

Does it matter? Assuming sync clocks, but the syncronizer sits there to give you some timing relaxation per the designer. How to use this? MCP or set max delay?