Time Killing Post P&R Simulation

[Nagaraj]

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

 

[Bob Perlman]

Hi -

On 11 Sep 2003 03:03:28 -0700, nagaraj_c_s@yahoo.com (Nagaraj) wrote:

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.

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

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 ?

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

 

[Mike Treseler]

Bob Perlman wrote:

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.

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

 

[Stephen Williams]

Bob Perlman wrote:

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 ?


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?

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,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."

 

[rickman]

Stephen Williams wrote:

Bob Perlman wrote:

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 ?


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?

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!

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

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[Brian Drummond]

On Thu, 11 Sep 2003 10:07:27 -0700, Mike Treseler
<mike.treseler@flukenetworks.com> wrote:

Bob Perlman wrote:

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.

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

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

 

[Mike Treseler]

Brian Drummond wrote:

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!

related thread:

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

** 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.

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

-- Mike Treseler