Time Killing Post P&R Simulation

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi,
   I have a moderately big design (~250K equivalent ASIC gates) in
Vertex FPGA. The post place & route simulation in Modelsim takes hours
together for simulating about 2-3 ms of input data. This is a time
killing step in my  product development lifecycle. Moreover if some
timing errors occur (evenafter analyzing P&R static timing) more
syn-map-par-sim iterations are required with modified timing
constraints or higher effort levels etc.
   There are some recent developments in EDA tools like Mentor
Graphics' VStation which cater to problems like I am facing by
"actually" simulating on the target hardware. But they are toooooooooo
costly (I don't know what makes EDA tool companies to fix such a high
price for their products)
   Is there any alternate way of simulating my design ?

Regards,
Nagaraj

Re: Time Killing Post P&R Simulation
Hi -


Quoted text here. Click to load it

Are you implying that you see timing failures in post-route simulation
that static analysis doesn't reveal?  Have you reported this to
Xilinx?

Quoted text here. Click to load it

What's your motivation for doing post-route simulation?  Why not just
simulate your pre-synthesis code, and use post-route static timing
analysis to confirm the timing?

I've been doing FPGA design for years, and can count the number of
times I've done post-route simulation on the fingers of one hand.
It's something I resort to only if I suspect that the place and route
tool has a bug that's producing a faulty design.  (I mean, this is
something I *always* suspect to one degree or another, but usually I
can allay my fears in some less time-consuming a way--looking at the
post-map trim list, using the FPGA editor, etc.)  And if I think the
synthesizer is causing problems, I'll do a post-synthesis simulation.

The value (or lack thereof) of post-route simulation has been debated
here before; take a look in the archives.

Bob Perlman
Cambrian Design Works

Re: Time Killing Post P&R Simulation

Quoted text here. Click to load it

I agree. If an FPGA design is 100% synchronous,
sims functionally, and passes post-route static timing,
post-synth/route simulation is rarely indicated.

  -- Mike Treseler


Re: Time Killing Post P&R Simulation
On Thu, 11 Sep 2003 10:07:27 -0700, Mike Treseler

Quoted text here. Click to load it

I find it a useful crutch when you don't understand the way the timing
constraints work ... and the details of their syntax is not always
clear! but that need is reduced with more experience.

OTOH ... when the design is not 100% synchronous ... I have found errors
(** mostly mine! :-) crossing clock domains when I synchronised
handshake signals incorrectly. It's a useful tool in the armoury, to
pull out when things go wrong, but I agree it shouldn't be in the normal
development loop.

Related question: if you have one or two FF's in the entire design
dedicated to resolving metastability, you want to turn off their Tsu/Th
checks, since their whole point is to encounter setup/hold violations!

How do you do that for these individual FF's while leaving all the other
checks in place? (to catch any uncovered domain-crossing signal paths)
I resorted to inserting To_01() in the relevant signals in the
gate-level netlist by hand, which was untidy, but tolerable for the
(mercifully few) passes I needed, but there HAS to be a better way...


** but the FIFO solution from Xilinx app note ???(I forget which) also
"failed" post-route sim, coming out of reset. It only brings one reset
line out, which is used for both clock domains internally. I modified it
to bring out a reset in each clock domain, since I ran the incoming
reset through a synchroniser for the rest of my logic anyway.

Call me paranoid? In real life I doubt it matters, but in sim, once
"reset" put the counters into an indeterminate state, it never
recovered.

- Brian

Re: Time Killing Post P&R Simulation



Quoted text here. Click to load it

related thread:

http://groups.google.com/groups?q=synchronizer+sim+ack+blind


Quoted text here. Click to load it

Reliability comes from getting the details right.
Writing your own code is one way to do it.

    -- Mike Treseler


Re: Time Killing Post P&R Simulation

Quoted text here. Click to load it

We've started doing post route simulation of a design we are
working on, and we are finding that xst is being "surprising".
It's been not matching pre-synthesis simulation. We've been
finding bugs in the synthesis results. Yikes!

--
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
We've slightly trimmed the long signature. Click to see the full one.
Re: Time Killing Post P&R Simulation
Quoted text here. Click to load it

Can you provide any specifics?  What sorts of errors are you finding?
Is the synthesis not right?  Are circuits being "optimized" incorrectly
by the P&R software?  Timing issues?  

--

Rick "rickman" Collins

snipped-for-privacy@XYarius.com
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline