Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Some problems about SCAN Insertion, wlecome to discuss them

Status
Not open for further replies.

wjccentury

Junior Member level 2
Joined
Sep 12, 2005
Messages
24
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
1,484
set_scan_signal site:edaboard.com

Hi, everybody !

Now, I am doing scan insertion from netlist generated by "compile -scan". I encountered some problems. I am not sure about my understanding. I hope someone can help me. Thank you !

1. For a large design(about 10,000,000 gates), how can we define the number of scan chains ?
My understanding:
a: the number of I/O that can be used as scan I/O
b: the DFF number can't exceed the upper limit (ex. 1,000 DFF),or the scan test vector may be too long.

2. When scan insertion, I define the number of scan chain. Then I create test ports, such as "test_si_1","test_si_2","test_so_1","test_so_2" and so on. Then I define scan signals ,test_si_# and test_so_#, as "test_scan_in" and "test_scan_out" signal. When I do this step. I should give the scan path info. How can I generate the scan path info ?
My understanding:
The synopsys command is "set_scan_signal test_scan_in -port test_si_# -chain chain_#". Here, I must provide the chain_1_#'s information. I know I should use the command "set_scan_path". But the number of chains may be about 200, I don't know how define these chains.

3. When I finish the scan insertion, there are so many tset ports in top module. I should use a control logic such as a mux to decrease the number of test ports and then connected with I/O pad, right ?

Hope for your answers.

Thank you very much !
 

scan compression x-compact

wjccentury said:
Hi, everybody !

Now, I am doing scan insertion from netlist generated by "compile -scan". I encountered some problems. I am not sure about my understanding. I hope someone can help me. Thank you !

1. For a large design(about 10,000,000 gates), how can we define the number of scan chains ?
My understanding:
a: the number of I/O that can be used as scan I/O
b: the DFF number can't exceed the upper limit (ex. 1,000 DFF),or the scan test vector may be too long.

2. When scan insertion, I define the number of scan chain. Then I create test ports, such as "test_si_1","test_si_2","test_so_1","test_so_2" and so on. Then I define scan signals ,test_si_# and test_so_#, as "test_scan_in" and "test_scan_out" signal. When I do this step. I should give the scan path info. How can I generate the scan path info ?
My understanding:
The synopsys command is "set_scan_signal test_scan_in -port test_si_# -chain chain_#". Here, I must provide the chain_1_#'s information. I know I should use the command "set_scan_path". But the number of chains may be about 200, I don't know how define these chains.

3. When I finish the scan insertion, there are so many tset ports in top module. I should use a control logic such as a mux to decrease the number of test ports and then connected with I/O pad, right ?

Hope for your answers.

Thank you very much !

In general, we need define scan input/scan output before scan insertion, also with scan clock etc. so we have very clear picture about scan architecture in mind before we take scan insertion.
what you problem like mux scan I/Os is project specific.
feel free to ask me.
regards,
Cheelgo
 

scan chain vector total test time

1. For a large design(about 10,000,000 gates), how can we define the number of scan chains ?
My understanding:
a: the number of I/O that can be used as scan I/O
b: the DFF number can't exceed the upper limit (ex. 1,000 DFF),or the scan test vector may be too long.


What u said is correct.
For large design , use as more scan chains as u can.
If there is not enough ports, and each scan chain contain more than 2000 DFFs,
maybe u can think about partial scan.

2. When scan insertion, I define the number of scan chain. Then I create test ports, such as "test_si_1","test_si_2","test_so_1","test_so_2" and so on. Then I define scan signals ,test_si_# and test_so_#, as "test_scan_in" and "test_scan_out" signal. When I do this step. I should give the scan path info. How can I generate the scan path info ?
My understanding:
The synopsys command is "set_scan_signal test_scan_in -port test_si_# -chain chain_#". Here, I must provide the chain_1_#'s information. I know I should use the command "set_scan_path". But the number of chains may be about 200, I don't know how define these chains.


Actually u could just ignore the "-chain" option if u r not care about which DFF is in which scan chain . Just use : "set_scan_signal test_scan_in -port test_si_# " is OK.

3. When I finish the scan insertion, there are so many tset ports in top module. I should use a control logic such as a mux to decrease the number of test ports and then connected with I/O pad, right ?

If u define the scan signal correctly , there should not be any extra test port.
Scan Clock : create_test_clock
Scan In/Out: set_scan_signal test_scan_in/test_scan_out
Scan Enable: set_scan_signal test_scan_enable
If u r using "autofix"
Test Mode : set_dft_signal
Reset : set_signal_type & set_dft_signal

Check the manual for more detail about the commands above.

Hope this help.
 

    V

    Points: 2
    Helpful Answer Positive Rating
care-abouts in scan chain?

With 10 mil gates, I assume that you have anywhere between 250k-500k flip-flops.
Assuming 500k FFs, you will need 500 scan chains to reduce it to 1000 FF per chain, which means you need 1000 scan I/Os!

Actually, the number of scan chains chosen depends on many factors, the most important ones are:
1. The number of available input and output ports on the chip that can be used as scan I/O.
2. The target ATE equipement configuration, how many scan chains it can support, and the memory depth behind each scan pin.
3. The total test time budget per chip.

If you have large number of I/Os that can be used for scan, and you have enough tester channels to accomodate those I/Os, you should maximize the number of scan chains to give you the shortest test time.

However, if you are restricted in either number of chip I/Os or the number of tester channels, you can try to use one of the scan compression methods availble through different tool vendors, e.g. Synopsys Adaptive Scan, Mentor TestKompress, Cadence OpMISR, or SynTest Virtual Scan. Each of these methods will give you full scan access with reduced chain length and uses a smaller number of I/Os.

Let me know if you want more info regarding scan compression techniques. The commercial tools will require a separate licence that may be expensive though.
 

set_scan_signal set_dft_signal

in commercial use Mentor tool could support scan insertion and test compression.

thanks,
cheelgo
 

set_scan_signal set_dft_signal

Thank you. We have a test compress tool (In House).
I am a newbie. Many things are strange to me.

dr_dft said:
With 10 mil gates, I assume that you have anywhere between 250k-500k flip-flops.
Assuming 500k FFs, you will need 500 scan chains to reduce it to 1000 FF per chain, which means you need 1000 scan I/Os!

Actually, the number of scan chains chosen depends on many factors, the most important ones are:
1. The number of available input and output ports on the chip that can be used as scan I/O.
2. The target ATE equipement configuration, how many scan chains it can support, and the memory depth behind each scan pin.
3. The total test time budget per chip.

If you have large number of I/Os that can be used for scan, and you have enough tester channels to accomodate those I/Os, you should maximize the number of scan chains to give you the shortest test time.

However, if you are restricted in either number of chip I/Os or the number of tester channels, you can try to use one of the scan compression methods availble through different tool vendors, e.g. Synopsys Adaptive Scan, Mentor TestKompress, Cadence OpMISR, or SynTest Virtual Scan. Each of these methods will give you full scan access with reduced chain length and uses a smaller number of I/Os.

Let me know if you want more info regarding scan compression techniques. The commercial tools will require a separate licence that may be expensive though.
 

scan insertion

Is there anybody can explain relationship between the BSD and Scan chain in synopys tools.Is it better if we multiplex the scan chains to jtag ports,so we can using only one pair of pads for all chains?is this acceptable for testers and ATE equipment
 

Re: Some problems about SCAN Insertion, wlecome to discuss t

dr_dft said:
Let me know if you want more info regarding scan compression techniques. The commercial tools will require a separate licence that may be expensive though.

I wanna know more info about Synopsys Adaptive Scan . Can you help me ?
 

Synopsys Adaptive scan is based on Illinois scan where each scan input fans out to multiple internal scan chain inputs. On the output side, it is like X-compact from Intel, where several internal scan chain outputs are XOR together to obtain a single scan output port.
The problem with Illinois scan is when 2 internal chains share the same scan input, the patterns the receive are correlated, which may lead to lower coverage if they share the same cone of logic.
To remove this coupling effect, Adaptive scan uses a few scan input ports as "fanout" select pins, so these select pins changes which two or more chains share the same scan input.

You can read more here:
**broken link removed**
 

Re: Some problems about SCAN Insertion, wlecome to discuss t

Hi,
Normally, I start scan insertion from netlist generated by "compile -scan". Now, I want to know if the netlist generated by "compile" not "compile -scan" what special attention should be paid ?
Thank you !

dr_dft said:
With 10 mil gates, I assume that you have anywhere between 250k-500k flip-flops.
Assuming 500k FFs, you will need 500 scan chains to reduce it to 1000 FF per chain, which means you need 1000 scan I/Os!

Actually, the number of scan chains chosen depends on many factors, the most important ones are:
1. The number of available input and output ports on the chip that can be used as scan I/O.
2. The target ATE equipement configuration, how many scan chains it can support, and the memory depth behind each scan pin.
3. The total test time budget per chip.

If you have large number of I/Os that can be used for scan, and you have enough tester channels to accomodate those I/Os, you should maximize the number of scan chains to give you the shortest test time.

However, if you are restricted in either number of chip I/Os or the number of tester channels, you can try to use one of the scan compression methods availble through different tool vendors, e.g. Synopsys Adaptive Scan, Mentor TestKompress, Cadence OpMISR, or SynTest Virtual Scan. Each of these methods will give you full scan access with reduced chain length and uses a smaller number of I/Os.

Let me know if you want more info regarding scan compression techniques. The commercial tools will require a separate licence that may be expensive though.
 

Re: Some problems about SCAN Insertion, wlecome to discuss t

Normally, I start scan insertion from netlist generated by "compile -scan". Now, I want to know if the netlist generated by "compile" not "compile -scan" what special attention should be paid ?

Logically, there is not much difference. If you are stitching with DFT compiler, all you need is to not declare the netlist as test_ready for a netlist that was not synthesized with the "-scan" option.
The main difference though is timing closure. With -scan option, the original synthesis takes the additional mux delay of a scan flip-flop into consideration, as well as some extra loading on the Q output. Without -scan option, the timing will be easily violated after scan insertion if not enough margin was given during synthesis.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top