Mismatch simulation & post sythese results

Hi

I am a little bit desperate at the moment. My design is working fine when simulating in with Modelsim. Also the sythesis process works fine but when I check the register content at the end of the computation with Chipscope I have a mismatch between the results that my simulation outputs :(

Anyone an idea how I could locate this error? Probably its going to be difficult to work with Chipscope and connect all the possible signals.

THanks for helpful feedback, Rob

Reply to
Rob Jones
Loading thread data ...

When you say ModelSim, are you talking about a behavioral simulation or post-translate? Sometimes things change with translation. If that isn't it, are you sure it isn't a timing issue? Also when you simulate are you using the same conditions as for the running hardware? Some mis-matches are in the stimulus, too. Can you successfully run a post place&route timing simulation and get the original simulation results?

If it turns out to be a timing issue (which might be caught by post p&r timing sim), I would look at a verbose timing report for possible problems in un-covered paths.

HTH, Gabor

Reply to
Gabor

Mostly agree but I think the priorities are ordered differently:

1) Check timing. Look at timing reports and verify everything passes. Make sure you're using the correct timing file for your chip. 2) Do a post map/p&r simulation to make sure that you don't have any multi-cycles you missed. Change the DUT in your testbench to output of P&R and make sure it works correctly. This will also check if your logic has been mapped correctly. 3) Check the initial state and the inputs to DUT in testbench and hardware are the same. 4) If still nothing start adding printfs to the chip ie add signals to chipscope starting at the input, first register output and proceed incrementally till you get to the output while verifying functionality at every point.
Reply to
Muzaffer Kal

Have you reviewed your design for metastability? Do all your state machines synchronize any asynchronous inputs (including reset!)

-Jeff

Reply to
Jeff Cunningham

Debug consists of partitioning a problem into easily controllable and observable elements. Those are what you need to look at with chipscope. If it takes 12 steps to make the journey from input to final register, do those 12 steps happen like you expect? Just looking at the 12th step doesn't tell you anything except that you've failed. Seeing what's right helps you isolate what's wrong.

Reply to
John_H

is that a interface error or a state machine error? if a interface error you should do the timing analysis for each data pin and clock pin. if a state machine error, I think you should review if all the state condition are considered.

Reply to
dadabuley

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.