Answers Database

M1.5 TRACE: What to do about tilded values (~46ns) in the report


Record #3333

Product Family:  Software

Product Line:  FPGA Implementation

Problem Title:
M1.5 TRACE: What to do about tilded values (~46ns) in the report


Problem Description:
Keywords: approximate, estimate, tilde, timing report, twr

Urgency: standard


The TRACE or Timing Analyzer report may contain values
preceded by a tilde (~). If this happens, this means that
the value given is an estimation of the delay, and is not
necessarily the worst-case. There are three parameters that
will trigger a tilde in the report (any one of these will
cause the tilde):
1) The length of the route is physically long and passes
through too many PIPs (programmable interconnects) without
being rebuffered by a feedthrough.
2) The fanout is extremely high
3) The timing on the route segment exceeds a certain preset number for that fami
ly (35ns for the 4KE/EX/XL).

If any of these conditions are met, then the RC calculations
tend to break down.
TRACE automatically "penalizes" such nets by 20%, so if it is
not much above 35ns, then it is likely to be OK. If this net
is on your critical path, then some action may need to be taken.

It has recently been discovered that a tilde is added when it
was not really necessary for the XL and EX parts. If you are
using a XL or EX part, then you may safely disregard a tilde
on any net for any value, as the value reported should be
conservative (for M1.4).


Solution 1:

You can add a timespec to the net to try to get it
under limit. The reason tildes usually happen is
because the net got pushed aside due to congestion of higher-priority nets; a ti
mespec may help.
One thing to note: PAR does not attach any negative
connotation to a tilde, so if the tilded value does not violate any timespec, it
 will take no further action to try to get
rid of it.
You may also try rerunning PAR in a re-entrant route with a delay-based cleanup
(-d).




Solution 2:

You may add a PENALIZE TILDE command to the PCF, and perhaps add another 10-20%
penalty to the tilde. This is only useful if you have a timespec in the design t
hat applies to the tilded net. If the net can be relatively slow, but you don't
want it tilded, then perhaps you could add a slow global timespec with a more se
vere PENALIZE TILDE.



Solution 3:

Perhaps the best solution for a single tilde net is to go
into EPIC and unroute the net, then reroute it. Much of the time PAR moved the n
et to a slower/longer path so it could route higher priority nets, but subsequen
tly the resource became available again later on. If you go into EPIC and rerout
e it, often net can find the better route paths it was originally moved out of.
Try using a Delay-based cleanup (in the Autoroute -All menu).





Solution 4:

Another possibility is logic replication or creating your own
feedthroughs. PAR can create feedthroughs, but it might choose not to if there i
s not a timespec it has to meet. You can also
put a high fanout net on a global buffer (BUFG).

To create a feedthrough, you can add a BUF to schematic with
a "KEEP" attribute applied to the net on both sides of the BUF.
In HDL, you have to instantiate it.


For Logic replication in HDL, you could describe the logic in
two separate processes (one process would drive one subset, another process woul
d drive another subset of the destination logic).
A schematic example of logic replication is given below:

From:

----net_a----->[FLOP_Source]-------->[FLOP_Dest1,2,3,...,50]

To:

----net_a--o-->[FLOP_Source1]------->[FLOP_Dest1,2,3,...,25]
	   |
	   o-->[FLOP_Source2]------->[FLOP_Dest26,27,...,50]




End of Record #3333