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.

How to decide which clocks should be used for scan ?

Status
Not open for further replies.

raviram80

Member level 3
Joined
Jun 8, 2009
Messages
65
Helped
1
Reputation
2
Reaction score
1
Trophy points
1,288
Activity points
1,750
Hi All,

I have a general question on deciding the scan clocks? If there are 10 system clocks for example, how do we decide which clocks to use for scan?

What is the criteria for deciding that? Is it like a scan clock should cover certain percentage of flops in the design?

Please let me know,

Thanks,

Ravi
 

Re: Deciding Scan Clocks

Baiscally, I pick the scan clock scheme for ease of clock tree generations and STA.

The easiest thing to do is that each clock domain has dedicated scan clock. By doing so, once you generate clock trees in function mode and it has good clock skews within the clock domain, you don't have to worry about the clock skew in scan mode. Also scan capturing paths are checked with STA in functional mode so that you don't have to spend a lot of time to fix the capturing paths after you close the timing in function mode.

if you don't have that many pins for scan clocks, one of good approaches is letting the clock domains which dont' directly communicate share the scan clock. The reason is obviously to make the STA easier.
 
Last edited:

Re: Deciding Scan Clocks

Thanks for your reply,
"
if you don't have that many pins for scan clocks, one of good approaches is letting the clock domains which dont' directly communicate share the scan clock. The reason is obviously to make the STA easier. "


How are we making STA easier? I am not getting this? Could you please explain this a little more
 

Re: Deciding Scan Clocks

Within each clock (functional) domain, you'd do rigorous STA and guarantee that no timing violations within the domain. The issue to share the scan clock with different clock domains is that the paths from one domain to another domain become valid in scan mode, while they are not valid paths in function mode(therefore you set them false path in functional STA) and you start seeing timing violations that you haven't seen in functional mode STA.
If the path between those domains doesn't exist, you wouldn't see this issue even though they share the same scan clock so that it's better to use the same scan clock to the blocks that are logically far from each other.
 

Re: Deciding Scan Clocks

"If the path between those domains doesn't exist, you wouldn't see this issue even though they share the same scan clock so that it's better to use the same scan clock to the blocks that are logically far from each other. "

In the capture mode , e.g the output of flop from one clock domain goes through some logic and is captured in another flop driven by another clock and the only path for those faults in the logic to be tested is through the response capture by the flop in second clock domain, then how can we avoid this issue without loss of coverage

So what you are suggesting is, there are two ways

1. we toggle only one clock and do not toggle the other clock in capture and this would mean loss of coverage

2. by defining two clocks the tool can intelligently stagger the clocks (pulse one clock once followed by pulsing second clock) in capture so that we still capture the response without any timing violation and also no loss of coverage
 

Re: Deciding Scan Clocks

then how can we avoid this issue without loss of coverage
You don't lose coverage.

1. we toggle only one clock and do not toggle the other clock in capture and this would mean loss of coverage
No it doesn't lose coverage. It just takes a few ten/hundred more cycles to complete the test by staggering the scan clocks in capture mode.
2. by defining two clocks the tool can intelligently stagger the clocks (pulse one clock once followed by pulsing second clock) in capture so that we still capture the response without any timing violation and also no loss of coverage
That's how the test is usually done unless you want to make all the sequential cells in the chip synchronous which is a design nightmare.
 

Re: Deciding Scan Clocks

Thanks a lot for your help. One last thing,

If we have two clock domains interacting with each other and sharing clock, the timing violation that you were referring to above was setup only I think. Can hold violation occur if we have just one capture pulse in capture mode and new data cannot come from previous flop?

I may not be very accurate here but still giving a shot.
 

Re: Deciding Scan Clocks

Even with a single pulse, you can get hold viols if the paths have enough clock skew.

The 2nd clock may capture the data launched by the rise edge of the 1st clock, which is a hold violation.
Code:
----------------------+    +------------------
                      |    |
                      +----+

-------------------------+    +---------------
                         |    |
                         +----+
 
Last edited:

Re: Deciding Scan Clocks

Thanks a lot for providing that description. Since we are on the topic I would want to enquire about atspeed test with clock domain crossing. Can we do vector generation as below



The capture of first clock domain provides the launch of second clock domain. We could write this kind of sequence using any of the tools. Do you think this kind of staggering is possible for at speed also?

Thanks,
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top