more than 58'000 false paths...

Hi everyone,

I started adding false paths to my design (see this thread for a 
context: <boojj9FgihhU1@mid.individual.net>) 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?

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

On Monday, April 14, 2014 8:48:15 PM UTC-4, BobH wrote:
>=20
>=20
> I think you need to do your false path declaration from clock domain to=
=20
>=20
> clock domain, not register to register.
>=20

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

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

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

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

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 doma=
in as=20
> > being a false path rather than individual (or wild carded) paths is tha=
t=20
> > there no check that you don't incorrectly insert such a crossing.  If y=
ou=20
> > declare all clock domain crossings to be false, you have nothing in the=
=20
> > timing analyzer to check that you haven't overlooked something.  If you=
 do=20
> > declare them by path, then at least you would have had to look at the p=
ath at=20
> > some time and convince yourself that the path is not valid.  It's not=
=20
> > foolproof but it's better than nothing...unless of course it means that=
 now=20
> > the design won't build.=20

> I don't follow at all.  If you have paths between unrelated clocks, they=
=20
> can't be analyzed by STA because there is no clock period to the path.=20

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.

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

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.

> Are you saying that by adding them by path you are using STA as your=20
> check list to verify that you have caught all such paths?  I guess that=
=20
> has some use, but it can be a lot of work and as you say, no guarantee.=
=20

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.

> If it becomes cumbersome as the OP seems to be indicating, I think=20
> this can be omitted or perhaps used once to verify your special handling=
=20
> 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 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

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

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

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