描述

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>