General Description:
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 family (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).
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 timespec 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).
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 that 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 severe PENALIZE TILDE.
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 net to a slower/longer path so it could route higher
priority nets, but subsequently the resource became available
again later on. If you go into EPIC and reroute 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).
Another possibility is logic replication or creating your own
feedthroughs. PAR can create feedthroughs, but it might
choose not to if there is 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 would drive another subset of the destination
logic).
<pre>
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]
</pre>
AR# 3333 | |
---|---|
日期 | 01/18/2010 |
状态 | Archive |
Type | 综合文章 |