Hi,

I'm doing a Post-Route Simulation simulation in ModelSim V6.1a and having 
problem with physical paths delays.

The placed & routed netlist and associated SDF delay file are created with 
Lattice ispLever V5.1.

The problem is that propagations times from all signals are not the same on 
ModelSim wave window compare with the propagations times display on SDF 
file.


Example:

On the .SDF file and the Place & Route Trace Report .TWR file I found 2.887 
ns between the output F0 of SLICE_1442 and the input D1 of SLICE_1384.

On ModelSim the same physical path had a propagation delay of  5.487 ns!!!!

The question is simple: Why a difference here?

Useless to say that the whole simulation is wrong and the only solution is 
to increase the clock period...

Thanks,
Dan NITA




..TWR FILE RAPPORT:
CTOF_DEL    ---  0.310    R8C11A.D0 to    R8C11A.F0 SLICE_1442
ROUTE         5  2.377    R8C11A.F0 to    R3C15D.D1 instMotorsDriver_N_23
CTOOFX_DEL  ---  0.510    R3C15D.D1 to    R3C15D.OFX0 
instMotorsDriver_sigAccumulator_20_8_0_13/SLICE_1384
ROUTE         1  0.000    R3C15D.OFX0 to  R3C15C.FXB 
instMotorsDriver_instDriverProcessor_N_323


..SDF FILE RAPPORT:
(CELL
      (CELLTYPE "instMotorsDriver_sigAccumulator_20_8_0_13_SLICE_1384")
      (INSTANCE instMotorsDriver_sigAccumulator_20_8_0_13_SLICE_1384I)
    (DELAY
      (ABSOLUTE
        (IOPATH D1 OFX0 (510:571:632)(510:571:632))
        ...........
      )
    )
  )
(INTERCONNECT SLICE_1442I/F0 
instMotorsDriver_sigAccumulator_20_8_0_13_SLICE_1384I/D1 
(2377:2563:2749)-(2377:2563:2749)) 

Dan,

What kind of speeds are you pushing through your external I/O's and the
fabric itself? Depending on the clock period of your external I/O's and
the input port delays of your fabric components, it may be a
Verilog/ModelSim pulse-swallowing simulation issue. You can, however,
set path and transport delays to fine-tune the post-PAR simulation.

I was having a (somewhat) similar problem before, and it turned out
that my internal routing was not an issue, but my external I/O's were.
In my case, the facade was that fast bit transitions appeared to take
about twice as long, and the data was often wrong. This was ultimately
traced back to chip's multi-gigabit pins being too fast for ModelSim to
handle without special parameters... it was essentially swallowing
pulses on MGT pins and missing bit-by-bit transitions on the input.
This may or may not be the same issue as yours, but it could have the
same solution.

This is a Xilinx page, but it addresses the Verilog/ModelSim issue of
pulse swallowing on fast transitions:
http://toolbox.xilinx.com/docsan/xilinx4/data/docs/sim/simu12.html

Julian Kain
www.juliankain.com

Thanks for your explanations.

The clock is not that high, 60 MHz is the maximum frequency. Moreover, the
problems come out for internal signals, slice to slice propagation time.

I really don't understand how ModelSim estimate the propagation time...

I know that backannotation usually provides worst-case timing into the
simulation but why I cannot find the same propagations times on the .SDF
file?




Maybe the .SDF file is not the only input that ModelSim use for timing
estimation?



Dan.

Dan NITA wrote:
> Hi,
> 
> I'm doing a Post-Route Simulation simulation in ModelSim V6.1a and having 
> problem with physical paths delays.


http://groups.google.com/groups?q=no+sdf+sim+routed+netlist+needed

    -- Mike Treseler

Dan,

I don't think the .TWR example is complete since I'd expect to see some
additional delay like clock-to-Q of the first synchronous element in
the list. But in general I'd expect to see ROUTE delays of the TRACE
report that match the INTERCONNECT delays of the SDF.

I wonder if the SDF file is simply out of synch with the TRACE report?
Or maybe you're overriding the speed grade with TRACE? See Tools >
TRACE Options... in the Project Navigator. Also check the SDF setup in
ModelSim. See Simulate > Start Simulation... and the SDF tab where you
can specify the Min|Typ|Max delay to be applied.

Troy Scott 
Lattice Semiconductor TME

Hello,

> I don't think the .TWR example is complete since I'd expect to see some
> additional delay like clock-to-Q of the first synchronous element in
> the list. But in general I'd expect to see ROUTE delays of the TRACE
> report that match the INTERCONNECT delays of the SDF.

Indeed, the route delays of the Trace report matches the interconnect delays
of the SDF. That is OK.


>
> I wonder if the SDF file is simply out of synch with the TRACE report?
> Or maybe you're overriding the speed grade with TRACE? See Tools >
> TRACE Options... in the Project Navigator. Also check the SDF setup in
> ModelSim. See Simulate > Start Simulation... and the SDF tab where you
> can specify the Min|Typ|Max delay to be applied.

I will investigate this Multi-Source Delay options on the SDF tab. Thanks
for all
the suggestions.




> Troy Scott
> Lattice Semiconductor TME


Dan.

If you have no multcycle path or false path constraints, then yes, STA
plus RTL simulation are all you need.

But...   If you have any multicylce or false path constraints, you
either need a tool that will verify their validity, or you must run sim
with full timing to verify them.  Otherwise, what you thought was a
multicycle or false path may not really be so (or more commonly: not
properly specified), but the RTL sim and STA would indicate all was
well.  Note that the full timing sim can be reduced to cover only
sections that have such constraints.

Andy

Andy wrote:
> If you have no multcycle path or false path constraints, then yes, STA
> plus RTL simulation are all you need.

Yes. I pipeline multicycles and cover
synchronization without false path constraints.

> But...   If you have any multicylce or false path constraints, you
> either need a tool that will verify their validity, or you must run sim
> with full timing to verify them.  Otherwise, what you thought was a
> multicycle or false path may not really be so (or more commonly: not
> properly specified), but the RTL sim and STA would indicate all was
> well.  Note that the full timing sim can be reduced to cover only
> sections that have such constraints.

A full timing sim is a good release check-off item,
but I keep it out of the detailed design loop.

         -- Mike Treseler

Mike,

I'm pretty sure you understand this, but others may not:

The problem is not in having multicycle or false paths in a design; it
is in having constraints that relax timing requirements on those paths
that is the problem.  If the entire design p&r's and meets STA without
any of the above constraints, great, problem solved. But if it does
not, and you include the constraints, then there is a problem in that
the constraints may relax timing on paths that really are not
multicycle (or false), and then only a full timing sim will reveal it
(and then only if that particular path is exercised by the sim!).  In
fact even if you don't include constraints to pass static timing, but
just review the violations and rationalize them as false/multicycle
paths, you really have the same problem in verifying the
rationalizations.

There are some cases where including multicycle and false path
constraints prior to synthesis can resolve timing issues elsewhere in
the design, by not consuming critical resources where they are not
needed, thus reserving them for truely critical paths.  Whatever the
reason/result of including these constraints, they must be verfied just
like the RTL code, but the only way to do it (without a custom formal
analysis tool) is with full timing sim, excersizing the paths so
constrained.

Your point about detailed design loop vs release check-off is a good
one. I assumed we were talking about check-off, since I never run full
timing until then anyway.

Andy

Andy wrote:

> The problem is not in having multicycle or false paths in a design; it
> is in having constraints that relax timing requirements on those paths
> that is the problem.

I agree with your posting.
My preference is to constrain only
Fmax and to meet STA by design only.
You are correct that this can consume some
resources, but it also saves time
and reduces stress.

     -- Mike Treseler