In ESNUG 238 jcooley@world.std.com (John Cooley) wrote:
> ... with the parts they cut within "( ... )", here's my quote...
>
> ("In engineering terms, I think Power Compiler is sexier than being
> the only guy stranded on a Pacific desert island with twenty Miss Nude
> Universes. It's that hot!") "This is a real breakthrough. This is
> the first real attempt at taking a proactive approach to doing low-power
> designs." ("I know designers who would freely give their first born
> child for something like this.") "I think this will be one of the
> hottest products of the year."
>
> Sometimes I get the sad, lonely feeling I'm not "Politically Correct"
> <sniff!> :^( - John Cooley, the ESNUG guy
From: burt@bnr.ca (Burt B. Christian)
John, When I read the above, I was not very pleased with it, to say the
least. About your feeling sad and lonely, I am glad that you are alone
in expressing yourself as you did. And I am wondering if you might be
misleading yourself in believing that you are a lonely politically
incorrect person, for the text in question has no political content.
While I know that you were only being light-hearted, I find the above words
excessively abhorrent and therefore feel compelled to exhort and check you.
It is a pity that some have allowed themselves to be debased so much that
they no longer find such thoughts and ideas abhorrent but take glee in
expressing them.
I appreciate the good judgement of the editorial staff at EE Times for
editing out the text in question.
- Burt Christian
Bell Northern Research
( ESNUG 239 Item 1 ) ---------------------------------------------- [4/96]
From: dblack@apple.com (David C. Black)
Subject: Verilint Saved My Tail With Synthesis & Cadence Verilog Simulation
Hey John,
Here's some actual Verilint output that has saved my tail. Note that neither
the readers in Cadence Verilog nor Synopsys synthesis caught these errors.
`define BLOCK 8'd256
module Example(
Control_i,
Field_i,
Addr_o,
Clk
);
input [7:0] Control_i;
input Field_i;
output [15:0] Addr_o;
input Clk;
reg [15:0] Addr_o;
always @(posedge Clk) begin :ALWAYS_BLK
// Advance by 0, 1 or 2 blocks
Addr_o <= Addr_o + (Control_i[5] && Field_i)
? (`BLOCK << 1)
: ((Control_i[5] || Field_i)
? `BLOCK
: 16'd0);
end//ALWAY_BLK
endmodule//Example
Imagine this code embedded in a large real life design. How long would it
take you to find the errors? What if you use `define for more complex
operations? Do you always remember operator precedences? Here's what
Verilint caught for me:
interHDL inc. Verilint (R) Version 3.12a (C) 1993-1996 interHDL inc.
Linked on Tue Mar 19 15:06:27 PST 1996
Processing source file d.v
(W530) d.v, line 20: A flipflop is inferred: Addr_o
(W19) d.v, line 21: Truncation of extra bits: 8'd256
(W19) d.v, line 23: Truncation of extra bits: 8'd256
(W446) d.v, line 20: * Reading from an output port: Addr_o
(W224) d.v, line 20: Multi-bit expression when one bit expression
is expected: Addr_o + (Control_i[5] && Field_i)
(W180) d.v, line 23: Zero extension of extra bits: 8'd256
Top level modules:
Example
End of interHDL inc. Verilint (R) Version 3.12a, 0 errors, 6 warnings
The first obvious though frequently overlooked error is 8'd256 which should
be changed to 9'd256. I sized the number to ensure Synopsys wouldn't treat
it as a 32 bit number and avoid a 32 bit adder. It was natural to think of
8 bits as holding 256 bits...oops!
The second error involves operator precedence of the ternary ?: function.
An extra level of parentheses should have been added. Here is the
corrected assignment:
Addr_o <= Addr_o + ((Control_i[5] && Field_i)
? (`BLOCK << 1)
: ((Control_i[5] || Field_i)
? `BLOCK
: 16'd0));
The other warnings are useful to synthesis.
I have built verilint into my makefile scripts as a go/no-go check for
simulation and synthesis. It runs extremely fast, and saves me hours of
debug. I always try to ensure that I understand every warning, and turn
off only a very few.
- David C. Black
Apple Computer
( ESNUG 239 Item 2 ) ---------------------------------------------- [4/96]
Subject: (ESNUG 238 #1) The Change_names v3.3b Command Is A Real Dog!
> John, when we run the change_names command in Synopsys on our whole chip
> (somewhere in the neighborhood of 60K - 100K gates), it goes *very* slowly.
> ... When I say very slowly, I mean that it renames 1 net every 3 or 4
> seconds! The command takes roughly 24 hours to complete. ... The best
> workaround for this is to create a Perl script to do the job on your
> Verilog netlists.
From: stereshk@marsha.sanders.lockheed.com (Stephen P. Tereshko)
John, we had similar problems running change_names... the remedy was to throw
the secret switch:
change_names_update_inst_tree = false
Change_names will no longer try to update instance specific attributes
and thus run much much faster.
- Steve Tereshko
Lockheed Sanders
---- ---- ---- ---- ---- ----
From: "Jon Saari" <jons@psdc.sps.mot.com>
Hi John,
If the design has many layers of hierarchy it may be beneficial to process
the change_names commands using a "foreach" loop. Change_names report files
with the -verbose option can get very large. Try turning off the "-verbose"
switch.
- Jonathan K. Saari
Motorola
---- ---- ---- ---- ---- ----
From: larky@brooktree.com (Steven Larky)
John, we use change names and I've occasionally seen it really slow down
(couple of hours, never a day!). The problem was that a few lower level
modules were looking for a library that we no longer used (old version)
although all the cells existed in the new library. My workaround was to
reset all the designs so they didn't have the old library pointers in them
(design reuse issue).
If that's not it, a second suggestion is to run the change_names command on
the sub-modules first. It runs a _lot_ faster. And then, with just a few
changes at the full chip level, the full chip change_names command goes
quickly as well. This works for us (>100K gates).
Oh, I don't use -verbose (I doubt that is the problem though).
- Steven Larky
Brooktree Corporation
---- ---- ---- ---- ---- ----
From: soroc@hail.mpd.tandem.com (Scott Smith)
John;
We too, at Tandem, have run into this problem of *very* slow processing with
the change_names command. We have seen this problem with all versions of
Synopsys since version 3.0c. Our workaround is:
1. Save the design as either verilog or VHDL from the design compiler.
2. Remove all designs from the design compiler (remove_design -all).
Or exit the design compiler and re-start it.
3. Read the newly written code (verilog or VHDL), not
the .db file, back into Synopsys.
4. Issue the change_names command.
It seems as though the .db file contains some attributes about the design
that are confusing the change_names command, thus the slow processing times.
By reading in the gate level netlist (verilog or VHDL) these design
attributes in the database are removed and the change_names command processes
the netlist fairly quickly.
- Scott Smith
Tandem Computers Inc.
( ESNUG 239 Item 3 ) ---------------------------------------------- [4/96]
Subject: (ESNUG 238 #3) Three Ways To Port From Synopsys To Cadence Dracula
> How do other users run layout verification (such as Dracula) on a design that
> was synthesized with Synopsys? Synopsys writes out Verilog and VHDL
> netlists, but it does not write out the CDL (similar to Spice) format which
> Cadence's Dracula prefers. I know of three ways around this:
>
> 1.) tell Synopsys to create schematics, translate the output to a schematic
> tool (such as Viewlogic) through EDIF, then write out the CDL/Spice
> netlist from Viewlogic.
>
> 2.) use the Verilog netlist reader in Dracula's LOGLVS.
>
> 3.) write a home grown NAWK/C/Perl tool to translate the verilog netlist
> into CDL/Spice format.
From: jons@psdc.sps.mot.com (Jon Saari)
Hi John,
Here at our design center we use method number 1 as well ( however, we use
Cadence's Design Framework ). We have CDL views in our technology file, and
we dump a CDL/Spice netlist for verification.
- Jonathan K. Saari
Motorola
---- ---- ---- ---- ---- ----
From: Don Reid <donr@hpcvcdo.cv.hp.com>
John, We also had problems with the Verilog reader in LOGLVS. We use
our own netlist translator to write CDL/Spice.
- Don Reid
Hewlett Packard ICBD
( ESNUG 239 Item 4 ) ---------------------------------------------- [4/96]
From: oren@waterloo.hp.com (Oren Rubinstein)
Subject: "write_timing -f sdf -con verilog" w/ "change_names" Doesn't Work!
Hello, John,
In order to accomodate some layout tools, we restrict the names to 32
characters, by running change_names. As a result of the truncation, some
cells and nets, that originally had different names, end up with the same
name. I did a "write -hier -f verilog -o filename" and Synopsys appends a
"_inst" to the cells that have the same name as nets. (For example, I get
"zippy" for the net and "zippy_inst" for the cell.)
But this is done by the write command, not by change_names, and as a
result, the names are not updated in the .db!!!
I do "write_timing -format sdf -context verilog" to generate back-annotation
delays. Because the delays are generated from the .db, I get mismatches in
the SDF file!!!
The workarond is to remove all the designs, read the Verilog netlist back in,
and generate the SDF from that -- but in the process I lose all sorts of
useful data that is present only in the .db (for instance, the wire load
model to be used for each sub-block.)
- Oren Rubinstein
Hewlett-Packard (Canada) Ltd.
( ESNUG 239 Item 5 ) ---------------------------------------------- [4/96]
Subject: ( ESNUG 238 #6 ) Is Speedsim's DEC History A Customer Liability?
> Concerning your discussion about Speedsim where you mentioned that they did
> a lot of cycle-based simulation work while at DEC: how can we be sure that
> SpeedSim is not using Digital's prorietary technology? ... They would not
> be very happy about somebody selling this techonogy to their competitors.
> If I make a deal with SpeedSim today, can I get sued tomorrow by Digital?
From: dmcinnis@speedsim.com (Don McInnis)
John, regarding Digital's Proprietary technology: SpeedSim/3 is an entirely
new implementation of a cycle-based simulator. (It's called "/3" because
it's the third cycle-based simulator developed by the SpeedSim founders.)
We did legal due diligence before starting the company to insure that
SpeedSim did not violate any of Digital's intellectual property rights. By
comparison to DEC's internal Cycle simulator, SpeedSim/3: supports Verilog,
supports RTL constructs, uses a fraction of the memory, compiles & builds
almost 10X faster, and has run-time is about 3-5 X faster.
SpeedSim/3 is completely different simulator than Digital's.
- Don McInnis, CEO
SpeedSim
( ESNUG 239 Item 6 ) ---------------------------------------------- [4/96]
Subject: (ESNUG 238 #8) How To Synthisize Or Test For Glitchless Logic
> I'm wondering whether I can trust synthesis on generating logic that won't
> glitch in one mode of operation, when there is another mode of operation in
> which glitches are likely, and acceptable.
From: kenr@yarmouth.engr.sgi.com (Ken Rose)
John, my understanding is that glitchless operation is not generally
guaranteed for combinatorial decoding. Whether an output glitches or not
depends on how the Karnaugh map is reduced; if the transition from one state
to another fits within the same reduced term, no glitch. Otherwise, without
a covering term connected one reduced state to another, there is potential
for a glitch. Here's an example:
\ BC 00 01 11 10
------------------
A 0| 1 | 1 | | |
------------------
1| | 1 | 1 | |
------------------
We can express this (using sum-of-products) as A'B' + AC. This may glitch
if there is a transition from ABC = 001 to 101. The glitch can be eliminated
by the covering term B'C, but SYNTHESIS WILL NEVER GENERATE THIS COVERING
TERM. (The reason is this 3rd term is redundant, and Synopsys avoids
redundant logic.)
As Chuck pointed out one way to avoid the glitch is to use a flop, but
contrary to his assertion about performance, it is possible to use the flop
without introducing a performance penalty. Suppose, for example, I want a
signal to be asserted when count is 4. By using a flop, and setting the flop
to 1 when the conditions for the count to *become* 4 on the next rising clock
edge are met. (I would write an equation that sets the registered signal to
1 when the count is 3 and all the other conditions for the count to advance
are met.)
The other advantage of this approach is the outputs are actually available
faster by predicting them. In the conventional design, the output delay is
the sum of clk->Q for the counter and the prop delay through the combo logic.
With the registered design, the delay is only clk->Q, which may help if the
signal goes off-chip to other logic.
- Ken Rose
Silicon Graphics Inc.
---- ---- ---- ---- ---- ----
From: amonti@vim.tlt.alcatel.it (Aurelio Monti)
Hi John,
My view is quite pragmatic: I try to avoid situations with glitchy logic.
You could design a gray counter instead of a binary one. You could also
change the encoding from binary to gray using state Design Compiler's FSM
state machine algorithms.
I, too, would like a tool to tell me whether a signal is generated from
unsafe combinatorial logic. (Sometimes it is not straightforward to check
this contraint by hand -- especially when your design is quite complex.)
I know this actually exists on something like gate level designs (see for
example LSI-Logic CMDE 'Design Critic' tool), but I'd like something not just
from one ASIC foundry and that can run those checks at the RTL level.
- Aurelio Monti
Alcatel Telettra
( ESNUG 239 Item 7 ) ---------------------------------------------- [4/96]
Subject: It's Not Wise To Synthesize ROMs Using Design Compiler
> From: rray@msai.com (Russell Ray)
>
> Has anyone synthesized a ROM and had good success at getting as small a
> design as possible? If so, how did you do it?
>
> - Russell Ray
> Mitsubishi Semiconductor
From: jgais@wd.estec.esa.nl (Jiri Gaisler)
I used synopsys 3.2b to synthesize a 18 kbit ROM (900 x 22 bits). I first
tried synthesizing from VHDL, using a "case" statement with 900 entries.
This failed (of course?) due to insufficient swap space during synthesis
even though I had 300 MB swap available. I then generated a PLA file
instead, which was read in without problems. The initial gate count was
about 5,500 gates. Optimising with flattening and logical structuring took
it down to 3,300 gates, which I though was OK.
The main problem was place and route: the target device was a sea-of-gates
gate array with two metal layers. The vendor's place-and-route tool could
not handle a synthesized ROM very well. (I understod from the vendor that
the gate utilisation in the ROM block was below 20% !) Fortunately, our
vendor could insert hard macros into his base array, so we used a custom
ROM macro in the end.
I guess that the moral of the story is that you should check with your
silicon vendor whether they have experience from synthesized ROMs before
starting a design. The large connectivity of synthesized ROMs seems to be
a problem for some routing tools. Many vendors can provide composite arrays,
with macros for RAM and ROM, which can solve the problem. However, be aware
of that this could increase the NRE cost since a new base array might have
to be developed.
- Jiri Gaisler
European Space Research and Technology Centre
---- ---- ---- ---- ---- ----
From: simon@lsil.com (Simon Favre)
You should not be trying to synthesize ROM or RAM from RTL. Small register
files, maybe, but for anything beyond a few hundred gates, you may be MUCH
better off with a memory generated by your Silicon vendor. Many provide
memory compilers that generate the specific configuration you want from a
set of architechtural choices.
You should also be able to get a Synopsys model of the memory that will
allow optimization of the logic around the memory. Many will do this
for either gate-array, or standard-cell. Your NRE doesn't have to go up
if you are doing a gate-array, and you can get by with a small memory
generated from gate-array transistors. If you need the extra density of
a standard-cell memory squeezed into a gate-array, this usually adds cost.
The main problem with synthesized memory blocks is in P&R. This could make
the timing of the memory a nightmare. You could also end up inflating your
die size with all those random gates, when a compiled structure will fit
nicely. It never hurts to ask what's available.
- Simon Favre
LSI Logic Corp.
|
|
