1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Different Modelsim versions disagree in same backannotation!

Discussion in 'Embedded' started by spectrallypure, Jan 18, 2007.

  1. 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.
     
    spectrallypure, Jan 18, 2007
    #1
    1. Advertisements

  2. spectrallypure

    Paul Jansen Guest

    #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
     
    Paul Jansen, Jan 18, 2007
    #2
    1. Advertisements

  3. Hi,
    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
     
    Thomas Stanka, Jan 19, 2007
    #3
  4. 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...
    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.
    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.
    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, Jan 20, 2007
    #4
  5. 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.

    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
     
    Kim Enkovaara, Jan 22, 2007
    #5
  6. spectrallypure

    Duth Guest

    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
     
    Duth, Jan 23, 2007
    #6
  7. spectrallypure

    Paul Jansen Guest

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

    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
     
    Paul Jansen, Jan 23, 2007
    #7
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.