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
Time Killing Post P&R Simulation
Started by ●September 11, 2003
Reply by ●September 11, 20032003-09-11
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
Reply by ●September 11, 20032003-09-11
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
Reply by ●September 11, 20032003-09-11
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."
Reply by ●September 12, 20032003-09-12
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
Reply by ●September 12, 20032003-09-12
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
Reply by ●September 12, 20032003-09-12
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
