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.

Lockup Latch for DFT purpose

Status
Not open for further replies.

Varun124

Junior Member level 3
Junior Member level 3
Joined
Jul 3, 2019
Messages
28
Helped
0
Reputation
0
Reaction score
0
Trophy points
1
Activity points
224
Hi all,
I was reading a document about lockup latches and found out that these are added on scan path for different clock domains to avoid hold violation. Why we are added along the scan path where we are using same scan clock? How exactly we are getting hold violation in the scan path if we are not using lockup latches.
Thanks in advance
 

Hi all,
I was reading a document about lockup latches and found out that these are added on scan path for different clock domains to avoid hold violation. Why we are added along the scan path where we are using same scan clock? How exactly we are getting hold violation in the scan path if we are not using lockup latches.
Thanks in advance

Lock up latches allow you to have flops on multiple clock domains in the same scan chain. Flops of the same clock domain will be grouped together separated by a lock up latch.

FF_0_clk1->FF_1_clk1->FF_2_clk1->Lockup_latch->FF_0_clk2->FF_1_clk2->...

Since clk1 and clk2 are async clocks it is not guaranteed that the rising edges will be aligned when going between clock domains. The lockup latch guarantees this transfer.

The lockup latch allows a half cycle to make the flop to flop transfer. The lockup latch clock is clk1 inverted. Google "lockup latches in scan chain" to get detailed information on the operation.

Hope this helps
 

They don't use lockups in functional logic b/w asynchronous domains but synchronizers like 2-D flops (among other structures for multi-bit transfers). Phase difference b/w any two edges of async clocks is not guaranteed and so lockups are not exactly a reliable solution. Does this mean the 2 scan clocks are generated synchronously from the OCC to make sure the lockup is a reliable solution?

Similar arguments could be made for lockups inserted in EDT logic (decompressor in Mentor implementations) to ensure transfer b/w EDT and scan clocks.
 

They don't use lockups in functional logic b/w asynchronous domains but synchronizers like 2-D flops (among other structures for multi-bit transfers). Phase difference b/w any two edges of async clocks is not guaranteed and so lockups are not exactly a reliable solution. Does this mean the 2 scan clocks are generated synchronously from the OCC to make sure the lockup is a reliable solution?

Similar arguments could be made for lockups inserted in EDT logic (decompressor in Mentor implementations) to ensure transfer b/w EDT and scan clocks.

Lockup latches are placed in the scan-path (Q to scan_data_in), not in the functional path. It is used to reliably transfer scan_data in between clock domains during scan shifting.
 

Lockups won't work b/w any 2 async domains whether on the scan or the functional path was the point. If they were, they would've been freely used on functional paths instead of the common 2d-flop synchronizer. Ergo, the only valid scenario for inserting lockups b/w 2 scan domains is for them to be synchronous.
 

Lockups won't work b/w any 2 async domains whether on the scan or the functional path was the point. If they were, they would've been freely used on functional paths instead of the common 2d-flop synchronizer. Ergo, the only valid scenario for inserting lockups b/w 2 scan domains is for them to be synchronous.

I do not believe that your statement is correct. Lock-up latches will work between two async clock domains within the scan path. Refer to my original post. The clock of the lock-up latch is CLK1 INVERTED. This clock inversion will allow the transfer between CLK1 and CLK2 flops to occur reliably. This inversion allows a 1/2 cycle for this transfer to occur. Draw out the waveforms.

As to why this method is not used in functional logic instead of synchronizers, I would defer to a logic designer for more detail but I suspect syncronizers are more robust for high speed applications, the scan shift clock is typically slow speed.
 

Skew is undeterministic b/w 2 async domains because the phase difference is not repeatable. Draw a 4ns and 6ns clock - consider them to be synchronous - and see how the waveforms start repeating after the 3rd/2nd cycle respectively. The same 4ns and 6ns clock if asynchronous would not have determinism b/w any 2 edges. The half cycle added by lockups to ease hold closure is useless because the hold skew b/w async clocks itself is unknown.


I suspect syncronizers are more robust for high speed applications
Synchronizers are used as a non-negotiable rule whether b/w high or low speed async clocks. No ifs and buts there.
 

We have two clock domains CLK1 and CLK2. The clock trees length (clock latency) are different in these domains. We did not balance them between domain (only balance inside each domain).

During scan we have only one clock SCANCLK. It was delivered to flops through the same clock trees as in normal mode of operation. As we have in the same scan chain flops from different clock domains we can have hold violation due to big clock skew. So lockup latches help us with this hold violation ONLY during scan mode when ONLY one clock exist. This lockup latch does not work during normal mode of operation.
 

Lock up latches are used BOTH when one scan clock exists and skew is discovered post layout (i.e. not during scan insertion when skew is unknown) or between 2 scan clocks with skew in mixed scan-stitched chains. That is why lockups are automatically inserted by tools in these 3 cases where 2 clocks exist - bypass mode when concatenating scan chains clocked by different clocks, b/w decompressor and internal scan chains (by TestKompress) and while mixing clocks during scan stitching (when instructed using the insert_test_logic -merge command).

The question is anyway about applicability of lockups in synchronous vs asynchronous clocks in scan mode. Lockups don't solve the problem of metastability/data loss/incoherence caused by async clocks. An indeterministic half-cycle to solve a hold violation b/w 2 async clocks will not work. And even if shift is slow, setup violations will occur if both are async.


This lockup latch does not work during normal mode of operation.
Yes, I understand scan lockups are not exercised in functional mode (simply because that path is not traversed). Latches/buffers are however used to fix hold violations b/w sync clocks in functional mode.
 
Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top