DFT PLanning on a new chip

Hi Guys,

I would like to know your inputs on DFT PLanning needed for a new design partiularly

1. What flops to make scannable and which flops to avoid scannable

2. How to decide the number of chains?

3. Do we keep separate scan i/os or mux them with functional i/os? What would be the criteria for that?

4. How do we make sure that each flop is getting clock and reset? Is a separate test clock used or it is the functional clock?

5. How about clock domains? How to decide which flops of which domains can be combined or have to be kept in separate chains

6. Does PLL Atspeed vector generation play a deciding role in choosing which flops can be combined in one chain?


I know lot of questions, but it would help me as well as many others if you all can provide your inputs.

Please feel free to add more questions if you want. That will also help.

Thanks a lot,

1. What flops to make scannable and which flops to avoid scannable
Shift registers are typically the only flops left out of the scan chain. Some reset and metastability flops may make sense to leave off the scan chains. Any devices left off the chain will need a separate manufacturing test suite.

2. How to decide the number of chains?
typically the more scan chains you have the shorter your tester test time is. it takes less time to load 10000 flops 30 (30 scan chains) each shift clock than if you could only load 2 (2 scan chains) each shift clock. if you only have 2 seconds of test time to do all of your testing you may find that you run out of test time...

3. Do we keep separate scan i/os or mux them with functional i/os? What would be the criteria for that?
Typically you do not have extra pads on designs; it is often hard to dedicate 5 signals to test. Typically all scan inputs and outputs are shared with primary i/o.

4. How do we make sure that each flop is getting clock and reset? Is a separate test clock used or it is the functional clock?
In order to be testable, every clock pin and every reset pin should be controllable by a primary input during test mode.
During design you should run dft-rule-checks as part of your synthesis flow.
For high fault coverage, you should fix every dft warning/violation.

5. How about clock domains? How to decide which flops of which domains can be combined or have to be kept in separate chains
If possible, do not mix clock domains for test;it is a nightmare...
If necessary, you may insert retiming latches OR ensure the stitching is such that you do not have a fast test-clock flop communicating with a delayed test-clock flop.

6. Does PLL Atspeed vector generation play a deciding role in choosing which flops can be combined in one chain?
To me at-speed test means the tester supplies the fast clock. As such, you will need to bypass any internally generated clocks.
Its all about fault coverage; the more you can control the flops from a primary I/O the better your coverage will be. If the tester can't easily control the clock, your fault coverage with suffer.

Thanks jpvsoccer

Hi, one more thing. You did not mention this in your original posting, but boundary scan capability is very important for chip/board-level and block-level testing. At the chip/board level the interconnect between devices needs to be verified. For complex SOC designs, boundary scan can be used to verify connectivity between blocks as well as provide block-specific stimulus/response.

If interested, here is a good summary of the requirements and benefits of JTAG/Boundary-Scan
JTAG - A Technical Overview - TAP Signals and Instructions

Hi Jpvsoccer,

You wrote this

5. How about clock domains? How to decide which flops of which domains can be combined or have to be kept in separate chains
If possible, do not mix clock domains for test;it is a nightmare...
If necessary, you may insert retiming latches OR ensure the stitching is such that you do not have a fast test-clock flop communicating with a delayed test-clock flop.


Now I have two questions,

Let's say the flops from two different clock domains are interacting and are part of the same chain.

One clock domain is 30Mhz and other is 500 Mhz

1. Does it matter if my capture is happening on slow speed 10Mhz whatever the system frequency is?

2. If these flops are in the same chain and being captured using the same slow clock of 10 Mhz could it cause any violation if they are interacting with each other.

I am thouroughly confused here.

Please let me know.

Thanks,

1.Technically, there is no such thing as clock frequency in the capturing mode because all you apply during capturing mode is ONE pulse. Having only one pulse, there is no concept of 'frequency'. In your scenario, if those clocks are comming from the different pins, do not toggle multiple clocks at the same time during the capture mode. Apply a pulse to one of them, and then apply another pulse to another clock. and then another.... stagger the pulsees to each clocks with enough interval and don't overlap those pulses from the different clock domains.
2. No.

Hi,

The problem that I see when sharing clock domains on a single scan chain it that the clock tree insertion delays are likely very different for the two clocks; as such you will have a slow domain and a fast domain.

If you do not do anything special about the interface between the two domains, you will have to guide the scan insertion so that the slow domain is stitched first followed by the fast domain.

Remember, we are worried about hold violations during scan shifting, so frequency is not the problem.

Now, one more thing...don't forget that AT-SPEED ATPG is sometimes a requirement.
As such, in this scenario I don't know if it makes sense to share scan chains between clock domains.

Hi lostintxlation/jpvsoccer,

I want to make sure here one thing here.

I know two scenarios

1. Everything that you mention here about the capture pulse, Is that a high speed pulse.?
Please Confirm this. I always used to think that we have a low speed capture pulse.

in the designs that I know it is generally the same clock used for shift,
so the clock for capture is slow speed clock of 10Mhz same as used to shift and as you mentioned above there is no chance of any violation in slow speed clock for cross domain paths.

2. The second scenario that I know of is when the Capture domain has two PLL at speed clocks which are high speed pulses generally output from On-chip clock generator.

Now I know the below for the case above.

1. If I have two clock domains of say 100 Mhz and 500 Mhz,

I have two cases for this

a. 400 Mhz and 500 Mhz clock are not interacting with each other, so during capture cycle, we can use the same clock for both of them and have pair of launch and capture at the same time for both of them

b. 400 Mhz and 500 Mhz clock are interacting with each other.

I have the below options about this

i). Use a common clock say 500 Mhz for them and ignore the hold violations occuring on 400Mhz. So I will have launch and capture pulse for 500 Mhz here.

Also here there may be paths that are not valid functional paths and could cause violations. We can also ignore those violations while doing vector generation.



ii) Use separate clocks if your pll allows and test these domains separately, ignoring cross clock domain paths.

I know lot of questions but please confirm

Thanks and Regards,

Hi, lets assume that you have a clock module where you mux the test clock for all of your clocks. All of your clocks have different clock-tree buffer delays. The fact that the test clock is the same waveform for scan chains where more than one system clock is used does not matter; you still pass the test clock through your test-muxes into the respective clock trees. As such, you will likely have a fair amount of skew between between the test-clocks that arrive at your scan chain.

Hi Jpvsoccer,

I could not understand your point as in how is this related to the question I asked, can you confirm if the capture we are talking about is not a slow speed capture and we are talking about Atspeed case as I ask in my question.

Please let me know,

Thanks,

Hi, sorry for the confusion...CTS can get a bit sticky...

when I talk about a slow clock I do not mean low frequency; I just mean a clock leaf pin that has more delay than another clock leaf pin. clock leaf pin being the pin on the buffer that drives a particular flop CK pin.

you never have a CTS generated clock arriving at the exact same time at any flop in your design; there is always some skew; that is why you plan for clock uncertainty in synthesis.

at-speed or slow speed, you still have two different length clock trees which will likely produce timing problems between the two flops that communicate during scan shifting.

Also could I please know the answer to the second part of the question

2. The second scenario that I know of is when the Capture domain has two PLL at speed clocks which are high speed pulses generally output from On-chip clock generator.

Now I know the below for the case above.

1. If I have two clock domains of say 100 Mhz and 500 Mhz,

I have two cases for this

a. 400 Mhz and 500 Mhz clock are not interacting with each other, so during capture cycle, we can use the same clock for both of them and have pair of launch and capture at the same time for both of them

b. 400 Mhz and 500 Mhz clock are interacting with each other.

I have the below options about this

i). Use a common clock say 500 Mhz for them and ignore the hold violations occuring on 400Mhz. So I will have launch and capture pulse for 500 Mhz here.

Also here there may be paths that are not valid functional paths and could cause violations. We can also ignore those violations while doing vector generation.



ii) Use separate clocks if your pll allows and test these domains separately, ignoring cross clock domain paths.


Thanks,

hello people.
it has been really informative to read through this thread.
i am a newbee to asic design and has been deployed in the DFT section .
right now i am doing ATPG (using Tetramax).
i would be highly obliged of you guys could point me to some material related to DFT and ATPG(both basic and advanced).

thanx and regards:smile:

Hi,

2. The second scenario that I know of is when the Capture domain has two PLL at speed clocks which are high speed pulses generally output from On-chip clock generator.

1. If I have two clock domains of say 100 Mhz and 500 Mhz,
a. 400 Mhz and 500 Mhz clock are not interacting with each other, so during capture cycle, we can use the same clock for both of them and have pair of launch and capture at the same time for both of them
JPV: if running at-speed and using the faster clock, won't you be violating setup on the slow clock domain by running it faster than you synthesized the logic for?

b. 400 Mhz and 500 Mhz clock are interacting with each other.
i). Use a common clock say 500 Mhz for them and ignore the hold violations occuring on 400Mhz. So I will have launch and capture pulse for 500 Mhz here.
JPV: how are you going to ignore HOLD violations? Won't they cause compare-fails?
JPV: what about setup violations within the slow clock domain flops?

Also here there may be paths that are not valid functional paths and could cause violations. We can also ignore those violations while doing vector generation.
JPV: how?

JPV: here is an interesting article on AT-SPEED testing:
https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.120.7929&rep=rep1&type=pdf

jpvSoccer said:

Hi,

2. The second scenario that I know of is when the Capture domain has two PLL at speed clocks which are high speed pulses generally output from On-chip clock generator.

1. If I have two clock domains of say 100 Mhz and 500 Mhz,
a. 400 Mhz and 500 Mhz clock are not interacting with each other, so during capture cycle, we can use the same clock for both of them and have pair of launch and capture at the same time for both of them
JPV: if running at-speed and using the faster clock, won't you be violating setup on the slow clock domain by running it faster than you synthesized the logic for?

b. 400 Mhz and 500 Mhz clock are interacting with each other.
i). Use a common clock say 500 Mhz for them and ignore the hold violations occuring on 400Mhz. So I will have launch and capture pulse for 500 Mhz here.
JPV: how are you going to ignore HOLD violations? Won't they cause compare-fails?
JPV: what about setup violations within the slow clock domain flops?

Also here there may be paths that are not valid functional paths and could cause violations. We can also ignore those violations while doing vector generation.
JPV: how?

JPV: here is an interesting article on AT-SPEED testing:
https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.120.7929&rep=rep1&type=pdf

Click to expand...

JPV : you can mask the violating points by providing ignore list to the scan generation tool and it will be marked as X in the vector and so the response will not be compared.

raviram80 said:

JPV : you can mask the violating points by providing ignore list to the scan generation tool and it will be marked as X in the vector and so the response will not be compared.

Click to expand...

If the path is completely ignoreable, that path is redundant and why do you keep such paths in your design ? The thing is no they are not completely ignoreable. You just can ignore the viols on some occasion, but the same path cannot be ignored at other occasion.
You need to be careful about it, otherwise you would have a massive chip failure in the lab, or even worse in the field.

Hi, and to add to the above comment. Any time you have an exception (Xing out some signals) you open yourself up for additional problems down the road...it is best to figure out a way to configure/design the chip so that you have the fewest possible number of exceptions.

You handle separate clock domains by:

1) Assigning each clock domain a separate test clock pin.

2) During test generation force each clock to be pulsed in a separate test cycle. This will prevent you from having to mask cross clock domain captured values.

3) The scan stitching tool will add lockup latches as needed on the scan chains so you should not have to concern yourself with cross clock domain timing problems while shifting.

4) You can add hardware to the PLLs so that they can be used to apply a fast accurate double pulse for at-speed testing. This should be controlled by your tap controller so it is used only during the application of a test.

5) Don't make flip-flops scannable where:

1) The delay added by test logic causes timing problems in the functional operation of your chip.
2) The flip-flop is used to apply test clocks.