Synthesis with Design Compiler

Hi,

I'm a teaching assistant for a class that is using design compiler
W-2004.12 and we are having a couple of issues. Some of my students
are synthesizing code at two clock periods, say 15ns, and 10ns. Even
though all the constaints are met at both period, the 15ns code can be
connected to a test bench and simulate fine, while the 10ns code will
not simulate correctly. I suppose that the lower period could force
design compiler to use different optimizations which cause this
problem, but is have other people seen this behavior? The same has been
true for flattened and non-flattened code, sometimes one will work
while the other will not.

Thanks,
Ali

 

I met similar problem before. It was caused by some format of logic is
sensitive to uninitialized signals which propagated 'X's in design.
Believe it or not, synopsys can give two equivalent circuits one is
sensitive to the uninitialized signal, the other one is not.
The best way to figure out which portion is sensitive is to debug
gate-level netlist.
If you initialize all inputs and all flipflops have been reset, the
problem should be gone. But this is expensive way.

Nandy
www.nandigits.com
Netlist Debug/ECO in GUI mode.

 

Is there a way to tell the synopsys tool to only generate circuits that
aren't sensitive? Every flipflop in the design is being reset with a
synchornous reset at the start of the simulation, but the problem
presists.

Thanks,
Ali

 

No. The tool doesn't which signal will go X.
How do you debug your design? Do you dump waveform? Check the waveform
to find out if the failing is caused by 'X'.
The unknow X is most likely one. But there is still a lot of other
possible reasons. Debug the netlist with waveform dump is the best way
to figure out.

Nandy
www.nandigits.com
Netlist Debug/ECO in GUI mode.

 

[J o h n _ E a t o n (at)]

asaidi@gmail.com wrote:

Is there a way to tell the synopsys tool to only generate circuits that
aren't sensitive? Every flipflop in the design is being reset with a
synchornous reset at the start of the simulation, but the problem
presists.

Thanks,
Ali

Try this.

// synopsys sync_set_reset "Reset"



But remember that the original logic generated by synopsys is correct and will
work in silicon. The only issue is that verilog can't simulate it. If
you use this pragma then you force synopsys to give you different logic
that is either slower or bigger or both simply to solve a simulation
problem.

You may be better off using force statements to get your sims working.

John Eaton