Lock-Up Latch: Implication on Timing

Lock-Up Latches are important elements for any STA engineer while closing timing on their DFT Modes: specially the Hold Timing Closure of the Shift Mode. While shifting, the scan chains come into picture, which are nothing but the chains of Flops involving the output pin of one flop, connected to the Scan-Input or Test-Input pin of the other flop, and so on, forming a chain. 

Now, imagine that we have two functionally asynchronous domains 1 and 2. Functionally asynchronous means that during the normal mode of operation (Functional Mode), the two domains do not interact with each other. However, very rarely do the designers have the liberty to make a separate scan chain for functionally asynchronous domains. Let's consider the following scenario: where domain 1 has the average clock latency of 3ns, and domain 2 has the average latency of 6ns. And the time period of the test clock is, let's say, 10ns.

Now, let's see the timing checks for this scenario. The output of the last flop of the domain 1 is in scan-chain and connected to the Test-Enable input of the first flop of domain 2. The check would be like: 

Owing to the positive clock skew, the setup check would be relaxed, but hold would be critical. Two possible options to fix the hold timing:

• Insert the buffers, to add sufficient delay, so that hold is finally met.

• To add the Lock-Up Latch between the two flops where scan chain crosses the functional domains.

The first might not be a robust solution because the delay of the buffers would vary across the PVT Corners and RC Corners. In the worse case, there might be a significant variation in the delays across corners and you might witness closure of timing in one corner, but violation in other corner!

Second solution is a more robust solution because it obviates the above scenario. Hence see how it does it.

 

Timing Check would be like:

Hence, both setup and hold checks are relaxed!!

[Please note that in the above circuit, the latch is a negative level triggered latch.]

DFT Modes: Perspective

As more number of transistors are finding their way onto a single SoC, Design for Testability (DFT) is becoming an increasing important function of the SoC design cycle. As the technology nodes are shrinking consistently, the probability of the occurrence of the faults is also increasing which makes DFT an indispensable function for modern sub-micron SoCs. What are the possible faults within an SoC and whhat all ways are possible to detect them? We will take them up briefly.

Imagine that you own a chip manufacturing company for the automotive industry. The end application can be something meant for infotainment, engine management, rear view camera, ethernet connectivity, power  glasses or for a critical application like collision detector or air-bag control etc. You wouldn't like to sell a faulty chip to your customers for two main reasons:

• Trust of the customer which would impact the goodwill of the company.
• Loss of business: Maybe because the customer opted for some other semiconductor vendor or even worse, the chip failed at the user end and he sued your customer who ultimately sued you!

Hence, it is pretty important to test the chip before shipping it out to the customers.

Types of fault and their detection:

• Structural Fault: Basically refers to the faults due to faulty manufacturing at the fabs. Even a tiny dust particle has cause shorts or opens in an SoC. 
  Let's try to understand it from our example. Let's say you manufactured the chip but there is a fair probability  that there might be some structural inadequacies in the form of shorts or opens. Imagine any digital circuit. Single short or a single open can cause the entire functionality of the device to go haywire. Structural testing is done during the DFT tests or modes called as Shift and Stuck-At Capture. We'll discuss these in detail in the upcoming posts. Note that these tests are conducted after manufacturing, before shipping the part to the customer.
  
• Transition Faults: Signal transitions are nothing but the voltage levels while they switch from either 'high' to 'low' or vice-versa. There is a designated time before the clock edge when all the signals should be stable at the input of the Flop (a very crude definition of setup time) and also a designated time after the clock edge when none of the signals should change their states at the input of the Flop (a very crude definition of hold time). Any such fault in the transition times (conversely: setup or hold violations) is referred to as a transition fault.
  
  
  Going back to our example. Suppose that you first filtered out the chips which had some structural fault. Now you would test the remaining chips for transition faults. What would happen if you ship a chip with a transition fault to a customer? If it had a setup violation, the chip will not be able to work at the specified frequency. However, it will be able to work at a slower frequency. If it had a hold violation, the chip will not be able to work at all! One possible consequence from our example could be that in an event of a collision you would expect a few micro- or nano- seconds for the air bag to open up, it might ending up taking seconds! Unfortunately, it would be too late.
  The At-Speed test is used to screen the chip for transition faults.
  

  
  

  
  

  Broadly speaking, there are only two types of the faults as discussed above. However, there's another possibility which can arise. 

  
  Imagine that your car has an SoC which senses a collision and opens the  air bag  within a few micro-seconds of the collision. You would expect it to open up if such a scenario arises. But what if your car is, let's say, 6 years old and the chip is now not functioning as expected. In this case, you would like to test the chip first. And if it is fine, you may proceed on to ignite the engine and start the car. Such a scenario would demand conducting a test while the chip is in operation. Such a DFT test is called LBIST Test (Logical-Built-in-Self Test). In an LBIST test, one would be testing the entire chip or a sub-part of it for structural and/or transition faults. Such a test for memory is referred to as MBIST Test (Memory-Built-in-Self-Test).
  
  An important characteristic of a built in self test is that it is self sufficient. It would carry out the test internally, following a software trigger, without any external input; carry the test; and send out a signature in terms of PASS/FAIL.
  
  A failed LBIST test on the air-bag chip, might flash a warning and can prevent the user from starting the car engine! It might sound cruel, but it can surely save your life!!
  
  In the upcoming posts, we would discuss these from the design perspective. Stay tuned!

Parallel to Serial Converter

Let's discuss the design of a Parallel to Serial Converter. Here's the crude problem statement.

You have 8 FFs, each working at a frequency of 10MHz and sending out a parallel data which effectively would be 8-bit wide. We intend to convert this data into a serial one, where 1 FF would output the data serially in order of first FF, then data of second FF and so on. Refer to the diagram below:

Such a parallel to serial converter might be useful in applications requiring Serial Communication which maybe interface to a microprocessor or a microcontroller; interface between your monitor and the CPU or any application which might involve serial processing of information.

Now let's proceed for the design. Note that:

• We have 8-bits of input data, and we want to output them one at a time. This suggests the use of a multiplexer. The size of this multiplexer would obviously be 8:1.
• Apart from the inputs, the multiplexer would have select lines (3 select lines for a 8:1 MUX) and we need to control these lines. Select lines need to be controlled in such a way that first the FF1 is selected, then FF2 and so on. 
• Recall the functionality of a multiplexer. The first bit is selected when select lines would be {S2,S1,S0} = 000, Second bit when {S2,S1,S0} = 001. Hence we can use a binary counter which would count from 000 to 111 in a binary manner.
• What would be the frequency of this counter? Note that for every one cycle of input data, we need to 8 outputs corresponding to 8 input FFs. Hence the frequency of the counter would be:

Freq. = 8 X 10 MHz = 80 MHz

Here's the final design: