Editor's Note: When you're submitting stuff for publication on ESNUG,
please use newlines and don't let your line length go wider than 77
characters. A number of readers can't get e-mail wider than 80 characters
and a 77 width allows for quoting. Also, do not use tabs; your tab
setting ain't the same as everyone else's! Thanks.
- John Cooley
the ESNUG guy
(and ASIC Design Consultant!)
( ESNUG 134 #1 ) -------------------------------------------------- [7/93]
Subject: (ESNUG 133 #1) "Want Verilog/VHDL to SPICE/HSPICE translator"
> do you know of any available translators to get my netlist out of
>Design Compiler and into HSPICE format? i do not want to generate a
>schematic in Cadence/Mentor/Viewlogic in order to accomplish this.
>
> ideally, it would also support hierarchy. possibly an "EDIF 200"
>or Verilog to SPICE converter.
From: fdme@sh.alcbel.be (Frank De Meersman)
We had the same request two years ago, and Cadence has some routines that
work via the verilog PLI routine, and that translate a verilog netlist
to Spice and a verilog netlist to a netlist for Dracula Verification (CDL).
I think that if you contact the people from Cadence UK, you will get more
infomation.
We personnally are using this translator quite often to translate the
verilog netlist into a netlist for Dracula, as long as we still encounter
small problems with the Verilog input in Dracula.
Concerning a VHDL to Spice translator, I am not not aware of the existence
of any translator, although I would like to get this one if it would exist.
I heard that Cadence might have some plans for writing a general netlist
based translator, and this would then accept also VHDL as input , and
generate some Spice like netlist. But I have no idea whether there are
already any commitments about this.
- Frank De Meersman
Alcatel - Bell
( ESNUG 134 #2 ) -------------------------------------------------- [7/93]
Subject: (ESNUG 133 #4) "Test Compiler"
>(Synopsys version: 3.0a-10063)
>
>After running insert_test there is a very high fanout on the
>test scan enable (test_se) signal. The Test Compiler manual
>recommends running 'compile -incremental' which is a very slow
>procedure for a large design. Is there a faster way to do this?
>I don't want it to consider every net - it just needs to fix
>test_se. (Can I dont_touch everything except this net? How?)
>
>It's interesting to note the Test Compiler manual states: 'If a
>design has no design-rule constraint violations before you add
>scan-test circuitry, it usually has no design-rule constraint
>violations after you add scan-test circuitry.'
>
>Except for on test_se that is....
From: brooks@dvs.com (Walter Brooks)
"Procedure to fix fanout on test_se"
What I did to fix this problem was to put dont_touch on the top level
modules. Usually our designs contain a number of top-level blocks that
are connected by a number of buses. By dont_touching the large modules,
the compile time is greatly reduced (no options to the compile).
Synopsys will buffer the test_se signal to the modules. If the fanout
is still too large, find the module with the most fanout, descend into
it, and then follow the same procedure until your fanout is ok. Also,
make sure the drive strength of your inputs are specified (I think
infinite strength is the default?????).
This also has the effect of fixing any module to module fanout problems
for other signals, without taking alot of compile time.
Hope this helps!
- Walter Brooks, Digital Video Systems
A Division of Scientific Atlanta
( ESNUG 134 #3 ) -------------------------------------------------- [7/93]
Subject: (ESNUG 132 #1) "Working with MUXes using Verilog and VHDL"
> Where did my mux go? Why can't the tool infer my 32 to 1 mux structure?
> The tool is broken!!! How many times have your found yourself in this
> situation when you have been using Design Compiler / VHDL Compiler?
>
> Many users write HDL code with the intent of inferring or synthesizing to
> multiplexers only to find combinational logic in the resulting circuit.
-- -- -- -- -- --
From: rbirch@convergent.com (Robert Birch)
"Where did my mux go?" is asked of the hotline. i often wear the hat of
a CAE tool guru here at Unisys, and i've heard the same question countless
times myself. But i am also trying to get ASIC's out the door, and i know
the other questions leading up to "Where's the mux?" The real issue is,
"Why does the 32 to 1 mux from synthesis take 10 ns when the data book shows
me it should be under 5?"
If a synthesis result is functionally correct and meets our critical
constraints, we will never notice which gates were used in the resulting
circuit.
As for functionality, i have never heard of Synopsys creating logic which
is not logically correct; i don't even question it anymore.
The functional problem caused by the lack of mux'es is that the synthesized
random logic will probably propagate unknowns in cases when a mux would not.
This problem is similar to the syncronous reset issue which has recieved so
much attention in ESNUG. Reset has been addressed in version 3, but i don't
believe anyone has looked at the global problem. We need a way to control
the propagation of unknowns. i haven't thought a lot about how this should
be done, but we did run in to a show stopper with this one time. We had some
muxes to reconfigure our scan chain depending on if we were in JTAG mode
or ATPG mode. These muxes were "optimized" into some sort of random stuff,
and our scan chains would not work unless the chip was first reset. This was
a case where we resorted to inferring muxes with a Verilog function.
Timing is the area where i'm most concerned about the treatment of muxes.
A couple of weeks ago, a colleague had a module which was a 64-bit wide
8 to 1 mux. The critical path was the data, and the area was unconstrained.
The synthesis result violated the maximum delay constraints; it had a data
path over 5 ns. If we had instantiated our own muxes, that delay should have
been more like 1 ns.
What really bothers me about all of the theoretical hand-waving in this article
trying to justify Design Compiler's decisions is that all of the comparisons
are based on area. The optimal solution, as the author points out, is the one
with the lowest gate count. It sounds like what is being said is that a design
decision is being made (and a whole class of solutions being discarded) by the
Synopsys program with no regard for user-specified design constraints.
The user says, "Give me a solution which runs at my system clock speed; i don't
care how big it is." Design Compiler's replies, "The fast solution was too
inefficient; take this instead. All you have to do is slow down your system
clock and it will work just fine."
Perhaps we should ask Synopsys to provide a new variable, "compile_elegance".
Running with compile_elegance = HIGH would allow DC to apply all of its
synthesis strategies as they are presented in the Journals, while setting
compile_elegance = LOW would let us have muxes with constant or redundant
data paths which meet our timing requirements.
- Robert Birch
Unisys, San Jose
-- -- -- -- -- --
From: chana@roadrunner.pictel.com (Allen Chan)
>always @ (d3 or d2 or d1 or d0 or c1 or c0) begin
> y <= mux4 (d3,d2,d1,d0,c1,c0);
good post, but one minor issue: this is an incorrect model of a mux. this
model implies that you should re-evaluate the always statement when any
data input changes, even if that particular data input has not been
selected. in the similuation of large designs, this needless re-evaluation
can cost you lots in CPU usage.
- Allen Chan
PictureTel
( ESNUG 134 #4 ) -------------------------------------------------- [7/93]
From: yoshino@lsil.com (Toshiaki Yoshino - 7064)
Subject: It Initializes in VHDL But Not After Synthesis
Hi, John
We design and simulate chips based on VHDL -> Synopsys -> Lsim (LSI Logic's
simulator) flow. We have found that Synopsys sometimes generates a netlist
which contains UNINITIALIZABLE registers. (we found this when we are
running Lsim).
Have you heard similar reports?
This happens when we compile with "-map_effort high" option.
The way we describe register is
WAIT UNTIL (CLK'event and CLK=F1);
if (RESET=F1) then
Q <= f0 ;
else
if (selA=f1) then Q <= AIN; -- load A input
elsif (selB=f1) then Q <= BIN; -- load B input
else
Q <= Q ; -- keep the prev. state
end if;
end if;
The register must be initialized when RESET is "F1"(high). It works fine
with our VHDL simulator (Vantage). But it cannot be initialized in the
actial netlist.
- Toshiaki Yoshino
LSI Logic
( ESNUG 134 #5 ) -------------------------------------------------- [7/93]
From: markg@cyrix.com (Mark Greenberg)
Subject: Modelling Muxes
John, I've been building the stdcell library at Cyrix and I'm having
trouble trying to specify the function for a decode-mux cell. The cell
has 4 inputs & 4 select lines, with one select line on at a time,
selecting an input. The function is:
a & ( sa & !sb & !sc & !sd) | b & (!sa & sa & !sc & !sd) |
c & (!sa & !sa & sc & !sd) | d & (!sa & !sa & !sc & sd)
The above function is correct with one select enabled, but if I use this
specification, Synopsys could use the cell to generate 0 by having more
than one select high. I need to convey the illegal states of 0 selects
high and more than 1 select high.
I found a 3 paragraph description on the tri_state attribute which looks
promising. I could enumerate the illegal states and have them as the
function for the tri_state statement. This would probably be okay,
though Synopsys may elect not to use a tristate cell in combinational
logic.
Does anyone have any ideas?
- Mark Greenberg
Cyrix Corporation
|
|
