The problem of setting set_false_path across clock domains

question:

Let me ask: Two asynchronous clock domains have paths, but they are both synchronized.

How should I constrain this asynchronous path? Is
it possible to directly set it to false path? Why
are many ip paths set to a period of the
source ? Is this setting only to ensure performance,

Why not set to two clock cycles?



answer:

1: It is possible to set false path in two asynchronous clock domains. Setting max delay is to ensure that the cross-clock signal of the bus class is the same shot of data when it is sampled. The constraint is generally one or half cycle of the destination clock. , the most stringent is half the fastest clock period of the source and destination.

2: If there is no path in the asynchronous clock domain or the path does not affect the function at all, the false path should be set directly. But if there are functional paths between asynchronous clock domains, and
    these paths are processed synchronously, then if only false paths are set, my understanding is that this will affect performance, not functionality. So use set max delay to guarantee performance.

    Is this understanding correct?

 3: It still depends on your design, such as the bus crossing the clock, assuming it is a 3bit signal, if only asynchronous is set, then 1bit may arrive in 1cycle, 1bit may arrive in 2cycles, and 1bit may arrive in 3cycles. At this time, cross-clock sampling If the design tolerance is high, for example, it is static, then there is no problem. If the design tolerance is not high, for example, the data of two shots can only be kept unchanged, then the function may be wrong. . :

4: Thank you. The general multi-bit bus will not directly use asynchronous clock sampling for synchronization, basically fifo, unless it is static to you. I am asking more, for example, if the bus uses asynchronous fifo synchronization, the Gray code signal in the asynchronous fifo will be constrained and set to set_max_delay $source_clk_period. Is this just to ensure performance, that is, if the Gray code in the asynchronous fifo is synchronized Signal path directly set to false path doesn't affect functionality, just performance?

5: If only set_false_path is used, the synthesis tool will not regard the corresponding CDC path as a so-called "timing path", but will think that "the timing of this path does not matter", and may pre-insert many unnecessary cells. More importantly, when the back-end people actually lay out, they will also think that this is a false path, so it may be because the chip P/R space is not enough, or the wiring is not balanced enough, or the local power cannot converge, etc. The CDC paths of interest can be drawn very long or scattered, and even multiple layers or diagonal lines can be taken in the layout. You can see a bunch of BUFs with strong drive (such as D16, D32, etc.) in the related PT setup timing report, or a few delay cells with a long delay (hundreds of ps) suddenly pop up. For false paths, the tool will misunderstand the design, so set_max_delay is used as an explicit delay constraint




Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=325730914&siteId=291194637