more than 58'000 false paths...

[alb]

Hi everyone,

I started adding false paths to my design (see this thread for a
context: <boojj9FgihhU1@mid.individual.net&gt but in order to avoid funny
names, I started to add wildcards.

My false path constraints look like this:

set_false_path -from [get_cells execute0.r.ctrl_wrb.reg_d*] \
-to [get_cells execute0.fpu0.REGISTER_o*]

And I have ~50 of them. Now, the wildcard is expanded and I end up with
~60000 false paths that apparently are a too huge amount for my par tool
(Designer), which takes 40 minutes *only* to import the file and 7h to
perform place and route.

I feel there's something wrong here... Any suggestions? The sad part is
that it also fail to meet timing constraints, even though the synthesis
looked like it had sufficient slack margin to handle routing delays.

Thanks in advance,

Al

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

 

[KJ]

On Monday, April 14, 2014 8:48:15 PM UTC-4, BobH wrote:

I think you need to do your false path declaration from clock domain to

clock domain, not register to register.

Don't think so, the paths are between registers. Saying that every transfer 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 as 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 declare all clock domain crossings to be false, you have nothing in the timing analyzer to check that you haven't overlooked something. If you do declare them by path, then at least you would have had to look at the path at some time and convince yourself that the path is not valid. It's not foolproof but it's better than nothing...unless of course it means that now the design won't build.

Kevin Jennings

 

[BobH]

On 4/14/2014 5:38 AM, alb wrote:

Hi everyone,

I started adding false paths to my design (see this thread for a
context: <boojj9FgihhU1@mid.individual.net&gt but in order to avoid funny
names, I started to add wildcards.

My false path constraints look like this:

set_false_path -from [get_cells execute0.r.ctrl_wrb.reg_d*] \
-to [get_cells execute0.fpu0.REGISTER_o*]

And I have ~50 of them. Now, the wildcard is expanded and I end up with
~60000 false paths that apparently are a too huge amount for my par tool
(Designer), which takes 40 minutes *only* to import the file and 7h to
perform place and route.

I feel there's something wrong here... Any suggestions? The sad part is
that it also fail to meet timing constraints, even though the synthesis
looked like it had sufficient slack margin to handle routing delays.

Thanks in advance,

Al

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

BobH

 

[alb]

Hi Bob,

BobH <wanderingmetalhead.nospam.please@yahoo.com> wrote:

I started adding false paths to my design (see this thread for a
context: <boojj9FgihhU1@mid.individual.net&gt but in order to avoid funny
names, I started to add wildcards.
[]

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

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.

 

[KJ]

On Tuesday, April 15, 2014 12:46:02 PM UTC-4, rickman wrote:

Just in general, the bad thing about marking clock domain to clock domain as
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
declare all clock domain crossings to be false, you have nothing in the
timing analyzer to check that you haven't overlooked something. If you do
declare them by path, then at least you would have had to look at the path at
some time and convince yourself that the path is not valid. It's not
foolproof but it's better than nothing...unless of course it means that now
the design won't build.

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.

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

These paths must be correct by design and require special attention
separate from STA.

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

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.

Yes, I use it as a check that there are no new paths created that cross domains. 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 course, within a clock domain and for the I/O pins, I'm using the full STA results.

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

I can't say I have any idea what is going in the OP's case. I wildcard specify paths so while I have a handful of path constraints I really don't know 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

 

[rickman]

On 4/14/2014 9:37 PM, KJ wrote:

On Monday, April 14, 2014 8:48:15 PM UTC-4, BobH wrote:


I think you need to do your false path declaration from clock domain to

clock domain, not register to register.


Don't think so, the paths are between registers. Saying that every transfer 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 as 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 declare all clock domain crossings to be false, you have nothing in the timing analyzer to check that you haven't overlooked something. If you do declare them by path, then at least you would have had to look at the path at some time and convince yourself that the path is not valid. It's not foolproof but it's better than nothing...unless of course it means that now the design won't build.

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

 

[rickman]

On 4/15/2014 3:40 AM, alb wrote:

Hi Bob,

BobH <wanderingmetalhead.nospam.please@yahoo.com> wrote:
I started adding false paths to my design (see this thread for a
context: <boojj9FgihhU1@mid.individual.net&gt but in order to avoid funny
names, I started to add wildcards.
[]

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

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.

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

 

[BobH]

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

On 4/15/2014 12:40 AM, alb wrote:

Hi Bob,

BobH <wanderingmetalhead.nospam.please@yahoo.com> wrote:
I started adding false paths to my design (see this thread for a
context: <boojj9FgihhU1@mid.individual.net&gt but in order to avoid funny
names, I started to add wildcards.
[]

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

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.

 

[alb]

Hi Kevin,
KJ <kkjennings@sbcglobal.net> wrote:
[]

I can't say I have any idea what is going in the OP's case. I
wildcard specify paths so while I have a handful of path constraints I
really don't know 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.

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

 

[alb]

Hi Rick,
rickman <gnuarm@gmail.com> wrote:

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.

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?

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

 

[alb]

Hi Bob,
BobH <wanderingmetalhead.nospam.please@yahoo.com> wrote:
[]

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.

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

With a single clock domain, using the false path won't work from clock
to clock.

false paths are from clock to D.

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

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.

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

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

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.

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.

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

Thanks for sharing them.

Al