what if we dont ignore false data path, and it generates timing error

hello every one,

What if we dont ignore false data path, and it generates timing error in STA.
Will the final .bit file generated will not act appropriately (if simulation is fine and assuming other parameters related to h/w and s/w are just fine, except for this timing error of FALSE path)

It is because I have a design where the Memory Interface Generator (MIG) is being used as guided by the vendor, but in the design OF VENDOR itself there is this timing error and when I inquired them they say that it is a false path...So I am confuse...What will the planner do while doing its job.

The bit file is fine as long as the only timing violation is the false path.

...but...

You should add a TIG to the false path as it would be appropriate in this situation. I would advise against just leaving the false path timing violation. If you don't TIG it there is a potential for the tools (PAR) to attempt to fix this failing path (which incidentally may be impossible to meet) resulting in problems elsewhere in the design. I've seen this happen on more than one occasion and have determined that it's primarily the timing driven placement that messes up the placement of other areas attempting to fix an impossible to meet timing arc.

Regards

ads-ee said:

If you don't TIG it there is a potential for the tools (PAR) to attempt to fix this failing path (which incidentally may be impossible to meet) resulting in problems elsewhere in the design. I've seen this happen on more than one occasion and have determined that it's primarily the timing driven placement that messes up the placement of other areas attempting to fix an impossible to meet timing arc.

Click to expand...

Indeed. The tools will try to meet timing anyways for this potentially difficult path. While doing so it will use up valuable routing resources. Which in turn makes it more difficult to meet timing for the paths that actually DO matter. So using a TIG will essentially tell the tool to forget about those unimportant signals, and concentrate all effort on the ones that actually matter.

Thank you,

but how can one decide, I mean the designer, that the following path is a false path, note that it lies under some clock domain, so it must be synchronous, hence it cannot be left as it is, right!

A common example would be a slow microcontroller interface to a high speed clock domain. In this case, the controller sends an address + enable to the other clock domain. The other clock domain may need only to double-register the enable. This is one possible false path for the "synchronizer".

At this point, the address isn't changing. The microcontroller then waits for a few of its slow clock cycles for the data to be returned and accepts whatever is on the bus at that time. The fast clock domain simply holds the data constant while the enable signal is high. This may be 100+ ns. Thus, the path must meet the register setup time (small), at worst 3 fast cycles for en, and then the rest can be the output logic. 100ns - 12ns = 88ns of allowable delay in the data path! Not literally a TIG, but effectively it is.

(in this example, I've suggested 2 registers on the enable line in case it goes to any state machines that might be affected by async logic. If the address lines go to BRAM, they may also need to be double registered if the BRAM can be corrupted by S/H errors on the control lines. Some BRAM can be corrupted when the address S/H is not met during reads.)

The other common example would be async fifos, which are designed to allow unrelated clocks. In some cases, the tools will see a relation (eg, common PLL). This can result in absurd requirements placed on the part of the design specifically designed to deal with the lack of synchronous requirements!