Different Modelsim versions disagree in same backannotation!

[spectrallypure]

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):

http://images.elektroda.net/5_1169063659.jpg

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.

 

[Paul Jansen]

#1 - Why is one signal rising at 10264ns, and the other at 10263ns?
Trace them back, see where they differ; that'll be your answer.

#2 - Who wrote the relevant simulation models? Is there a race in
them?

#3 - Why are you set at 1ns resolution? Is this a *very* slow chip? I
bet your sim models are set to 1ps; I'd suspect a rounding problem
somewhere.

#4 - What do you get if you enable sdf warnings & errors?

#5 - Is anyone in comp.arch.embedded really going to know the answer
to this one?!

/PJ

 

[Kim Enkovaara]

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):

One possibility is a bug in one of the Modelsim versions. SDF annotation
at least in huge chips usually finds some problems in the simulation
engine. Timing engine errors and differences are really hard to track
usually. You need at least the Verilog standard at hand to consult exact
functionality. The differences are usually much bigger between different
simulator vendors, although all of them should behave the same way.

I would suggest to send a testcase to Mentor. They have more tools to
pinpoint what really goes wrong. Also check the simulation resolution
you are using, rounding errors might be different in different tool
versions.

I made a signoff with 5.8b and 6.2a, both of them had some minor
problems, and different signoff corners needed different simulator
version to work the same way as static timing analysis (which usually is
the golden model).

If you have very complex tristate/opendrain structures 5.8b might cause
different results compared to newer versions (5.8b results are the
incorrect ones). And some early 6.2 versions had some problems with
conditional timing checks.

Also if the design is small have you tried to compare nonoptimized, fast
and vopt flows. As far as I know vopt timing engine is a new one, and if
you use the fast flow the engine behaves differently (the old way).

Also if the design is small easiest way to compare the results is to
record all the signals during the simulation (add log -r /*) and then do
a wave compare in the newer simulator version. Then search from the
comparison the first difference. You might need to change the comparison
default limits to much higher values to complete the comparison
(millions of differences allowed).


--Kim

 

[Thomas Stanka]

Hi,

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

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

 

[spectrallypure]

Thanks so much for your reply, Paul. Here I add some information:

#1 - Why is one signal rising at 10264ns, and the other at 10263ns?

As I told before, i just can't figure out why there are differences in
the the timming of the signals. What puzzles me the most is that even
the signal SHIFTWR (which is generated by the testbench and has nothing
to do with the synthesized netlist whatsoever) changes its timming,
presenting its rising edge @ 8463ns and @ 8487ns, respectively. Clearly
this is unexpected behavior. I have no clue of what could be the reason
nor how to trace it back...

#2 - Who wrote the relevant simulation models? Is there a race in them?

Please excuse me for not been that proficient... I don't understand
what do you mean by "race". But I can assure you that the **very same**
testbech is being used in both cases.

#3 - Why are you set at 1ns resolution? Is this a *very* slow chip? I
bet your sim models are set to 1ps; I'd suspect a rounding problem somewhere.

We also think the problem might have to do with this. I just set the
resolution to 1ns because that is the value of the resolution of the
SDF files, but I have experimented by changing this value and the
timing of the waveform changes A LOT. However, I haven't been able to
make the simulation give the expected results by tweaking this
parameter. The operating frequency of the design is 50MHz.

#4 - What do you get if you enable sdf warnings & errors?

In 5.8b I get a lot (nearly 50,000) of the following warnings:

# ** Warning: (vsim-SDF-3262) ./DFM_TC_Worst.pt.sdf(<-SDF line number
here->): Failed to find matching specify timing constraint.

.... but the simulation works. On the other hand, in 6.2e, I get this
same error but a lot more times (something like three times more), I
additionally I get the following error (once again, I get it a lot of
times):

# ** Warning: (vsim-SDF-3261) ./DFM_TC_Worst.pt.sdf(<-SDF line number
here->): Failed to find matching specify module path.

I used the VERR command in the hope of finding an explanation for this
errors, but the descriptions of the errors give me no clue of what
could be their real cause.

THANKS A LOT ONCE AGAIN FOR YOUR HELP!!!

 

[Kim Enkovaara]

We also think the problem might have to do with this. I just set the
resolution to 1ns because that is the value of the resolution of the
SDF files, but I have experimented by changing this value and the
timing of the waveform changes A LOT. However, I haven't been able to
make the simulation give the expected results by tweaking this
parameter. The operating frequency of the design is 50MHz.

You should set the resolution to what the models expect, nowadays the
resolution is usually 1ps or 10ps. The models can behave incorrectly
if the resolution is not correct.

And also the SDF must be generated from the layout tools with the same
or better resolution. 1ns resolution for the SDF files sounds very
large, unless you use some exotic or old process. Even for 0.13u process
1ps resolution is sometimes too high in STA.

In 5.8b I get a lot (nearly 50,000) of the following warnings:

# ** Warning: (vsim-SDF-3262) ./DFM_TC_Worst.pt.sdf(<-SDF line number
here->): Failed to find matching specify timing constraint.

... but the simulation works. On the other hand, in 6.2e, I get this
same error but a lot more times (something like three times more), I
additionally I get the following error (once again, I get it a lot of
times):

# ** Warning: (vsim-SDF-3261) ./DFM_TC_Worst.pt.sdf(<-SDF line number
here->): Failed to find matching specify module path.

Normally you should not get any warnings or errors from the annotation.
They usually tell that the SDF is annotated to a wrong place or
simulation models do not match the synthesis models (library version
mismatch etc.). You should manually compare the SDF and the models to
see why the errors are there. I have seen usually warnings in special
analog cells, IO-testing structures etc. that are quite hard to model in
simulation.

50k errors is too much, <100 warnings for few gigabyte SDF sounds normal
figure. The tool might do things differently in error conditions
depending on versions.


--Kim

 

[Duth]

Hi,

I agree with Kim. You should not get any of the warnings that you are
getting in 6.2e and 5.8 either. Ensure that the annotation is happening
at the correct instantiation.

Additionally, have you tired to run the simulation using the -novopt
switch? The one major difference is that vopt is on by default in 6.2
versions.

I would not say that this is necessarily a bad thing to have vopt on,
although there could be some issues in the vopt algorithm and a simple
test to look at this is to disable the vopt, by using the -novopt in
both compilation and simulation commands.

Thanks
Duth

 

[Paul Jansen]

Sorry, I only check in here when I get really bored...

Thanks so much for your reply, Paul. Here I add some information:

As I told before, i just can't figure out why there are differences in
the the timming of the signals. What puzzles me the most is that even
the signal SHIFTWR (which is generated by the testbench and has nothing
to do with the synthesized netlist whatsoever) changes its timming,
presenting its rising edge @ 8463ns and @ 8487ns, respectively. Clearly
this is unexpected behavior. I have no clue of what could be the reason
nor how to trace it back...

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.

In 5.8b I get a lot (nearly 50,000) of the following warnings:

# ** Warning: (vsim-SDF-3262) ./DFM_TC_Worst.pt.sdf(<-SDF line number
here->): Failed to find matching specify timing constraint.

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