( ESNUG 350 Item 8 ) --------------------------------------------- [4/27/00]
Subject: Doing Synopsys Scan Insertion Across Two Different Clock Domains
> If you have a design which connects flops Q to D, but the flops have
> different clocks, how do you force the Synopsys scan insertion tool to
> make the flops with one clock NOT the same chain as the flops with the
> different CLOCK? Must you hand craft your Verilog/VHDL code to allow for
> different data to be fed to Test In input of the chain? Just how smart
> is the Synopsys tool?
>
> - "Jim Jok"
From: Jan Decaluwe <jand@easics.be>
No, you don't have to change your HDL source code. The default behavior of
Test Compiler (since a couple of years) is to use separate scan chains per
clock system.
- Jan Decaluwe
Easics Leuven, Belgium
---- ---- ---- ---- ---- ---- ----
From: "Jim Jok" <jok@erols.com>
Thanks, with that knowledge I suppose I can add this other complication
which may have confused the others, too. (I am trying to fix a design which
is in silicon.)
The clocks are generated internal to the ASIC. The designers opted to use
one external clock, TESTCLOCK and when in scan mode this clock is on both
trees. I think this must have confused the tool since it mixed the scan
chains based on the connection of the Q to D connections.
I am wondering if by MUXing an external clock onto the seperate domains (so
in essence making them the same clock), the Synopsys tool thinks they are
the same clock and balanced. Any hints on driving the tool?
- "Jim Jok"
---- ---- ---- ---- ---- ---- ----
From: Jan Decaluwe <jand@easics.be>
> I am wondering if by MUXing a external clock onto the seperate domains (so
> in essence making them the same clock), the Synopsys tool thinks they are
> the same clock and balanced.
Yes, if they are driven from the same signal they are considered the same
clock for test purposes.
> So, any hints on driving the tool?
Yes, put the core of the design in a different level of hierarchy containing
everything except the clock mux and the pads. The core will have separate
inputs for the different clocks. Do scan insertion at the core level.
At the chip level, you can then run the tool with the -existing_scan
directive to recognize the scan chains.
This should do the trick for the scan chains, but when you now run ATPG at
the chip level, the clocks will again be considered the same by Test
Compiler. So if you have communication between the clock domains, the ATPG
vectors may not work.
- Jan Decaluwe
Easics Leuven, Belgium
---- ---- ---- ---- ---- ---- ----
From: Hans Lindkvist <Hans.Lindkvist@ldecs.ericsson.se>
You can manage with one scan chain. As long as the skew between the
"different clocks" in test mode (in test mode it is rather the same clock
but with skew) is limited to below half a clock cycle lockup latches in the
scan path will do the job. These latches can be added by test insertion
tools automatically. These tools does not fix problems on the mission mode
paths (which are the same as the capture mode paths). This will have to be
done up front, i.e. make the circuit immune to the maximum of the skew in
mission mode and capture mode.
My main message is that when the clocking scheme is designed, all of
mission-mode, scan-shift mode and capture-mode, have to be taken into
consideration or else the skew problems will very likely blow up in ones
face later in the design flow. At that point it can get very difficult and
expensive to fix it.
- Hans Lindkvist
Ericsson Mobile Communications AB Lund, Sweden
|
|
