Editor's Note: The rumors about ViewLogic buying Chronologic Simulations
are true. It was just announced that Chrono was bought for $26 million.
Chrono is to remain a separate division of ViewLogic. When asked about
having two divisions of the same company having mutually exclusive market
goals (Vantage pushing VHDL and Chrono pushing Verilog), Alain Hanover,
President of ViewLogic replied:
"It's always been my dream to give my customers a choice between
ViewLogic & ViewLogic. Vantage is a great VHDL simulator. We were
OEMing CAD Artisans' Verilog product for over a year. We weren't
making a lot of headway because we kept losing benchmarks to Chrono.
We decided we rather switch than fight. Let the customer vote
for Verilog or VHDL with their dollars. We're HDL neutral."
When asked how this impacts Synopsys, Aart de Geus, President & CEO replied:
"Here's a good example of industry interdependency. Synopsys supports VCS
(the Chrono Verilog simulator) because Chronologics has been a forward
looking adoptor of SWIFT - the interface that guarentees all LMC models
will work with a specific simulator. Interestingly it appears that
ViewLogic has positioned itself to now be a major competitor to Cadence
in the simulation market yet it'll remain Synopsys/LMC compatible."
Personal Opinion: With Cadence and ViewLogic becoming neutrals in the
Verilog/VHDL wars (because they offer both products) it will be only
a matter of time until Mentor and Synopsys will follow. The days when the
visiting EDA salesman tries to strong arm you into a specific HDL because
his company only sells a simulator in that HDL are numbered. Thank God
(and market forces!)
- John Cooley
the ESNUG guy
( ESNUG 184 Item 1 ) ---------------------------------------------- [4/1/94]
Subject: ( ESNUG 183 #4) Solution For Problem w/ Multiple Clock ATPG Designs
> One problem that I do, however, run into and haven't gotten to the bottom of
> yet, is that the Test Compiler knows nothing about propagation delays and it
> goofs up because of this, when you have several asynchronous clocks (when
> it propagates values from blocks of one clock to block of another clock).
> My ASIC vendor simulated scan vectors on their gate-level simulator and it
> always has miscompares. Has anyone else seen this problem and have any
> words of wisdom about fixing it? Hope this helps.
--- --- --- ---
From: pete@sei.com (Peter Johnson)
This user mentions that he has problems with test compiler not knowing about
propagation delays, and having problems as a result. Here's how I handle it.
First, even if Test Compiler knew about timing, it could not fix this problem.
The problem arises because there is skew between the different clocks. Since
a tester can't apply both clock inputs at the same time, there is no way to
even predict the skew, or even know which clock will arrive first. Most
important is to never put flip-flops with different clocks on the same scan
chain (for this rule, falling edge flip-flops are considered to have a
different clock than rising edge flip-flops). This will solve any setup/hold
problems caused by skew between clock while scanning in patterns. The other
rule is that you only apply one of the clocks when you drop out of scan mode
and capture the test response. Unfortunately, this means that you run your
patterns multiple times, one time for each clock.
So, to summarize, if you have two clocks A and B, run your patterns, clocking
only A when applying the pattern (when you drop out of scan mode). Then run
the patterns again, clocking only B when applying the pattern.
- Peter Johnson
Silicon Engineering, Inc.
--- --- --- ---
From: jwk@melardc.net.netcom.com (John Kesterson)
John, we are not using LSI as our vendor; however, we have encountered similar
problems to the one presented here.
We just completed an ASIC design that contained several clocks and several
scan chains. If you have a chain that is made op of flops that are clocked
with more than one clock, then you must find a method of deterministically
scanning in the test pattern. I use the word deterministically because
if you use the same clock stimulus on two clock pins of the ASIC there will
be clock skew between the versions of those clocks as seen by the flops
themselves. Consider the following example. Given that there are two
flops - A and B. There are also two clocks C1 and C2. In the scan test
mode, suppose the same clock is inserted on C1 and C2. After the clock edge
you would hope that flop A contains the new scan in value and that flop B
contains what flop A had before the clock edge. But if C2 is seen by flop B
late, then both flop A and B end up with the new scan in value and we
have not therefore sucessfully loaded the intended scan pattern.
Test compiler DOES take timing into consideration when it creates a scan
chain, but it does NOT take into consideration timing BETWEEN two different
clocks. The workaround is easy. Don't stimulate both clocks (C1 and C2)
with the same clock. Use the create_test_clock command to create different
phases of the clock to use on each clock pin. The timing difference between
the clocks obviously must be greater than the setup and hold times. Here is
an example of how it is done in a script:
create_test_clock C1 -period 500 -waveform { 100 200 }
create_test_clock C2 -period 500 -waveform { 300 400 }
With different phases of the clock one can see that it is still possible to
deterministically insert any desired pattern and we very happily discovered
that test compiler uses this information.
I have used this and have seen all of the miscompares eliminated when doing
so. When generating the vectors, it skips the random vectors and starts out
with the deterministic ones. It takes a little longer to generate the vectors
but they are not longer! I hope that this helps.
- John Kesterson
Mitsubishi R&D Center
( ESNUG 184 Item 2 ) ---------------------------------------------- [4/1/94]
From: munoz@aurfs1.aur.alcatel.com (Ron Munoz)
Subject: (ESNUG 180 #4 182 #1) Synopsys Test Compiler w/ LSI Logic
John,
I just read the latest on this posting with a great deal of interest as our
company was also in the process of deciding whether we'll use the Synopsys
ATPG output or LSI's ATPG tool. The main reason (according to LSI) for using
LSI's tool is that it creates a fault dictionary that can be used to debug
the vectors on the test machine if there is a problem. This is a great
feature and should be incorporated into Test Compiler (hint, hint).
CTV, which is what the original question was about, is Synopsys's ATPG vector
formatter specific to LSI. Since CTV is a fairly new product, our Synopsys
sales rep gave us a couple of references. One of the references was in the
process of using CTV to format the vectors, while another had already used it
and was awaiting prototypes back from LSI. Both references commented that
they thought the tool was simple to use and one only found some minor problems
with syntax errors. The one reference has received his prototypes and LSI
reported no problems using the CTV formatted vectors on their test machine.
Based on this information, we are proceeding with Test Compiler's ATPG output
formatted with CTV tool (naturally, a separate cost).
- Ron Munoz
Alcatel Network Systems
( ESNUG 184 Item 3 ) ---------------------------------------------- [4/1/94]
From: rray@poci.amis.com (Russell L. Ray)
Subject: (ESNUG 183 #1) Model Tech / Synopsys VHDL Differences
John, I love ESNUG and what it does. Keep up the good work.
In regards to ESNUG 183 #1, I have done a lot of comparisons between Model Tech
and Synopsys. In addition to the items listed by Robert Hunter, I have found
that Model Tech does not support an SDF file. Of course, this is not
necessary for a behavioral or RTL simulation but is essential for accurate
gate level simulation. Fortunately, I understand that they are working on an
SDF reader now.
- Russell L. Ray
American Microsystems, Inc.
( ESNUG 184 Item 4 ) ---------------------------------------------- [4/1/94]
From: jhollins@adaptec.com (Jack Hollins x2309)
Subject: Getting Nice Verilog Out of Synopsys
John,
Here's a summary to get rid of tri wires, tran primitives, assign statements,
and backslashes from the Verilog netlist that is created by the HDL Compiler
when writing out Verilog from Synopsys:
1. Set the io variable "verilogout_no_tri" equal to true before writing
out the design to get rid of tri wires and trans primitives.
2. Set the compile variable "compile_fix_multiple_port_nets" equal to
true before compiling the design to get rid of assign statements due
to ports connected to the same net.
3. To get rid of assign statements due to nets connected to power or
ground create a library element using the Library Compiler that
represents a ground cell in a technology library or find a technology
library that contains a ground cell and then map the ground connection
to this cell. The cell description for the ground cell may be the
following:
library (pwr_gnd) {
cell (GND) {
area : 1;
pin (Z) { direction : output; function : "0"; }
}}
By adding this new library to our target_library variable (i.e.
target_library = target_library + {pwr_gnd.db}) and recompiling the
design we get the following netlist from the HDL Compiler:
4. Set the io variable "read_array_naming_style" to the legal Verilog
naming style "%s_%d" before reading in the design to get rid of
baskslashes.
If I take the following test case:
module test (a,b,z,y,x);
input [4:0] a,b;
output [4:0] z;
output [3:0] y;
inout x;
wire [4:0] ztemp;
assign ztemp = a + b;
assign z = ~ztemp;
assign y[0] = a[0];
assign y[1] = 1'b0;
assign y[2] = z[2];
assign x = ~a[0];
endmodule
The HDL Compiler produces the following Verilog netlist without the four steps:
module test ( a, b, z, y, x );
input [4:0] a;
output [3:0] y;
input [4:0] b;
output [4:0] z;
inout x;
wire \n21[1] , \ztemp[0] , \ztemp[1] , \ztemp[2] , \ztemp[3] , \a[0] ,
\z[2] ;
tri x_wire;
assign \a[0] = a[0];
assign z[2] = \z[2] ;
assign y[2] = \z[2] ;
assign y[0] = \a[0] ;
tran( x_wire, x );
IVP U7 ( .A(\ztemp[1] ), .Z(z[1]) );
IVP U8 ( .A(\ztemp[0] ), .Z(z[0]) );
IVA U9 ( .A(\a[0] ), .Z(x_wire) );
test_DW01_add_width5_0 add_7 ( .A({a[4], a[3], a[2], a[1], \a[0] }), .B(b),
.CI(1'b0), .SUM({\n21[1] , \ztemp[3] , \ztemp[2] , \ztemp[1] ,
\ztemp[0] }) );
assign y[1] = 1'b0;
IVP U4 ( .A(\n21[1] ), .Z(z[4]) );
IVP U5 ( .A(\ztemp[3] ), .Z(z[3]) );
IVP U6 ( .A(\ztemp[2] ), .Z(\z[2] ) );
endmodule
But by doing the four steps summarized above, I get:
module test ( a, b, z, y, x );
input [4:0] a;
output [3:0] y;
input [4:0] b;
output [4:0] z;
inout x;
wire n21_1, ztemp_3, ztemp_2, ztemp_1, n37, ztemp_0, n38;
IVDA U7 ( .A(n38), .Z(z[2]) );
IVDA U8 ( .A(n38), .Z(y[2]) );
IVP U9 ( .A(n21_1), .Z(z[4]) );
test_DW01_add_width5_0 add_7 ( .A(a), .B(b), .CI(n37), .SUM({n21_1,
ztemp_3, ztemp_2, ztemp_1, ztemp_0}) );
IVP U10 ( .A(ztemp_3), .Z(z[3]) );
IVP U11 ( .A(ztemp_2), .Z(n38) );
IVP U12 ( .A(ztemp_1), .Z(z[1]) );
IVP U13 ( .A(ztemp_0), .Z(z[0]) );
IVA U14 ( .A(a[0]), .Z(x) );
GND U4 ( .Z(y[1]) );
GND U5 ( .Z(n37) );
IVDA U6 ( .A(a[0]), .Z(y[0]) );
endmodule
- Jack Hollins
Adaptec
( ESNUG 184 Networking Section ) ----------------------------------- [4/1/94]
Two Digital Design Engineers wanted in Galway, Ireland. ASIC and System work,
VHDL, Synopsys etc. Toucan Technology, Fax +353-91-755635 or coffey@iol.ie.
|
|
