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

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.

#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

spectrallypure wrote:
> 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

Hi,

spectrallypure schrieb:

> 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

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!!!

spectrallypure wrote:
>> #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.

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.


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

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

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


Kim Enkovaara wrote:
> spectrallypure wrote:
> >> #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.
>
> 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.
>
>
> >> #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.
>
> 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

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

On 20 Jan 2007 10:43:16 -0800, "spectrallypure" <jorgelagos@gmail.com>
wrote:

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

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