Synthesis and gate level simulation

[Juan Ignacio Morales]

Hi,

I've been working with the openMSP430 a while, when I synthesize the design and try simulate it, X states propagate by many signals and i can't find the mistake.
However, when i run formal verification between RTL and netlist, it's succesful.  
I'm using Synopsys tools (DC and Formality), and simulation with Modelsim.

Thanks,
Ignacio

[Olivier Girard]

Hi Ignacio,

The formal equivalence tool will only make sure that RTL and nettles are formally equivalent from a logical point of view… so this does’t tell a lot about X propagation :-P

There are a lot of other reasons that could generate an X in your design.

The very first thing that you need to check is that your design is timing clean (check your DC reports) and that the target frequency that you specified in your synthesis flow is bigger or equal than the one generated in your test bench.

If all of these are fine, you could for example make sure that your memory model is fine (for example if you might generate hold violations if you use an use ideal memory model (i.e. the memory output is immediately updated with the clock edge).

If if all of these look fine, you have no other way than opening your waveform viewer and just track the X back to see who is generating it.

I hope this helps.

Cheers,

Oliv'

--
You received this message because you are subscribed to the Google Groups "openMSP430" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss_openmsp...@googlegroups.com.
To post to this group, send email to discuss_o...@googlegroups.com.
Visit this group at http://groups.google.com/group/discuss_openmsp430.
For more options, visit https://groups.google.com/d/optout.

[Johan....@ymatra.be]

Hi,

Some common causes we see in gatelevel simulations:
- I assume you are doing untimed (!) gatelevel simulations post-synthesis, make sure to add command line switches such as +delay_mode_zero; if you see setup/hold warnings, you are probably not running in untimed mode
- make sure any scan related ports that might get added are properly tied in your testbench (scan_mode, scan_enable)
- disable boundary opto and port inversion, so it will be easier to look at the MSP interfaces as that's most likely where things will first go wrong.
- disable clock gating as that's a major case of confusion when debugging the delay_mode settings (your clocks will get delta cycle delays etc...)
- have a good look at the RAM/ROM interface, sometimes things such as an OE will put the data bus in HighZ when deasserted and that's a guaranteed way of having X's
- try to fix things in RTL as much as possible; if you see X's in RTL sims, try to get rid of them as much as possible

Have a look at the X optimism/pessimism settings of your simulator, maybe they can be used to track the issue in RTL

[Juan Ignacio Morales]

Hi Olivier and Johan,

I'll discuss more details about my problem:

1- Target frequency is 25MHz, testbench freq. 20MHz.
2- There aren't timing violations
3- I synthesized a memory model like an array of flip-flops. This gate level with another RTL files, simulates ok.
4- I disabled gate clocking, scan related ports... I'm synthesizing the most simple version of openMSP430, like FPGA functionality
5- The option -no_boundary_optimization is set at compile
6- What are the X optimism/pessimism settings of the simulator?

The problem may be related to these warning?

Warning:  Starting with the 2000.11-1 release, the Presto Verilog reader treats Verilog 'integer' types as signed; synthesized result may not match earlier versions of HDL Compiler. (VER-314)
Warning:  ./rtl/verilog/omsp_frontend.v:186: signed to unsigned part selection occurs. (VER-318)

Warning:  ./rtl/verilog/omsp_mem_backbone.v:136: signed to unsigned conversion occurs. (VER-318)
Warning:  ./rtl/verilog/omsp_mem_backbone.v:138: signed to unsigned conversion occurs. (VER-318)
Warning:  ./rtl/verilog/omsp_mem_backbone.v:141: signed to unsigned conversion occurs. (VER-318)
Warning:  ./rtl/verilog/omsp_mem_backbone.v:143: signed to unsigned conversion occurs. (VER-318)
Warning:  ./rtl/verilog/omsp_mem_backbone.v:182: signed to unsigned conversion occurs. (VER-318)
Warning:  ./rtl/verilog/omsp_mem_backbone.v:183: signed to unsigned conversion occurs. (VER-318)

Warning:  ./rtl/verilog/omsp_sfr.v:240: signed to unsigned assignment occurs. (VER-318)
Warning:  ./rtl/verilog/omsp_sfr.v:246: signed to unsigned assignment occurs. (VER-318)
Warning:  ./rtl/verilog/omsp_sfr.v:247: signed to unsigned assignment occurs. (VER-318)

Warning:  ./rtl/verilog/omsp_multiplier.v:351: unsigned to signed assignment occurs. (VER-318)
Warning:  ./rtl/verilog/omsp_multiplier.v:352: unsigned to signed assignment occurs. (VER-318)
Warning:  ./rtl/verilog/omsp_multiplier.v:359: signed to unsigned part selection occurs. (VER-318)

Warning:  ./rtl/verilog/omsp_dbg.v:743: DEFAULT branch of CASE statement cannot be reached. (ELAB-311)

These are the only warnings that DC reports.

Thanks for your suggest!

Ignacio

[Olivier Girard]

Hi Ignacio,

The warnings you see in DC are perfectly okay (of your formal equivalence check also proves that :-P ).

Now, to repeat my first email, I think your best option now is to just open your favorite waveform viewer and track the X back to see who is generating it.

Cheers,

Oliv'

[Juan Ignacio Morales]

Hi,

I found two causes for X propagation:

1- setup/hold time violations. I fix them by modifying behavior cell libraries.
2- the omsp_sync_cell module. Using this cell in RTL and gate level of rest of project, the simulation works.

I prove this module (gate level) alone and it works, but with the openmsp it fails.

[Johan....@ymatra.be]

Hi,

No offense, but you are doing the wrong thing here; after synthesis, you should not be concerned with setup and especially not with hold violations.
The synthesis netlist from DC is by no means a valid ASIC design, for that you'd need to go through full place and route to e.g. Insert the clock trees that will have a significant impact on setup and hold violations (synthesis should never attempt to fix hold!); also post P&R you can extract parasitics (RC etc) that will also impact timing.

After synthesis, you should simulate *without* timing checks (see my previous comment on simulator switches such as delay_mode_zero) as it is a given that timing is totally unrealistic after synthesis (disclaimer: setup timing is surely indicative for what you might get after layout)

I hope this clarifies some things.

Cheers,
Johan

[Juan Ignacio Morales]

Hi Johan,

Thanks for your advice. I'm a newbie in this area and i read many differents ways to test synthesis results. I previously simulated synthesis netlist without timing checks, like you said, but x's propagates yet. For this reason, I modified behavior cell libraries and tested every modules of the project.
I found that errors begins at memories, they don't have initial values and propagates x's. Changing this, it works!

Thank you all,

Ignacio