( ESNUG 331 Item 4 ) --------------------------------------------- [10/7/99]
Subject: ( ESNUG 317 #5 330 #7 ) Troubling Scan Insertion Name Changes
> The script referred to by project_name + "_wireload.scr" is a brute force
> search and destroy script to match up the current_design design name with
> an associated wireload. This worked great until I tried to route the scan
> chains at the core level, which changes the design names! The variable
> insert_test_design_naming_style can be used to control how the design is
> renamed, but the %s and %d fields are required. I set it to %s_scan_%d.
>
> - Bob Wiegand
> Creative Labs Malvern, PA
From: Gzim Derti <gderti@intrinsix.com>
To: Bob Wiegand <rwiegand@ensoniq.com>
Robert,
You mentioned in ESNUG 330 about DC changing the names of blocks after scan
insertion. I have noticed the same thing recently. It seems to me that
the blocks that have their name changed are those blocks which contain scan
VIOLATIONS. Did you happen to notice if this was the same for you???
Basically, the way I noticed this was that I'm doing a bottom up scan
insertion, all of my leaf cells seemed to scan correctly, BUT when I go up
one level to try and get DC to connect up all the individual chains is when
replicas of the lower blocks are created. The blocks that are "copied" seem
to be those blocks that have some form of scan violation at this newer,
higher level of hierarchy.
In my case, it had to do with a design that I was handed, the lower level
blocks have clocks and resets passing in from above and everything seems
to be working well. BUT, at the next higher level of hierarchy, DC noticed
that the "reset control" line for a particular block came from gated logic,
and one of the inputs to the logic came from a flop WITHIN the design, thus
I got a violation about possible instability during scan and capture.
Along with duplicating the blocks, DC leaves these "violated" blocks OUT of
the resultant final scan chain, AND the "violated" blocks have been
duplicated.
SO, it seems to have something to do with scan violations that are found.
ALSO, I just did a compare between the two designs... (in my case let's use
Xcounter as the name). Xcounter scan inserts with no problem. When I go up
one level and try to connect the scan chains up, Xcounter is replicated and
called Xcounter_test_1. Xcounter contains the scan flops, BUT the design
Xcounter_test_1 is a PRE-SCAN version and is NOW whats being linked to in
the design.
I have NO idea why it does this other than something to do with the scan
violations concerning reset signals gated with internal flop outputs.
Hopefully, all of that made some form of sense. I'll try and see if I can
figure any thing else out.
- Gzim Derti
Intrinsix Corp. Rochester, NY
---- ---- ---- ---- ---- ---- ----
From: Robert Wiegand <rwiegand@ensoniq.com>
To: Gzim Derti <gderti@intrinsix.com>
Gzim,
What I have noticed is that the design names change after running the
insert_scan command at core level. The lower level modules were compiled
with the -scan switch, but no insert_scan was run. As a result, there are
no test_se inputs on any of the designs (except for the RAM wrappers)
untill the core level insert_scan is run. Check out ESNUG 317 #5, "Seven
Cool Tricks From My Adventures Using Test Compiler". I went into a lot of
detail there about the methodology. Anyway, when the scan enable inputs
are added to the lower level designs, they are renamed. The original
designs are still in memory with unrouted scan logic, but the core now
links the new renamed designs with routed scan logic. I had performed
check_test on all the lower designs, as well as the core and worked out the
problems. I had the luxury of a test_mode pin which I could use to gate
out any reset testability problems. The only design names that weren't
changed were purly combinatorial blocks, which didn't need a test_se port.
In ESNUG 317, I reported a problem of having all the test_se connectivity
get trashed and then reconnected to the existing tree when trying to do a
netlist level insert_scan to add the clocks block scan chains to the
existing core chains and connect all the core level test_si's and
test_so's. It seems that doing an insert_scan at the core followed by an
insert scan at the top (without rerouting the core chains) had something to
do with it. I have since tried using various permutations of the -hookup
option of set_scan_signal -test_scan_enable -port test_se command to get
around the problem, but without success. But I found another way to get
around it. Make sure the top level test_se connectivy is already present,
and then use set_scan_configuration -route_signals serial. This will leave
the scan enable connectivity alone, and only deal with the scan chain
connectivity.
- Bob Wiegand
Creative Labs Malvern, PA
|
|
