( ESNUG 324 Item 9 ) ---------------------------------------------- [8/04/99]
Subject: ( ESNUG 323 #3 ) Avanti Apollo P&R Restitching Scan Chains Gotchas
> "I ran into a guy named Al Crouch at the Mentor's Design-For-Test
> booth. He clued me in on a bunch of scan chain problems, so I feel
> obliged to put in a plug for his book "DFT for Digital IC's and
> Embedded Core Systems". Al definitely had a strong opinion that
> Synopsys' Test Compiler is an inferior product. (Probably why
> Mentor Graphics hosted him at their booth).
>
> Here are the scan chain gotchas he told me to watch for if we allow
> Avanti Apollo P&R to restitch the scan chain:
>
> 1) Apollo will not recognize separate clock domains when it
> restitches. It simply routes from flop to nearest flop without
> regard to the clock. To get around this you need to put each
> clock domain on a separate scan chain and explicitly tell Apollo
> which registers are on which chain. (I think that putting each
> chain on it's own enable facilitates this.)
>
> 2) We cannot allow Synopsys to put buffers along the chain. Apollo
> ignores them, routes flop to flop, and leaves the buffers and
> inverters hanging.
>
> 3) Apollo does not have any sense of timing, so when it restitches
> and routes to the flop next door it could cause hold violations.
> Al mentioned a design he had with about 5000 flops. Apollo
> introduced 3000 hold violations.
>
> Email Al_Crouch@prodigy.net w/ questions. He was a really nice guy."
>
> - An Anon Engineer (from the DAC'99 Trip Report)
From: [ A Synopsys Test CAE ]
John,
These issues are real, but they are not as serious as may appear. We have
supported scan chain reordering using Apollo for a couple of years (in the
TestGen product line) with good results. To address the 3 issues above:
1) This workaround is unnecessarily complex. The reordering tool
is driven by commands that can be written out by the scan
insertion tool. The scan chains for reordering do not need
to match the physical scan chains at all, or have any difference
in their controls. If the insertion tool has kept the clock
domains separated, it can tell the reordering tool to do so.
2) This is indeed a problem. Sorry but we don't have an immediate
fix. But this is much less disasterous than (1) and (3).
3) This is a danger, but in the experience of our customers, and of
our test consulting group, it is not worse than the problem of
scan chain clock skew without reordering. Separating the clock
domains, using lockup latches and careful control of clock skew
within each clock domain keeps this problem under control.
As a side note, if there are that many scan shift violations, then the
clock skew is probably so large that there will also be many problems
during capture since ATPG doesn't know which direction the clock skew is
going either.
- [ A Synopsys Test CAE ]
---- ---- ---- ---- ---- ---- ----
> 3) Apollo does not have any sense of timing, so when it restitches
> and routes to the flop next door it could cause hold violations.
> Al mentioned a design he had with about 5000 flops. Apollo
> introduced 3000 hold violations.
From: Zeev Yelin <zeev@avanticorp.com>
Hi John,
I'm not a Apollo expert, so I'll answer only to the third "Gotcha" - the
issue is not a tool one but a library one and is caused by lack of delay
on the SD (Scan D) input. Or, in other words, by a negative difference
between the Clock to D and the Hold time of the driven FF ( assuming
traces of Qi-> Di+1, and Clock traces to Cpi, and Cpi+1 have equivalent
length). So, bottom line, those "violations" are proof that Apollo is
reordering the scan-chain FF in what it was meant to do as close as
possible one to another.
A remedy to this "Gotcha" is to inserting an additional delay on the SD
input as to beef-up the delay in the Qi -> SDi+1, this inflates the FF
cell area a bit. (the price of testability) .
BTW, I bet that the first 2 "Gotchas" are solvable by a more robust
Design Flow/Methodolgy... Though I may be wrong ;-))
- Zeev Yelin, Applications Engineer
Avant! (Israel) Herzelia, Israel
|
|
