Different Modelsim versions disagree in same backannotation!

Hi all! I am experiencing a very strange and rather frustrating problem while trying to run the same backannotated simulation in two different versions of Modelsim. In both cases I am using exactly the very same files for everything, and also the same compilation and simulation commands. The old version (Modelsim 5.8b) simulates fine and gives the expected results, while a newer release (Modelsim 6.2e) gives erroneous results. The following caption explains the situation (copy and paste the following link in your browser):

formatting link

In the figure at the link above you can see the two simulations:

****[Upper part of image: Modelsim 5.8b - Results: OK, as expected] Notice pulse on signal "RNet7947' begining @ 10263ns and falling @ 10353ns. This is an update signal that is correctly fetched by the clock "RNet7665" @ 10353ns. The good, expected behavior is that the data in signal "WIR_shift" is updated to signal "PER/WIR", as shown.

****[Lower part of image: Modelsim 6.2b - Results: WRONG, unexpected] Notice pulse on signal "RNet7947' this time begins @ 10264ns and falls @ 10354ns, too early to be fetched by the clock "RNet7665" (see carefully). Thus, the signal "WIR_shift" is NOT updated to signal "PER/WIR", which remains in "000", as shown.

I would be the most grateful if anybody could please give a clue to what is going wrong here. I REALLY need to get version 6.2e to run correctly with my design. The simulation command issued in both versions is as follows: vsim -sdfmin /ram_16kx16_tap_top_tb_p1500/dfm_0=DFM_TC_Best.pt.sdf

-sdfnoerror -sdfnowarn -t ns +mindelays work.ram_16kx16_tap_top_tb_p1500

In both cases I am using the same SDF file, with has the following header: (DELAYFILE (SDFVERSION "OVI 3.0") (DESIGN "DFM_TC") (DATE "Fri Nov 24 16:01:11 2006") (VENDOR "COREM10LPHVT CORXM10LPHVT IOLIB_65_M10_CUP_FT_TEST_1V2 PRM10 splpll_16Kx8") (PROGRAM "Synopsys PrimeTime") (VERSION "V-2003.12-SP1-3") (DIVIDER /) // OPERATING CONDITION "Best::Best" (VOLTAGE 1.32::1.32) (PROCESS "0.8000::0.8000") (TEMPERATURE -40.00::-40.00) (TIMESCALE 1ns) ...

Thanks in advance!!! Regards, JL.

Reply to
spectrallypure
Loading thread data ...

Hi,

spectrallypure schrieb:

I think there are some changes in the preferences between both versions. I would start and use the same preferences. Second, there might be some changes in compilation result when using the same switches, as defaults changed. Check the release notes for 6.2e to see, if this is applicable in your design.

bye Thomas

Reply to
Thomas Stanka

Cut down your test bench, don't instantiate your device, see if you can confirm that SHIFTWR timing changes even without the synthesised netlist. I doubt it, but you will need to fix this first if you're right. If this really *is* the case, then there's almost certainly an error in your testbench, which will probably be either a race condition or a timing resolution problem. If it's not obvious (it should be), manually check the timing on whatever logic drives SHIFTWR. At some point, you should find that the numbers start diverging between 5.8 and 6.2. This will be very tedious, but you should manage it within a few hours.

You're in trouble if you don't understand race conditions. Google comp.lang.verilog; you'll find a huge number of posts on it.

If this is a school project, as I suspect it is, then you should probably give up. If it's a real project and you actually need a fix, then I'm afraid that you're probably going to have to pay someone to sort it out. Running PrimeTime and back-annotated ASIC timing sims is not a job for beginners. Reply if you're interested, and I'll send you my real email address.

Rule #1 when you get an error message you don't understand: Google it. Ther are some exact matches on your error message, which suggest that you might not have recompiled your simulation libraries when changing ModelSim versions. For ModelSim, you always need to recompile libraries when changing major version numbers.

/PJ

Reply to
Paul Jansen

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.