Editor's Note: There been some very interesting developments this week in
the physical synthesis race. In this week's EE Times On-line, the DSP
division of Texas Instruments just announced it completed a tape out of
a 250 - 500 kgate design using PhysOpt. (Cool! EE Times had just
confirmed my scoop of the TI/PhysOpt tape-out in my SNUG'00 Trip Report!)
See http://www.eetimes.com/story/OEG20000503S0018
What's more interesting is what the article said about Monterey:
"TI's DSP group has signed an agreement to use Dolphin on 0.18-micron
and smaller geometry designs. The agreement marks a major design
win for Monterey, which describes Dolphin as offering a complete
placement and routing solution."
This almost seems to imply that TI DSP favors Monterey over PhysOpt. But,
because there is no Monterey / TI DSP tape-out story, it's hard to tell
if this is just empty lip service (like how TI ASIC "endorses" Magma) or
the start of a real business relationship. Time will tell...
On the Cadence front, the PKS marketdroids got a really impressive big
gun backing them in this very ESNUG 351 #1 with Jay McDougal of Agilent.
I'm sure the Cadence guys are just giddy to get Agilent. I could care
less. What impressed me was getting Jay McDougal. He's written in ESNUG
since the very early days -- he wrote in the 12th ESNUG back in early
1992. (ESNUG starts at ESNUG 40; Jay wrote in ESNUG 52.) Jay also wrote
one of the top three papers at SNUG'96. It was titled "Creating & Using
Custom Wireload Models". Jay also presented a paper at DesignCon'99
titled "Achieving Timing Convergence Between Synthesis And Place & Route".
Very impressive, Cadence PKS marketdroids, VERY impressive!
- John Cooley
the ESNUG guy
( ESNUG 351 Subjects ) -------------------------------------------- [5/4/00]
Item 1 : One Engineer's Comparison Of Cadence PKS 3.0.13 To "PKS-II" 3.0.15
Item 2 : ( ESNUG 348 #4 ) More User Comments On LogicVision's memBIST-IC
Item 3 : De-Glitching TransEDA's VeriSure Causes A 3X Sim Performance Hit
Item 4 : Three Letters Correcting Cooley's SystemC vs. Cynlib Comparision
Item 5 : ( ESNUG 348 #8 ) Run Synopsys DesignPower w/ Cadence NC-Verilog
Item 6 : ( ESNUG 348 #10 ) A Good EMACS Set-up For Use With dc_shell-mode
Item 7 : ( ESNUG 347 #1 ) Reactions To Cliff's Nonblocking Verilog Paper
Item 8 : Formality, Chrysalis, Verisity, and Cadence's Model Checking Tools
Item 9 : Censorship, InterHDL, Hitler, Stalin, God, LSI Logic, & Gerry Hsu
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
( ESNUG 351 Item 1 ) ---------------------------------------------- [5/4/00]
From: Jay McDougal <jay_mcdougal@agilent.com>
Subject: One Engineer's Comparison Of Cadence PKS 3.0.13 To "PKS-II" 3.0.15
Hi John,
I don't have the time to give you a detailed description of my use of PKS.
However, I will state some basic info from my use to date that may be
interesting/useful to the ESNUG readers. First of all, I will refer
to several versions of PKS. PKS-II is really a marketing name for versions
of PKS after 3.0.13. PKS-II is not a new/seperate product with its own
seperate license file; it's just revs of PKS (after 3.0.13) with the latest
patches and features. My latest work has been with 3.0.15.
I have run PKS myself with support from Cadence during my initial training.
At first, Cadence took one of our designs (a 200 Mhz, 170 Kgate, 0.25um
ColdFire-4 processor core) and ran it through PKS for us in July of '99.
Their results looked encouraging, so I decided to run PKS in house to
reproduce their results and try it on a few other ARM/ColdFire processor
cores. Synopsys PhysOpt was still not available on HPUX in this timeframe
(Oct 99), and all the other physical synthesis tools were not even offered
by their vendors except in a "we will run it for you" (Taxicab) model.
I have been running PKS off & on since then on ARM & ColdFire cores.
None of the 4 ARM/ColdFire cores I have completed with PKS have been
released into a production ASIC. We expect the first ASICs that use these
cores, produced using PKS, to release this fall. Here are the basic things
I have seen in my evaluation/use of PKS.
The Good Things:
1) I had little/no issue with correlation of the PKS timing engine
and the timing engine used in Silicon Ensemble (SE).
2) For designs that are lightly congested PKS is able to give me better
timing in a single pass than we had achieved in 6-10 IPO/ECO iterations
on the same design using Synopsys with SE. Results compared to using a
single pass SE with a QPopt/PBOpt flow were mixed with some savings in
cell area and about the same timing results. The end results after
routing were within 2-3 percent of the PKS estimates.
3) Getting our library physical and timing info into PKS was easy, if you
have a SE and Synopsys background/history. Just take a Synopsys .lib
and compile them to make your PKS .alf file.
4) In cases where I was really pushing the clock frequency, PKS run times
were dramatically longer than standard RTL-with-wireload synthesis
runs. We use both Ambit RTL and DC synthesis here in Corvallis. The
200 Mhz, 170 Kgate, 0.25um ColdFire-4 processor core would take about
14 hours using wireload models with Ambit RTL or Synopsys DC (didn't
matter which we used.) But since it's wireloads, I know it would
really be 160 Mhz or less instead of the promised 200 Mhz, unless
I did lots of timing driven place & route, PBopt, etc. A PKS run
on the same design at 192 Mhz takes 21 hours (1.5X standard synthesis.)
To get up to my target 200 Mhz, PKS takes 42 hours (3X standard
synthesis.) However, most of this time is spent getting the last few
tenths of a nanosecond that we were never able to get with our regular
synthesis/place/route flow. Also, this extra time is insignificant
compared to the time required to run even a single IPO/ECO loop.
The Not So Good Things:
1) PKS (3.0.13 and prior) did not accurately account for pre-placed cells,
layer obstructions, and power rings. It would place things on top of
these pre-placed parts and obstructions. There are ways to work around
this, but it caused difficulty and innacuracy in the PKS congestion
estimates.
The latest releases of PKS (3.0.15) have resolved this. Pre-routes,
obstructions, etc. are handled well now; it sees them. PKS does an
initial place with its own placer. These placements typically overlap
each other in bins. Run Qplace to clean the bins. Typically I'll have
to interate between PKS and Qplace twice. After the second Qplace
call, you then call WarpRoute, and you might then interate between
PKS and WarpRoute a few times. If you're not congested, you don't
need to interate much because WarpRoute is very Steiner.
2) With medium to highly congested designs, PKS routability estimates
were not accurate. In the worst cases, PKS was unable to optimize the
design without growing our original floorplan even though we knew it
was routable in SE. In other cases, it lead to non-convergence because
there was up to a 25 percent difference between PKS timing estimates
and final WarpRoute back-annotated timing after routing. This was
mainly due to over-congested areas that had to be routed around. PKS
did not do a good job of predicting the routing/timing in these areas
and the additional RC delay trashed timing.
This is partially addressed with PKS versions 3.0.15 and beyond. The
routing estimates for congested designs are still off. The global
route portion of the Warp router has been integrated into PKS, but the
final route part of WarpRoute is not integrated into PKS yet. These
enhancements allowed me to achieve timing convergence with most
congested designs. However, with very congested designs it required
3-4 iterations between calling the integrated Warp global router and
doing incremental timing/placement optimizations.
My suspicion is that this type of convergence with may not always be
possible and that convergence is not guaranteed. The potential
problem is that after each incremental timing/placement iteration, a
new global route must be performed (not incremental). This can create
new (unanticipated) problem nets in congested areas. In my case these
nets converged to a stable set and the incr timing optimizations were
able to fix all of them without any new global route suprises after
3-4 iterations. The WarpRoute global routing algorithms aren't the
same as the PKS global routing algorithms so their estimates still
often differ significantly. The more congested the design, the worse
this gets.
3) PKS documentation isn't a strong point. No useful design methodologies
are documented, just the basic command stuff and vanilla flows. I had
to discover (with lots of help from my AE) most of the real world PKS
techniques.
4) Clock tree generation and scan insertion are not well integrated into
the PKS flow and require a patch process where we leave PKS. This
means moving large data files back and forth and potentially handing
off or synchronizing with another designer. Once outside PKS, we run
our in-house scan insertion tool and then create buffer trees for
the clocks and scan control signals (using CTgen inside SE.) Then,
you have to reload the whole physical design back into PKS for final
timing optimization.
In conclusion, PKS is working well for us for timing convergence. We've
purchased two copies and will be using them for production work.
- Jay McDougal
Agilent Corvallis, OR
( ESNUG 351 Item 2 ) ---------------------------------------------- [5/4/00]
Subject: ( ESNUG 348 #4 ) More User Comments On LogicVision's memBIST-IC
> 3. memBIST-IC inserts the mbist into the netlist. This has both positive
> and negative implications. Positive: Verilog porting does not need to
> be fixed through the hierarchy (the BIST adds several new ports).
> Negative: the "golden" RTL code must be frozen and the mbist inserted
> to generated the "operating" RTL code for simulation and layout.
From: Jeff Hung <jeffhung@silicon-spice.com>
Hi John,
Regarding the LogicVision memBIST-IC tool, nothing says you *have* to let it
(or more specifically, designAssemble) insert the RTL. For precisely the
reasons this designer cites, we chose to have our designers insert the
memory collars.
One feature I really wish LogicVision had is an option to pick between a
"collar" and something more like a "BIST interface". Having the collar
structure instantiate the memory sometimes didn't work in our methodology.
What we really wanted was an interface in front of the memory to handle the
BIST and functional signals. So pretty much by hand, we had to change it
from a "collar" to "interface". This ugly task is compounded by the
incredibly ugly generated code for the collar. But basically we did it
once and then forgot about it.
This approach had a number of side effects of course. After we went down
this road, we never used their synthesis scripts, nor their testbench. We
kind of had to migrate stuff into our flow, but it wasn't that bad. For
instance, because of the extremely simple controller protocol I generated
the testbench in VERA in minutes.
> 6. memBIST-IC can handle parallel or serial mbist with the number of
> comparators specified by the user. Mentor's MBistArchitect can only
> handle full parallel mbist.
This right here is the deal-breaker for us. Wire congestion was already a
problem, and full parallel bist would have been unacceptable. We used only
a handful of comparators.
What I really liked was the ease in customizing the OperationSet for an
individual memory. Since we really did want to run at speed and test time
wouldn't be a huge issue, we could modify the OperationSet to support
pipelining, and re-run the tool to get a new BIST controller. Otherwise
decoding what's going on inside the BIST controller and trying to modify it
would be a trememdous pain, given the obtuse generated controller code.
I'm sure it's that way on purpose.
In summary, we were reasonably happy with the size and wiring of BIST from
LogicVision. However, after generating the controller/collar RTL, we
pretty much went our own way.
- Jeff Hung
Silicon Spice, Inc.
( ESNUG 351 Item 3 ) ---------------------------------------------- [5/4/00]
From: Dan Joyce <dan.joyce@compaq.com>
Subject: De-Glitching TransEDA's VeriSure Causes A 3X Sim Performance Hit
Hi, John,
There is an problem we found with the TransEDA's VeriSure code coverage tool
almost 2 years ago, that appears not to be unique to this tool. VeriSure
made a fix for it, but have not rolled that fix into their mainline tool (at
least not in the default mode) because of a 3X simulation performance cost.
I think their mainline tool does now finally have the ability to turn on the
"deglitch" feature that will solve this problem.
The problem has to do with coverage analysis of lines in combinatorial
always@ constructs - always@(signal_list). Since these constructs are
entered each time one of the signals in the signal_list changes, they get
executed several times per clock if several of the signals change. The
problem is that only the last time through the always@ - before the next
clock - really gets simulated. T his is because only the output settings
made on the last pass are clocked into DFFs. This can lead to false
positives in your coverage data.
Lines of code that show many executions can actually be completely
unverified by your tests!!!
Code in "always@(posedge Clock)" constructs are immune to this problem since
they are only executed once per clock. The part that really concerns me is
that much of the most important code in my Verilog HDL is written in
"always@(signal_list)" loops. Namely my state machines! This is where I
use code coverage first, and where I find it most useful. If you are
writing code for high performance designs, you usually need to generate
Mealy outputs from your state machines (outputs dependent on state variables
AND inputs.) With Mealy outputs it is much easier to describe the outputs
and next state outputs in an "always@(signal_list)" loop, and then send the
state variables and Moore outputs to "always@(posedge Clock)" and clock them
into DFFs separately.
This problem is with VeriSure at or before version 4.200B1. We saw the
false positives using Cadence Verilog-XL as the simulation engine. I
cannot tell if the problem still exists because we have solved it for
ourselves by turning on the "deglitch" feature in our VeriSure.par file.
To turn on Deglitch feature in VeriSure.par file with a time unit of 1
vsinstrument deglitch_compatible on
vssimulate deglitch_time 1
You can see if your VeriSure version has the deglitch feature supported by:
1. set up VeriSure as normal.
2. type vsinstrument -help
3. from the resulting messages check for "deglitch_compatible"
Unfortunately, I have not been able to turn "deglitch" off correctly and get
a good run. And I don't have any time to work on it.
My advice to others, especially if you are using Verilog-XL, or if you
suspect you are getting false positives in combinatorial always@'s
(always@(signal_list)), would be to run this code snippet:
module test1(
);
reg clk;
reg [4:0] register;
reg [4:0] register_next_state;
reg error;
reg error_next_state;
reg [11:0] count;
initial begin
//$dumpvars;
register <= 0;
error <= 0;
clk <= 0;
count <= 0;
#20 clk <= 1;
end
always@(clk) clk <= #20 ~clk;
always@(posedge clk) begin
count <= count+1;
if (count == 12'hfff) $finish;
end
always@(register) begin
if(register[0]) register_next_state = 5'b00000;
else register_next_state = 5'b11111;
case(register)
5'b00000 : error_next_state = 0;
5'b11111 : error_next_state = 0;
default : error_next_state = 1; // line should show NO coverage!
endcase
end
always@(posedge clk) begin
register <= register_next_state;
error <= error_next_state; // This line should show no coverage!!!
end
endmodule
While taking a VERA class at Synopsys, I had a CoverMeter AE run this code
on CoverMeter using VCS as the simulator. This showed no coverage (worked
correctly). I would like to see CoverMeter running Verilog-XL however.
- Dan Joyce
Compaq Computers
( ESNUG 351 Item 4 ) ---------------------------------------------- [5/4/00]
Subject: Three Letters Correcting Cooley's SystemC vs. Cynlib Comparision
> Here is an example for an adder that adds a + b then registers the output
> to register c in both Synopsys SystemC and CynApps CynLib:
>
> a --->|--| temp -----
> |+ | ------>|reg|----> c
> b --->|--| -----
> |
> clock -------------
>
> Synopsys SystemC CynApps Cynlib
> ---------------- --------------
>
> #include "systemc.h" #include "cynlib.h"
>
> struct adder_reg : sc_module { Module adder_reg (
> sc_in<sc_int<8>> a; In<8> a,
> sc_in<sc_int<8>> b; In<8> b,
> sc_out<sc_int<9>> c; Out<9> c,
> sc_in<bool> clock; In<1> clk )
>
> // internal signal Always (Posedge(clk))
> sc_signal<sc_int<9>> temp; c <<= a + b;
> EndAlways
> // adder process EndModule
> void add() {temp = a + b;}
>
> // register update process
> void reg() {c = temp;}
>
> // Constructor
> SC_CTOR(adder_reg) {
> SC_METHOD(add);
> sensitive << a << b;
>
> SC_METHOD(reg);
> sensitive_pos << clock;
> }};
From: [ A Synopsys SystemC CAE ]
Hi John,
Since you are comparing SystemC with CynApps, please compare apples to
apples and not different style, as you did in your example. Please
publish the following correction:
Synopsys SystemC CynApps Cynlib
---------------- --------------
#include "systemc.h" #include "cynlib.h"
SC_MODULE(adder_reg) { Module adder_reg (
sc_in<sc_int<8>> a; In<8> a,
sc_in<sc_int<8>> b; In<8> b,
sc_out<sc_int<9>> c; Out<9> c,
sc_in<bool> clock; In<1> clk )
void add() {c = a + b;} Always (Posedge(clk))
SC_CTOR(adder_reg) { c <<= a + b;
SC_METHOD(add); EndAlways
sensitive_pos << clock; EndModule
}
};
I'd like to point out the flexibility of the coding style with SystemC
in terms of data types and modeling hierarchy. This flexibility comes of
course with the problem that one can use different styles to model the
same thing. However if we compare to other libraries, we should make
an effort to show the same style. Otherwise any comparison looses
credibility in my eyes.
And I found another even worse mistake in your email. The following is
simply wrong:
> Both C-based design systems require their own special pre-processors to
> make the macros they use actual true GNU gcc compile-able; it just appears
> that CynApps pre-processor "Cyn++" is more adapted to having engineers
> write C psuedo-code that's very Verilog-like. See http://www.cynlib.com
SystemC doesn't need a preprecessor. Where did you get this information?
It is wrong!!! Only CynApps needs their own proprietary preprocessor.
SystemC can be compiled as is with a standard C++ compiler.
- [ A Synopsys SystemC CAE ]
---- ---- ---- ---- ---- ---- ----
From: Kurt Schwartz <kurt@whdl.com>
Hi, John,
I was amused by the comparison given of SystemC to Cynlib. In the interest
of providing a little more realistic comparison, I'd like to make two
points:
1) The SystemC example gratuitously used two processes where one would
have been sufficient.
2) Download the free Cynlib software and try to compile the Cynlib
example: OOPS - it won't compile. Why? Because it uses a special
Verilog-like syntax that requires a proprietary ($$) pre-processor
to translate the code into C++.
Note that SystemC does use macros to hide C++ implementation details, but
these macros come with the free download and do not require a proprietary
pre-processor.
- Kurt Schwartz
Willamette HDL, Inc.
---- ---- ---- ---- ---- ---- ----
From: David Chapman <dchapman@aimnet.com>
John,
Great review, even if I couldn't understand some of it - I work mostly in
low-level physical design these days.
I'd like to point out what looks like a typo in your SystemC example:
> Synopsys SystemC CynApps Cynlib
> ---------------- --------------
> ...
> struct adder_reg : sc_module { Module adder_reg (
> sc_in<sc_int<8>> a; In<8> a,
If in fact SystemC is to use ANSI C++, the line on the left should be:
sc_in<sc_int<8>> a;
Notice the extra space! Because of the way compilers work, the closing
brackets for the template in the original example will be read as a
"shift" operator instead of template brackets. The line can be formatted
most any old way as long as '<' or '>' template specifiers are not
concatenated. Not being an official "promoter" of SystemC (i.e. I
haven't downloaded anything from them), I don't know if this was a typo
on the part of the transcriber or was in fact in the original computer
readable text.
The ANSI C++ committee argued about that extra space for a long time
before finally agreeing that it had to be there. It's an artifact of
the somewhat clunky way of specifying templates in C++. If the current
SystemC preprocessor accepts this non-C++ syntax, they'll be setting
their users up for a maintenance nightmare and will need to stop this
non-ANSI "feature" now while they have a chance.
(I'm hopeful that it was just a transcription error, which would look
quite harmless and be easy for a non-C++ programmer to make, but it's
potentially too important an error just to assume that.)
- David Chapman
Chapman Consulting Santa Clara, CA
( ESNUG 351 Item 5 ) ---------------------------------------------- [5/4/00]
Subject: ( ESNUG 348 #8 ) Run Synopsys DesignPower w/ Cadence NC-Verilog
> We are using Synopsys DesignPower and Cadence NC-Verilog, in order to
> perform power estimation of our ASIC's - but we are having problems -
> perhaps some of your readers might be able to help us out.
>
> The problem relates to the backward SAIF file, written by NC-Verilog
> through the $toggle_report PLI supplied by Synopsys (the file contains
> switching activity for all ports). It seems like some input ports are
> dropped, but not all. When read into dc_shell, and running report_power,
> these "dropped input" are having default 50% switching activity (no
> annotation), which was the way I initially discovered the problem.
>
> The ports, which are in the rtl2saif output file, are all monitored
> except for one data_valid and in[0]. Why does this happen with
> NC-Verilog 3.0 PLI version 3.3 but this does not happen with either VCS
> or Verilog-XL 3.0 simulators?
>
> - Hans M. Pedersen
> Oticon A/S Hellerup, Denmark
From: [ A Synopsys DesignPower CAE ]
John,
Monitoring behavior is simulator dependent.
Although my answer to this question is based on Pedersen's design that he
e-mailed to me, this answer applies to many in his situation.
In his particular case, Pedersen's data_valid (a single bit) in HDL is
connected to port 'in' of Pedersen's "XYZ" instance. His port 'in' is
defined inside the "XYZ module" as a bus width of 3. Pedersen's data_valid
is connected to in[0]. Since the other 'in' bits are not used, NC-Verilog
internally represents the port 'in' as a single bit object, which is
interpreted by our PLI as 'in'. But inside Verilog-XL or VCS, Pedersen's
port 'in' is represented as a 4-bit bus object, which is interpreted by our
PLI as 'in[0], 'in[1]', etc.
Our PLI monitors the in[0] and checks whether the in[0] exists. Our PLI
checks the rtl2saif (forward SAIF) output file and NC-Verilog for in[0]. A
mismatch occurs since in the rtl2saif output file the port is represented
as in[0] and in NC-Verilog the port is represented as 'in'. Our PLI then
writes out the backward SAIF file. Since port is interpreted by PLI as 'in'
under the NC-Verilog environment, our PLI fails to find the name 'in' in
rtl2saif output file and therefore the port name is not written out to the
backward SAIF file. In Verilog-XL or in VCS, the in[0] port is represented
with a matching name so our PLI is able to monitor and, check in rtl2saif
and write out in the backward SAIF file information about that port.
Pedersen's Workaround:
1) Remove 'in\[0\]' line in the rtl2saif file; then data_valid is captured.
2) Change 'in\[0\]' to 'in' inside the rtl2saif output file; then
data_valid and in are both captured.
Hope this helps.
- [ A Synopsys DesignPower CAE ]
( ESNUG 351 Item 6 ) ---------------------------------------------- [5/4/00]
Subject: ( ESNUG 348 #10 ) A Good EMACS Set-up For Use With dc_shell-mode
> Does anyone have a good emacs settup for dc_shell scripts?
>
> - Scott Butler
> Intel
>
From: Reto Zimmermann <reto@synopsys.com>
Yes, but only for dc_shell, not dc_shell_t (tcl mode):
http://www.emacs.org/hdl/dcsh-mode.html
- Reto Zimmermann
Synopsys Design Reuse Group Beaverton, OR
( ESNUG 351 Item 7 ) ---------------------------------------------- [5/4/00]
Subject: ( ESNUG 347 #1 ) Reactions To Cliff's Nonblocking Verilog Paper
> module dffx (q, d, clk, rst);
> output q;
> input d, clk, rst;
> reg q;
>
> always @(posedge clk)
> if (rst) q = 1'b0;
> else q <= d;
> endmodule
>
> Example 14 - Preferred D flip-flop coding style with nonblocking
> assignments
From: "Alex Kumets" <kumets@hotmail.com>
John,
Cliff's Example 14 will work better if we use nonblocking during reset:
module dffx (q, d, clk, rst);
output q;
input d, clk, rst;
reg q;
always @(posedge clk)
// if (rst) q = 1'b0;
if (rst) q <= 1'b0;
else q <= d;
endmodule
Also, we may use blocking-only assignments in our design ( making much more
'always' ) but nonblocking assignments make source code much better to read
and maintain
- Alex Kumets
Wave Systems
---- ---- ---- ---- ---- ---- ----
From: Andrew Roy <andrewr@eng.adaptec.com>
John,
I think that there is a problem with Example 14 in Cliff's paper e-mailed
in ESNUG 347. The (synchronous) reset is done with a blocking assignment,
and the "clock edge" assignment is done with a nonblocking assignment.
This violates Cliff's Guideline #1 and Guideline #5, and is probably not
synthesizable with Synopsys tools.
Was this intentional, or a typo/file translation error? If it was
intentional, why is a synchronous reset handled differently than the
asynchronous reset of Cliff's Example 17 (and some other examples)?
- Andy Roy
Adaptec
---- ---- ---- ---- ---- ---- ----
From: Neil Crook <ncrook@micron.com>
Hi John,
In Example 14 of Cliff's paper, Cliff mixes blocking and nonblocking
assignments within an always block (in violation of his Guideline #5).
I believe the = should be an <=. If so, it would avoid confusion to
fix this up...
In his Example 17, surely the whole point is that the temporary
variable n1 can be deleted, so that the second assignment to q2
becomes: q2 <= q1 ^ q3;
- Neal Crook
Micron
---- ---- ---- ---- ---- ---- ----
From: Oren Rubinstein <oren@gigapixel.com>
Hi, John,
I didn't see Cliff's presentation at SNUG (I was in a different session),
but this is indeed a very thorough analysis of the different cases. All of
Cliff's guidelines have been standard practice for us, for a long time.
I'd add one guideline of my own - add a #1 in the nonblocking assignments
to sequential elements:
a <= #1 b;
instead of
a <= b;
There are two reasons for this:
1. It allows mixed RTL and gate-level simulations to run correctly,
by providing 1ns of hold time to the gate-level flip-flops.
2. It's so much easier to understand what you see on the waves display
when you're trying to debug something, because signals change 1 ns
after the clock edge.
Good paper, Cliff.
- Oren Rubinstein
GigaPixel Corp. Santa Clara, CA
---- ---- ---- ---- ---- ---- ----
From: Alain Raynaud <alain@tensilica.com>
John,
I can't help it, I have to add my 2 cents to Cliff Cummings otherwise
excellent paper on nonblocking Verilog assignments. And believe me, I'm
not trying to start a language war either...
We, European designers, never cease to wonder why our American friends
have such a hard time dealing with a relatively simple issue (Cliff's
paper lists a total of 8 rules), when it all fits in one golden rule:
"Verilog blocking vs. nonblocking is the same as VHDL variable vs. signal".
For those of you who are not familiar with VHDL, let me restate the VHDL
variable rule with a Verilog spin: "blocking assignments should be used
for intermediate computations inside an always block, whereas
nonblocking assignments should be used to export outputs of an always
block to other blocks or ports".
If you look carefully, this one rule is exactly the equivalent, but more
powerful, of guidelines #1, #3 and #4. It also shows that guideline #5
and #6 are actually overkill.
Of course, I am aware that the VHDL variable semantics has one major
restriction: you cannot do a nonblocking assignment to the same signal
in different always blocks. But I believe it's a small price to pay for
peace of mind...
- Alain "where is VHDL when you need it?" Raynaud
Tensilica, Inc. Santa Clara, CA
---- ---- ---- ---- ---- ---- ----
From: "Steve Glaser" <sglaser@avici.com>
John,
While it's not synthesizeable, another common misuse of blocking vs.
nonblocking is in tunable external delay elements. These are pretty handy
in testbench code. However, using it correctly violates Cliff's
Guideline #3.
Guideline #3: When modeling combinational logic with an "always"
block, use blocking assignments.
We commonly use something like the following...
function real n2r;
input delay;
reg [31:0] delay;
n2r = delay * 0.01;
endfunction
...
reg [31:0] sci_dly; // written by Vera
initial begin
sci_dly = 32'd0;
out = 1'b0;
end
always @(in)
out <= #(n2r(sci_dly)) in; // don't use blocking assignment here
The n2r function scales and converts an integer to a real. It helps since
Vera doesn't do floats as nicely. It's not critical to the issue (except
some Verilogs won't let you use a non-integer as a delay, even if it was
a constant).
If this code used blocking assignment, and input edges happen faster than
the delay value, then input edges will get lost and not show (delayed) up
on the output.
- Steve Glaser
Avici Systems North Billerica, MA
P.S. I assume Cliff meant nonblocking on both assignments in his Example 14.
Otherwise this would violate his Guideline #5.
---- ---- ---- ---- ---- ---- ----
From: "Vigyan Singhal" <vigyan@home.com>
John,
I have a comment/question on Cliff's following myth:
> 15.3 Multiple Nonblocking Assignments To The Same Variable
>
> Myth: "Making multiple nonblocking assignments to the same variable
> in the same always block is undefined"
>
> Truth: Making multiple nonblocking assignments to the same variable
> in the same "always" block is defined by the Verilog Standard.
> The last nonblocking assignment to the same variable wins!
>
> Quoting from the IEEE 1364-1995 Verilog Standard [2], pg. 47, section
> 5.4.1 on Determinism:
>
> "Nonblocking assignments shall be performed in the order the
> statements were executed. Consider the following example:
>
> initial begin
> a <= 0;
> a <= 1;
> end
>
> When this block is executed, there will be two events added to the
> nonblocking assign update queue. The previous rule requires that
> they be entered on the queue in source order; this rule requires
> that they be taken from the queue and performed in source order as
> well. Hence, at the end of time-step 1, the variable a will be
> assigned 0 and then 1."
>
> Translation: "The last nonblocking assignment wins!"
The Verilog LRM appears to be inconsistent on this issue. I picked up the
following from section 9.2 on "Procedural assignments":
"When multiple non-blocking assignments are scheduled to occur in
the same register in a particular time slot, the order in which the
assignments are evaluated is not guaranteed -- the final value of
the register is indeterminate. As shown below, the value of register
a is not known until the end of time step 4.
module multiple2 (out);
output out
reg a;
initial a = 1;
// The register's assigned value is indeterminate
initial begin
a <= #4 0; // schedules a = 0 at time 4
a <= #4 1; // schedules a = 1 at time 4
end // At time 4, a = ??
endmodule
This seems to contradict Cliff's earlier quote from Section 5.4.1... Which
is correct, and why does the LRM seem to be inconsistent? In fact, I have
seen an example (more complicated than this one) where DC picked the first
assignment, but we thought it wasn't DC's fault since the RTL was not
deterministic. Perhaps we should have treated it as a synthesis bug.
- Vigyan Singhal
---- ---- ---- ---- ---- ---- ----
From: Bob Emberley <bobe@verisity.com>
Hi John,
I found Cliff's paper, "Coding Styles That Kill!" very informative. Several
of the pitfalls that Cliff described can be categorized as "read-write" or
"write-write" race conditions. Surelint is able to detect and warn the user
about these types of problems. Here is a summary of the SureLint results
using Cliff's examples:
Example 1: two read-write races are reported.
Example 2: no race is reported, as expected.
Example 7: two read-write races are reported.
Example 8: two read-write races are reported.
Example 11: no race is reported, as expected.
Example 15: no race is reported, as expected.
Example 26: two write-write races are reported.
Without going into too much of an advertisement, SureLint is able to detect
5 different types of races:
read-write
write-write
trigger propagation
combinational loop
UDP races (conflicts in UDP table)
The read-write and write-write are the most common and dangerous.
- Bob Emberley, FAE
Verisity Design Campbell, CA
( ESNUG 351 Item 8 ) ---------------------------------------------- [5/4/00]
From: John Cooley <jcooley@world.std.com>
Subject: Formality, Chrysalis, Verisity, and Cadence's Model Checking Tools
A few weeks ago, one of my readers forwarded me this anonymous post from
the Yahoo CDN stock chat board:
"Formality sales of about $10M doesn't point to a market leader, it
seems like a tool bundled into a larger deal for a very low price, which
Synopsys can afford to do to build a market presence. As you probably
know, formal verification is divided into two areas, model checking and
comparison checking. Verplex is the runaway leader in comparison
checking, and Chrysalis/Avanti still owns model checking. Another area
is test bench verification where Synopsys has no presence and Verisity
is the leader here. There is also a new company on the horizon that will
challenge Verisity. So Formality's survival is in question, and this
area is hot and growing."
Why I'm reprinting this is that passing claim that "Chrysalis/Avanti still
owns model checking" -- is this true? What are the customer experiences
with their model checking tools? Why I ask this was while at HDLcon'00, I
ran into a Cadence marketing guy who said Cadence was doing very well in
the model checking business. I would love to see a detailed customer review
of the Cadence model checking tools just to see if this Cadence marketdroid
was on-the-money or blowing smoke. Inquiring minds want to know!
- John Cooley
the ESNUG guy
( ESNUG 351 Item 9 ) ---------------------------------------------- [5/4/00]
Subject: Censorship, InterHDL, Hitler, Stalin, God, LSI Logic, & Gerry Hsu
> Stalin ruled Russia with a cult of personality the same way Gerry rules
> Avanti. Stalin was extremely paranoid, but he was dealing with Hitler
> and very unforgiving Russian politics. Gerry's paranoid, but he's
> dealing with Cadence and a very unforgiving San Jose District Attorney's
> Office. Stalin killed millions of people in the Soviet Union, sort of
> like how Gerry burns through employees at Avanti.
>
> But Stalin took a backwards Russia and in 30 years made it a nuclear world
> Soviet super power that bested the German Wehrmacht along the way. Gerry
> took a nothing ArcSys and turned it into a 26 consecutive profitable
> quarters Avanti that still bests Cadence in most P&R benchmarks.
>
> - from (censored) "Thank God For Gerry Hsu"
From: Al Kozloski <koz@axiscorp.com>
John,
Can I infer from this that Cadence can be compared to Hitler and the German
Wehrmacht? ;)
- Al Kozloski
Axis Corp.
---- ---- ---- ---- ---- ---- ----
From: [ Anon ]
John,
"Thank God for Gerry Hsu"??? Really? Gerry is a pariah whose company
is *allegedly* founded on stolen intellectual property. In my book,
dismemberment of both the company and the founder is warranted when the
charges are eventually proved. It does not matter that Gerry is not
the first nor the last crook in the world, but, it does matter that he
*allegedly* is a crook, and an unrepentant one at that. Until Gerry is
gone from Avanti and Cadence is properly restituted, I will not use *any*
Avanti tools. This is my personal decision and has nothing to do with
whether or not my company has the moral courage to do likewise. Anon,
please.
- [ Anon ]
P.S. This is easily your most pathetic, moronic column to date. That's
more likely why it was pulled from EE Times.
---- ---- ---- ---- ---- ---- ----
From: Steve Waterbury <steve.waterbury@gsfc.nasa.gov>
Gee, John, that Stalin was quite a guy!
Huh? I mean, politically incorrect is one thing ...
I dare you to do a column that idolizes Hitler next.
- Steve Waterbury
NASA
---- ---- ---- ---- ---- ---- ----
From: Sanjay Lall <sanjay@siliconsoftware.com>
John,
Impressive Summation. However, what about all the other crap technology
that has been acquired by Avanti and barely made it out of it's shell
in the last 4 years? You forget the other acquisitions and their demise.
- Sanjay Lall
Silicon Software
---- ---- ---- ---- ---- ---- ----
From: [ Anon Within Synopsys ]
John,
I gotta say, you glossed over one very big point. Gerry "brought competiton
to the backend P&R flow" through theft, plain and simple. That's not
something we should thank God for.
- [ Anon Within Synopsys ]
---- ---- ---- ---- ---- ---- ----
From: "tfran" <tfran@goplay.com>
John,
What piece of loco-dung did the Gadfly land on? Kudos for personalities
and products. The Internet maybe FREE but perhaps the Gadfly microphone
is NOT. "God and Gerry Hsu" in the same sentence -- and you're wondering
why EE Times balked. Duh!
Personalities/Religion aside, the only real news is Avanti has a thinning
lead in the P&R product race. Anything more, reads as paid for propaganda.
As an ex-Avanti with an inside view of the circle, any kudos for this man
are transient.
- "tfran"
---- ---- ---- ---- ---- ---- ----
From: [ Anon Within Synopsys ]
John,
Keep me anon if you want to use these comments.
I'm sorry this was censored, but I beg to disagree with your thesis.
Avanti is a great EDA technology company and has developed great products,
but Gerry's and the companies behaviors are bad for EDA and bad for the EDA
consumer.
The main issue is that the ongoing legal wrangling casts a dark cloud over
the entire EDA market and shows the companies executives as more interested
in infighting than in building new technology and value - not a good way to
build market cap. The low market cap is ultimately driving a flight of EDA
talent into dot com.
Gerry is doing his best to promote a closed proprietary EDA system which
does not provide for interoperability with other tools. Avanti has taken
great advantage of the other EDA company standards (LEF/DEF, LIB, PDEF,
SDC), yet has not provided any access to their Milkyway Apollo system. In
fact, Avanti has gone so far as to remove access to the XREF function to
disable the flow with Synopsys EPIC tools. Avanti has actively worked to
drop support of the SNPS-Avanti link-2-layout interface, and in 3 way
customer conference calls they have gone so far as to misrepresent facts to
their customers.
Case in point from the recent Mentor announcement:
Michael Jackson, head of West Coast R&D product management at Avanti, said
he had not heard that Mentor had attempted to contact his company about
interfacing Mentor's new placement technology to Avanti's Apollo P&R tool.
"I really don't see why we would engage in that type of an agreement
anyway," said Jackson. "It doesn't sound like Avanti's customers would
really benefit from it. Signal-integrity problems and timing closure
require a tight coupling between placement and routing. I don't see how
Mentor can believe they can integrate their placement product into our
Apollo product and do a better job of it than we can."
I would encourage you to ask the customer their opinion - I think you might
be surprised what you find. Yes best P&R tool - this does not indicate a
great company to do business with.
Gerry is akin to Bill Gates of EDA, Microsoft claims it has done great
things for the consumer and overall productivity. Yes great techology and
products, but in the end closed proprietary stance is bad for the long term
innovation.
- [ Anon Within Synopsys ]
---- ---- ---- ---- ---- ---- ----
From: [ Anon ]
John,
I may be wrong, but I think the inner circle at Avanti is Taiwanese, not
Chinese. But I don't work at Hsu Inc, so what do I know? Anon!
- [ Anon ]
---- ---- ---- ---- ---- ---- ----
> [ Editor's Note: I'm not going to try to explain the crazy politics
> that got this particular Industry Gadfly column yanked from EE Times.
> All I can say is: "Thank God For An Uncensored Internet". - John ]
From: Gale Morrison <GMorrison@cahners.com>
Hi, John,
We'll publish it.
- Gale Morrison, Senior Editor
http://www.ElectronicNews.com
Electronic News NY, NY
---- ---- ---- ---- ---- ---- ----
From: Keith Howick <keith.howick@siliconmetrics.com>
John,
Thanks for the (Censored) Gadfly, you're at your best. I love nothing more
than being confused over whether or not I like Gerry Hsu! :-)
- Keith Howick
Silicon Metrics Corporation Austin, TX
---- ---- ---- ---- ---- ---- ----
From: [ Anon ]
Nice post. Anonymously: A friend of mine close in the Avanti circle told
me that Gerry was hanging out in Taiwan during the investigation, mainly
because Taiwan didn't have extradition laws. Hearsay, but still true to
the spirit of Gerry.
- [ Anon ]
---- ---- ---- ---- ---- ---- ----
From: Brien Anderson <anderson@acuson.com>
Hi John,
Thank you very much for being uncensored.
- Brien Anderson
Acuson Corporation Mountain View, CA
---- ---- ---- ---- ---- ---- ----
From: Mark Natale <mnatale@ati.com>
So John, do you think Gerry is just kind of the "Tucker" of the EDA world?
You know, the guy who went against the Big Three auto makers right after
WW II?
- Mark Natale
ATI
---- ---- ---- ---- ---- ---- ----
From: Bryan Lewis <bryan.lewis@gartner.com>
Hi John,
Nice article. I am glad I got to read it and thanks for sending it my way.
- Bryan Lewis
DataQuest
---- ---- ---- ---- ---- ---- ----
From: Scott Clapper <scott@chameleonsystems.com>
John,
I enjoyed your article on Avanti's Gerry Hsu; it was true and funny @ the
same time. I couldn't agree more, as a user of their software since the
ArcSys days and a Cadence user before that. Gerry did a great job of
integrating Cell3 and Cell Ensemble. However I believe there's a method
to his madness as he does treat AEs badly and R&D guys very well. (I heard
of large cash incentives.) If Avanti is hemorrhaging AE's, it's only good
for the company in that these AE's go out and get real jobs (with much
better pay) what software do you think they will bring in house? Also,
their tools are well integrated (what better way to sell more tools.)
Star-RCXT, for example, is far more accurate than anything else out there.
I don't know if I go as far as thanking GOD for Gerry Hsu, but I would say,
as a user, my life is easy with them, than without them.
- Scott Clapper
Chameleon Systems Sunnyvale, CA
---- ---- ---- ---- ---- ---- ----
> Let me say that last thought another way. Since its start, LSI Logic has
> always been a "homebrew" P&R tools company (i.e. LSI PD and LSI CMDE.)
> Yet, recently LSI Logic fired their internal backend tool developers and
> standardized on Avanti's timing-driven P&R toolset. Why? Not because
> of Gerry's charming persona. Hardly. It was because Gerry's tools kicked
> butt in the benchmarks. (This is also why Intel was Avanti's biggest
> customer last year, followed by TI, Lucent, Philips, AMD, and Infineon.)
From: [ Anon Within Intel ]
John,
Pls keep me anon if you really want to post it.
1) I enjoy reading your mails and tahn you very much for the efforts.
2) Intel spend $ in mostly Avanti's ISS layout verification and minor
in RC and others. For P&R, Intel use Cadence most and some internal
development (which I think is not that good but has better GUI only).
There's some non-technical issue so that it's hard to bring their P&R here
even some engineers know/hear they are better. (big corp.)
Your above comment is a little bit misleading if you talks about P&R.
- [ Anon Within Intel ]
---- ---- ---- ---- ---- ---- ----
From: Jerry Twomey <jtwomey@diamond.fairchildsemi.com>
John,
Your LSI comments are very true, we spent several years inside LSI, and
their homebrew tools were a pain in the butt.
- Jerry Twomey
Fairchild Semiconductor San Diego, CA
---- ---- ---- ---- ---- ---- ----
> On the dark side, customers are still furious about Gerry's $47K price on
> interHDL's VeriLint.
From: Mike Glenn <mglenn@avanticorp.com>
John,
Just to set the record straight, InterHDL had already raised the price
before we bought the company, and I have the InterHDL price list to
prove it. We have since lowered the price to $21K for the unlimited
use batch version.
- Mike Glenn
Avanti Fremont, CA
============================================================================
Trying to figure out a Synopsys bug? Want to hear how 11,086 other users
dealt with it? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jcooley@world.std.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys,
_] [_ Verilog, VHDL and numerous Design Methodologies.
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Legal Disclaimer: "As always, anything said here is only opinion."
|
|
