( ESNUG 322 Item 10 ) --------------------------------------------- [6/15/99]
Subject: ( ESNUG 321 #7 ) DC's Wrecking My Scan Chains During Incrementals
> I have a netlist with a scan chain inserted. Now I want to do an
> incremental compile on that netlist without the Test Compiler. I've tried
> to put a set_dont_touch on every register and every scan chain net (the
> one which are connected to the DB input of my scannable register).
> Unfortunately, this doesn't stop Design Compiler from messing around with
> my scan chain since the set_dont_touch on a net applies only on
> combinatorial cells connected to that net.
>
> What happens basically is that Design Compiler is re-routing my scan chain
> thru inverters to try to reduce the fanout on other critical paths. So
> instead of going from Q to DB, it goes from QN to DB thru an inverter.
> Not really what I want for a scan chain !!!
>
> This scan chain wasn't generated by the Test Compiler at the first place.
>
> If anyone has a suggestion, that would be great.
>
> - Laurent Claudel
> Massana Ltd Dublin, Ireland
From: Jeffrey Ebert <ebert@sonicsinc.com>
John,
Laurent needs to make sure that DC knows about the scan chain. This
involves specifying the signal_types for the scan ports and running
check_test. Of course, this requires a Test-Compiler license, at least
for the check_test execution. Subsequent compiles will not need it.
In theory, you might be able to set the appropriate attributes on the
scan circuitry manually or with a nice little script, but I've never
been down that road.
On the other hand, I don't know why Laurent is concerned about DC using
the QN output. This is usually considered a good thing in scan
synthesis, precisely because it reduces loading on the functional
output. I guess he has his reasons, though.
- Jeffrey Ebert
Sonics
---- ---- ---- ---- ---- ---- ----
From: Sam Rosen <sam@lexra.com>
John,
I wanted to offer help on Laurent Caudel's Scan issue (ESNUG Post 321 #7).
I re-read Bob Wiegand's great letter on "Five Lessons I Learned The Hard Way
While Using DC 99.05" in ESNUG Post 317 #6, and realized I had a couple of
(hard-earned) gems of wisdom he didn't cover about Design Compiler and
Test Compiler. Hopefully these will help Laurent and others.
1. check_test adds scan attributes to a non-DC scan chain
In our design, we read verilog netlists (.hv) in for non-synthesized
pre-scanned blocks (ie, datapaths). To add scan attributes to a subdesign
(say, foo) on reading it in, do the following: (note: use set_signal_type
for _existing_ scan, while you use set_scan_signal before insert_scan.
why? beats me)
read -format verilog foo.hv
current_design foo
set_scan_configuration -existing_scan true
set_signal_type test_scan_enable SEN
set_signal_type test_scan_in SIN
set_signal_type test_scan_out SOUT
check_test
At this point, Design Compiler recognizes the scan chain, and therefore
won't do stupid things like adding muxes to the inputs, etc.
2. Optimizing use of the Test-Compiler License
We have less Test Compiler licenses than Design Compiler licenses. When
we ran out of Test Compiler licenses DC shell issued a non-fatal error
message occurred, and the job completed without inserting scan. The
solution we use causes a job to wait until it acquires a valid license,
and releases the license when its done. This should (with #1) allow
Laurent to do an incremental compiler without a Test_Compiler license.
(I found this basic script in SolvNet, slightly modified)
FAILED_LICENSE = 0
get_license Test-Compiler
while (dc_shell_status == 0) {
sh "sleep 300"
FAILED_LICENSE = 1
get_license Test-Compiler
}
if (FAILED_LICENSE) {
echo "Error: Test-Compiler License acquired"
}
<do the check_test from #1, above>
remove_license Test-Compiler
<do the incremental compile>
3. "Safe" insertion doesn't modify cells
This method of "safe" insertion was provided to me which shouldn't affect
the cells in existing scan chains. I've found it modifies cells when scan
configuration constraints are violated, but is much safer than a simple
insert_scan:
test_dont_fix_constraint_violations = "true"
insert_scan -map_effort low -ignore_compile_design_rules
I use this because in a subdesign block (foo, from above) on which I need
dont_touch attributes. However, I want its scan chain included on the
scan chain of the higher block. In some cases,
set_scan_path Chain1 foo/1 -complete false
insert_scan
might work (the foo/1 refers to the 1st scan chain in block foo, which
seems to be assigned randomly during check_test. referring to it as an
item should cause it to be untouched inside foo itself.) Referring to the
individual cells will cause an error that it can't insert because of a
dont_touch attribute.
I use this workaround:
<check_test on foo, as in #1, above>
<remove all dont_touches>
test_dont_fix_constraint_violations = "true"
insert_scan -map_effort low -ignore_compile_design_rules
<add back all dont_touches>
4. Forcing Q vs QN / chain buffers (only a mediocre workaround here)
One of the place & route tools we have experience with requires consistent
use of Q or QN as the scan output. We were told by Synopsys AE's that the
variable: test_disable_find_best_scan_out = "TRUE" should prevent it from
using QN. However, this was not the case.
To solve this, we've eliminated all flops with QN from our library (using
dont_use) to get around this. This initially worried me (overconstraints);
however, Design Compiler frequently chose flops with Q and QN while leaving
QN unconnected. The flop was larger _and_ slower. It turns out DC was
picking flops badly, and this helped it choose better. Does anyone have a
better solution?
- Sam Rosen
Lexra Waltham, MA
|
|
