more than 58'000 false paths...

I think you need to do your false path declaration from clock domain to clock domain, not register to register.

BobH

Don't think so, the paths are between registers. Saying that every transfe r between clock domains is overly pessimistic (based on the OP's posting in the other thread that he referenced).

Just in general, the bad thing about marking clock domain to clock domain a s being a false path rather than individual (or wild carded) paths is that there no check that you don't incorrectly insert such a crossing. If you d eclare all clock domain crossings to be false, you have nothing in the timi ng analyzer to check that you haven't overlooked something. If you do decl are them by path, then at least you would have had to look at the path at s ome time and convince yourself that the path is not valid. It's not foolpr oof but it's better than nothing...unless of course it means that now the d esign won't build.

Kevin Jennings

[]

There's no clock domain crossing, everything is on the same clock domain.

I agree with what Kevin said: you need to track individual paths! I did this simply looking at the critical path reported by the synthesis tool and verifying it was a path involving my (in)famous fpu.

I spent 20h of synthesis runs to spot all the paths (essentially 30min each path!), now the problem is that the par is not able to fit timing constraints (clock frequency only). Occupancy level is not huge (60%) so I'm a bit puzzled.

I don't follow at all. If you have paths between unrelated clocks, they can't be analyzed by STA because there is no clock period to the path. These paths must be correct by design and require special attention separate from STA.

Are you saying that by adding them by path you are using STA as your check list to verify that you have caught all such paths? I guess that has some use, but it can be a lot of work and as you say, no guarantee. If it becomes cumbersome as the OP seems to be indicating, I think this can be omitted or perhaps used once to verify your special handling list and then omitted to speed up the rest of the design process.

--

Rick

What is your clock rate? What part of the design is failing timing? I thought you were going to set the timing of the FPU to match what the tools would produce... Are you saying the non-FPU portion of the design is failing timing?

--

Rick

in as

t

ou

do

ath at

now

You can have them analyzed. Other than to point out where this is a crossi ng though I'm not sure how to really interpret the results that come out si nce it would depend on the relative phases and the frequencies of the clock s. But I don't care about that, just the list of paths that cross.

Agreed. But there is still value in putting something in place to verify w hether you are 'correct by design' or if something slipped through the crac ks.

Yes, I use it as a check that there are no new paths created that cross dom ains. It's not a lot of work since there aren't a boatload of places where signals cross clock domains in the first place. There may be no guarantee , but it is an additional check that gets performed on every build. Of cou rse, within a clock domain and for the I/O pins, I'm using the full STA res ults.

I can't say I have any idea what is going in the OP's case. I wildcard spe cify paths so while I have a handful of path constraints I really don't kno w how many actual paths that explodes to. I haven't had those constraints have any dramatic impact on P&R time like the OP is seeing.

Kevin Jennings

Hi Al, I always considered the false path declaration to be useful for handling multiple clock domain issues, or getting the tool chain to ignore the scan clock (or scan enable) to normal clock interaction type problems. With a single clock domain, using the false path won't work from clock to clock.

If you are getting 60K expansions on 50 nets, maybe reducing the wildcarding would help.

Is all of your clock distribution on one of the global clock routing resources? Are you using clock gating?

60% utilization should not be forcing the P&R tool into choices that have problems. Do you have the I/O pins constrained? If so, releasing the pin constraints and letting the tool pick them is a useful troubleshooting method.

This is about all the ideas I have at this point.

Good Luck, BobH

Hi Kevin, KJ wrote: []

At least Synplify Pro generates an 'sdc' file with the expanded signals out of your wildcards. It seems to me the file is automagically generated so no need to specify anything special in your settings.

A simple:

grep set_false_path file.sdc | wc -l

will do the trick (on a *nix system).

After my last 56hours run and some easter eggs (no pun intended) in between, I've realized there are additional paths of my FPU which were ok during synthesis but failed after p&r. I guess now I need to add additional false paths after they have been flagged as failing after p&r...

I have to say that this is an endless story and I'm not sure where it is going to get me. After all those hours I guess now it would have been more reliable and less painful to pipeline the design (sigh!).

Al

Hi Bob, BobH wrote: []

Please refer to my other thread on 'path verification' to follow the insanity of what I've been asked to do.

false paths are from clock to D.

Uhm, I do not think I have much of a choice if I do not want to change the constraint file over and over again.

I haven't done any check about the clock beeing used on a single clock routing resource, but I guess is not since typically those chips are devided in quadrants and each quadrant has its own clock resource.

I'm not sure if I need to pay extra attention to quadrant crossing clocks...

There are no I/O pins at all, the design is meant to be used as a block since we cannot afford to re-do the exercise everytime we integrate the module within another project.

Thanks for sharing them.

Al