From: tim@vertex.com (Tim Hsia)
Subject: Someone's Watching Over Me...
Dear John, I was in the middle of reading your article 'The Origins of
ESNUG' (ASIC & EDA, Sep., 1993, p. 34) while compiling a design in Synopsys
and I looked up to find the following message along with a crashed system:
Error id=62637
Fatal: Internal system error, cannot recover.
Release = 'v3.0b-12954' Architecture = 'sparc' Program = 'design_analyzer'
'9049448 9049732 10181516 9097764 4493616 4491324 4484040 4480284 4438248
4439052 4441716 4489120 2430044 2373232 2372268 2361708 1093616 8660848'
I guess it's the right time to ask for more information on ESNUG and join.
- Tim Hsia
Vertex
( ESNUG 155 Item 1 ) ---------------------------------------------- [10/93]
> Subject: ( ESNUG 154 # 4) "test_compiler Hates Existing Scan Chains"
>
> We're using mux'ed flop scan methodology on a hierarchical chip. We would
> LIKE to be able to insert scan on the individual modules when they are
> compiled, then just hook them up from the top of the chip.
>
> We have two engineers here (easily identified by the blood on their heads
> from repeated contact with the walls) who SWEAR that, despite all the
> stuff in the manuals about "set_test_methodology -existing_scan", and
> "set_signal_type", etc., there is NO WAY to get test_compiler to hook
> up existing scan chains in a hierarchical design.
>
> Before I bloody my head as well, can anyone either confirm or refute their
> claims. Has anyone ever succeeded in doing this? Repeated contact with
> Synopsys Hotline has not helped....
--- --- --- ---
John,
Ouch! These guys sound like they're in pain! I can't stand to see someone
in pain. I just had to respond. Please keep me anonymous, as usual. I'll
go by my alias.
From: [ The ESNUG Addict ]
In the interest of putting an end to the hemorrhaging....
In order to get this to work, you should read in all the .db files for all
of the lower level blocks when you try to insert scan at the top level (at
least that's the only way I know of).
IF you don't have any flops at the top level which need to be connected
to the scan chain,
THEN the following will work:
current_design = top_level /* where top_level is the design name*/
set_scan_style multiplexed_flip_flop
set_test_methodology full_scan -existing_scan
insert_test -no_insert
IF you do have flops that need routing at the top level,
THEN it gets a little more complex, try:
current_design = top_level
set_scan_style multiplexed_flip_flop
dont_touch {all_lower_level_blocks_which_have_scan_in_them}
insert_test -no_route
remove_attribute {all_lower_level....} dont_touch
set_test_methodology full_scan -existing_scan
insert_test -no_insert
report_test -scan_path
The first script simply routes all the existing scan chains together. The
second script places a dont_touch attribute on all flops which have scan and
then inserts scan on the rest, but doesn't route the scan chain. Then, the
dont_touch is removed and all flops and blocks are routed together. Of
course, a report on the scan path is generated just to make sure it worked
this time around!
- The ESNUG Addict (Keep those posts a comin')
--- --- --- ---
From: jwest@els.cray.com (Jeff West)
John, we too are having trouble getting Synopsys Test Compiler to not only
connect exhisting scan chains but to route a scan path in the hierarchical
order that we specify. To date we have written "several" scripts that get
us where we want to be but it is not without much gnashing of teeth and long
Test Compile runs. We are working with Synopsys on this problem but have no
results as of now.
- Jeff West
Cray Research
--- --- --- ---
From: marvin@lagrange.amd.com (Dean Marvin)
I can confirm by similar but less painful experiences (AMD uses soft cube
walls) that test_compiler does not like to do hookup on a block with scan
inserted in it. Fortunately the naming conventions used by TC+ make it easy
to use create_net, connect_net to do the routing at the top-level in
a script...
/*
** hookup t_si of subblock to glue at toplevel
*/
foreach(num, {0, 1, 2, 3, 4, 5, 6, 7}) {
sinet = "si[" + num + "]";
si = find(net, sinet);
if(si == {}) {
create_net sinet
} else {
disconnect_net sinet -all
}
spin = "subblock/t_si[" + num + "]";
gpin = "glue/si[" + num + "]";
disconnect_net all_connected(spin) spin
disconnect_net all_connected(gpin) gpin
connect_net sinet {gpin, spin}
}
As long as you follow a similar convention for your hookup pins or chain
blocks together it should work fine. Also you should manually set the test
attributes on the top-level pins so that you will be able to generate
patterns. Good luck.
- Dean Marvin
Advanced Micro Devices
--- --- --- ---
From: victor@boiler.truevision.com (Victor J. Duvanenko)
It is actually possible to succeed with the Test Compiler, and yes I've had
the same luck with Test Compiler support at Synopsys until I called my FAE in
Minneapolis who happened to have Test Compiler battle experience. Anyhow,
the method that worked for me was:
1) Add test pins (scan in, out, and scane enable) to each leaf block
2) Synthesize
3) Tell the Test Compiler about the scan pins so that it hooks the FF's
up to them
4) Recompile to get the performance back
5) Connect the scan chains yourself on the next level up
6) dont_touch all the leaf cells
7) Label the test pins of this block
8) Synthesize on low level (so that Synopsys simply connects) - DO NOT
run the Test Compiler at this level (run check_test however).
9) Keep going with steps 5 through 8 until you get your chip assembled
10) Once the entire chip has been assembled then label its test pins
and generate scan vectors.
I have actually succeeded at generating scan vectors for one of my chips,
with 4 scan chains. These vectors are being used for production testing now
and give about 80% coverage. You've got to love automagic, even after all
the suffering!
- Victor J. Duvanenko
Truevision
--- --- --- ---
From: Synopsys Applications Engineering
Below is an example design that shows how to get Test Compiler to hookup
existing scan chains in a hierarchical design. Two files are provided in
this testcase: 1) tc.v which is a Verilog HDL design and 2) run.scr which
is a dc_shell script file that shows the commands used to create the scan
chains and connect them up. At run time, look at the commands executed and
the reports to show that the scan chains built in the hierarchy blocks and
the connecting of all blocks into one scan chain.
- Synopsys Applications Engineering
module tc (in1,in2,in3,out1,out2,out3,clk,SCAO);
input in1,in2,in3,clk;
output out1,out2,out3,SCAO;
reg out1,out2,out3;
wire temp1;
assign temp1 = in1 & in2;
always @ (posedge clk) begin
out1 = temp1 & in3;
out2 = in1;
out3 = temp1 | in2;
end
endmodule
module tc2 (in1,in2,in3,out1,out2,out3,clk,SCAO);
input in1,in2,in3,clk;
output out1,out2,out3,SCAO;
wire temp1;
reg out1,out2,out3;
assign temp1 = in2 & in3;
always @ (posedge clk) begin
out1 = temp1;
out2 = in1 | in3 | in2;
out3 = temp1 & in2;
end
endmodule
module tc3 (in1,in2,in3,in4,out1,out2,out3,clk,SCAO);
input in1,in2,in3,in4,clk;
output out1,out2,out3,SCAO;
wire out1,out2,out3;
wire temp1,temp2,temp3,temp4,temp5;
assign temp1 = in1 & in2;
assign temp2 = in3 & in4;
assign out1 = temp3 & temp4;
assign out2 = temp5 | temp6;
assign out3 = temp7 & temp8;
tc c1 (.in1(in1),.in2(in2),.in3(in3),.out1(temp3),.out2(temp4),
.out3(temp5), .clk(clk));
tc2 c2 (.in1(in4),.in2(temp1),.in3(temp2),.out1(temp6),.out2(temp7),
.out3(temp8), .clk(clk));
endmodule
---run.scr---
link_library = target_library = class.db
read -f verilog tc.v /* tc.v containts all the designs */
current_design = tc3
compile
current_design = tc
set_signal_type test_scan_out SCAO
set_test_methodology multiplexed_flip_flop
insert_test
report_test -scan_path
current_design = tc2
set_signal_type test_scan_out SCAO
set_test_methodology multiplexed_flip_flop
insert_test
report_test -scan_path
current_design = tc3
set_signal_type test_scan_out SCAO
set_test_methodology multiplexed_flip_flop -existing_scan
set_signal_type test_scan_out {c1/SCAO c2/SCAO}
set_test_routing_order {c2 c1}
link -all
insert_test -no_insert
report_test -scan_path
quit
( ESNUG 155 Item 2 ) ---------------------------------------------- [10/93]
From: uunet!fmicos!splinter!flieder (Jeff Flieder)
Subject: ( ESNUG 137 ) Don't Use Fix Stinky Verilog (FSV) Script w/ Rev 3.0b
John, I just thought that I should let anyone using FSV that there are some
problems related to using FSV with V3.0b. It seems that in 3.0b, Synopsys is
much better at using the Q_bar outputs of sequential elements than it was
before. FSV assumes that the entire bus exists on the Q output of the
sequential elements. FSV will still do a pretty good job of fixing things
up, but you will have to check the Q outputs to make sure things are still
kosher (they probably won't be). It turns out that trying to fix this may be
a fairly monumental task, and I just don't have the time to do it right now.
Sometimes it is just no fun writing back-end tools when you have no control
over the front-end!
- Jeff Flieder
Ford Microelectronics
( ESNUG 155 Item 3 ) ---------------------------------------------- [10/93]
From: "Fred Lee Lum" <Fred_Lee_Lum@mesqm1.sps.mot.com>
Subject: Problems with ECL
Is there any one out there using the ECL compiler? The extract command
crashes if the library has flip flops with differential clocks. I get one
of two errors:
Error: Illegal clock logic for state vector element 'xx_reg[0]'.
or
Error: Cannot extract multiple clocks feeding state vector
element 'xx_reg[0]'.
Has anyone seen this?
- Fred Lee Lum
Motorola
( ESNUG 155 Item 4 ) ---------------------------------------------- [10/93]
From: Murphy Peter <uunet!tcemail!rnd3.indy.tce.com!MurphyP>
Subject: VSS Running By Itself
Has anyone noticed vhdldbx seeming to run without issuing a run command?
The waves window advances in time with results that are definitely bogus
while the vhdldbx display shows that the simulator clock has not advanced.
- Peter Murphy
Thomson Consumer Electronics
|
|
