Dealing with syncronizers

Qwerty112233 · Sep 21, 2023

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 · Sep 21, 2023

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 · 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.

Qwerty112233 · Sep 21, 2023

ThisIsNotSam said:
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 ---

FvM said:
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 · Sep 22, 2023

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

Qwerty112233 · Sep 22, 2023

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 · Sep 22, 2023

Qwerty112233 said:
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 · Sep 23, 2023

kaz1 said:
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 · Oct 9, 2023

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?

Dealing with syncronizers

Qwerty112233

Member level 2

ThisIsNotSam

Advanced Member level 5

FvM

Super Moderator

Qwerty112233

Member level 2

FvM

Super Moderator

Qwerty112233

Member level 2

kaz1

Full Member level 6

Qwerty112233

Member level 2

Qwerty112233

Member level 2

Similar threads

Dealing with syncronizers

Member level 2

Advanced Member level 5

Super Moderator

Member level 2

Super Moderator

Member level 2

Full Member level 6

Member level 2

Member level 2

Similar threads

Privacy & Transparency

Privacy & Transparency