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.

[SOLVED] capture path across clock domain in DFT mode

Status
Not open for further replies.

owen_li

Full Member level 3
Joined
Jul 22, 2007
Messages
150
Helped
17
Reputation
34
Reaction score
15
Trophy points
1,298
Activity points
2,301
Hi.

I just had a question about the cross clock domain capture issue in DFT.
As we know, we can insert a lockup latch on the scan chain who is crossing the clock domain, to ease the hold timing fix.
But how to hanle the capture path which is asynchronous from clock domain A to clock domain B ?
This path is asynchronous in function mode but it is synchronous in DFT mode.
coz the clock skew is very indeterministic between these two clocks in DFT mode, the hold violation is very hard to fix and also it is needless.

Thanks!
 

The question is not very clear....but I think you are worried about hold time between two asynchronous clocks in DFT. Actually there is no way this can be even in functional mode. the clock domain crossing between two asynchronous clock is handled by synchronizers in the receiving domain which are special flop structures. the idea is to treat them as false paths during STA.
 

The question is not very clear....but I think you are worried about hold time between two asynchronous clocks in DFT. Actually there is no way this can be even in functional mode. the clock domain crossing between two asynchronous clock is handled by synchronizers in the receiving domain which are special flop structures. the idea is to treat them as false paths during STA.

Hi, artmalik
Thanks for your reply. I know the hold timing in functional mode can be ignored. My concern is the cross domain path in DFT mode.
Coz the clocks will be synchronous in DFT mode, and the result of the capture path will be shift out cycle by cycle.
So the hold timing violation will be dangerous in DFT scenario.
 

You should break the scan chain at the asynchronous interface.... you should scan through an asynchronous interface.... as you have no control over the scan hold time/setup time requirements.
 

Hi artmalik. Did you mean "you should never scan through an asynchronous interface" ?
 

https://anysilicon.com/lock-latch-implication-timing/
This is one document which explains the usage....of lock up latch in the process of fixing the hold time.... if you can avoid it is even better.

Hi artmalik

I think you may misundertood my question.
What I mean is the cross clock domain path on the capture path.
Yes, if this isssue occurs on scan path, we can insert lockup latch to fix the hold violation.
But what shall we do on the crossclock domain capture path?

Thanks!
 

Hi owen_li,

I understand your concern. The lockup-latches only help during the shift phase and not during the capture phase.

It seems one way to do this is to have different clock control blocks for each domain. During shift phase scan clocks will all be same. In capture mode only one of the domain is in scan capture mode, other domain is clock gated. So you'll basically need to generate multiple patterns to test the clock crossing interface.

I'm not an expert in this so what I'm implying might not be fully correct.
 

Hi owen_li,

I understand your concern. The lockup-latches only help during the shift phase and not during the capture phase.

It seems one way to do this is to have different clock control blocks for each domain. During shift phase scan clocks will all be same. In capture mode only one of the domain is in scan capture mode, other domain is clock gated. So you'll basically need to generate multiple patterns to test the clock crossing interface.

I'm not an expert in this so what I'm implying might not be fully correct.

Thanks harpv.
I think you are correct. I found some material on google about this topic. It said that ATPG will generate multiple test patterns and will let one clock domain toggle the capture clock. I want to want to find some DFT experts to confirm it.
If there are many clock domain crossing like this case, the test time will increase a lot. Coz only on clock domain can take the capture action.
So is there any effective way to control the test time in this scenario ?

Thanks!
 

I guess if you want to avoid using multiple patterns, i believe in the same pattern you can have multiple capture phases spaced accordingly. And during each capture pulse you'll have to make sure only domain is active.

So you reduce the test patterns and hence the test time.

Again this is only theoretical knowledge I have, you'll have to track down a DFT expert to get the complete picture.
 

Hello All,

We can do multiple capture if the clocks are independent.
To cover the clock domain crossing faults, we can do :
e.g. 2 consecutive scan stitched flops.
1st flop ff1 : clk1 and
2nd flop ff2 : clk2,
there is some combo logic between ff1 and ff2.
In such case,
1. Shift-in all chains
2. Pulse clk1
3. Pulse clk2
4. Shift-out all chains.
By doing sequentially pulse of capture clock we can cover the faults between clk1 and clk2 domain crossing.
Above procedure is not for all the patterns but only to cover clock domain crossing faults.

Hope it solve your question.

--
Thanks & Regards,
Maulin Sheth.
 
Hello All,

We can do multiple capture if the clocks are independent.
To cover the clock domain crossing faults, we can do :
e.g. 2 consecutive scan stitched flops.
1st flop ff1 : clk1 and
2nd flop ff2 : clk2,
there is some combo logic between ff1 and ff2.
In such case,
1. Shift-in all chains
2. Pulse clk1
3. Pulse clk2
4. Shift-out all chains.
By doing sequentially pulse of capture clock we can cover the faults between clk1 and clk2 domain crossing.
Above procedure is not for all the patterns but only to cover clock domain crossing faults.

Hope it solve your question.

--
Thanks & Regards,
Maulin Sheth.

Good explanation. Thanks Maulin & harpv
 

Thanks for the reference to our blog....
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top