Friday, July 10, 2026

Why Virtual Clock?

 What is a virtual clock: By definition, a virtual clock is a clock without any source. Stating more clearly, a virtual clock is a clock that has been defined, but has not been associated with any pin/port. A virtual clock is used as a reference to constrain the interface pins by relating the arrivals at input/output ports with respect to it with the help of input and output delays.


How to define a virtual clock: The most simple sdc command syntax to define a virtual clock is as follows:
                create_clock –name V_CLK –period 10
The above SDC command will define a virtual clock “V_CLK” with period 10 ns.

Purpose of defining a virtual clock: The advantage of defining a virtual clock is that we can specify desired latency for virtual clock. As mentioned above, virtual clock is used to time interface paths. Figure 1 shows a scenario where it helps to define a virtual clock. Reg-A is flop inside block that is sending data through PORT outside the block. Since, it is a synchronous signal, we can assume it to be captured by a flop (Reg-B) sitting outside the block. Now, within the block, the path to PORT can be timed by specifying output delay for this port with a clock synchronous to clock_in. We can specify a delay with respect to clock_in itself, but there lies the difficulty of specifying the clock latency. If we specify the latency for clock_in, it will be applied to Reg-A also. Applying output delay with respect to a real clock causes input ports to get relaxed and output ports to get tightened after clock tree has been built. Let us elaborate it in some detail below. Let us assume clock period to be 10 ns and the budget allocated to be 3 ns inside; thus, having a "set_output_delay" of 7 ns.


 virtual clock is used to time interface paths. Figure 1 shows a scenario where it helps to define a virtual clock. Reg-A is flop inside block that is sending data through PORT outside the block. Since, it is a synchronous signal, we can assume it to be captured by a flop (Reg-B) sitting outside the block. Now, within the block, the path to PORT can be timed by specifying output delay for this port with a clock synchronous to clock_in. We can specify a delay with respect to clock_in itself, but there lies the difficulty of specifying the clock latency. If we specify the latency for clock_in, it will be applied to Reg-A also. Applying output delay with respect to a real clock causes input ports to get relaxed and output ports to get tightened after clock tree has been built.
Figure 1: Figure to illustrate virtual clock

Case 1: Applying "set_output_delay" with respect to real clock (R_CLK)
Pre-CTS scenario: Here, if we apply any latency to the clock, it will be applied both to launch as well as capture registers (capture register is imaginary here). So, we unltimately get a full cycle to time the path. In other words, applying or not applying a latency to the clock will time the path as needed.
Post-CTS scenario: Post-CTS, we need to "set_propagate_clock RCLK" in order for clock latencies to come into effect. Doing so, the launch register's actual clock latency will come into picture. However, since, capture register is imaginary, there is no clock built onto it and its latency will be zero. So, we get (clock_period - RCLK_latency) as the actual phase shift to time the path. Thus, timing path gets tightened by "RCLK_latency".
Case 2:  Applying set_output_delay with respect to virtual clock (VCLK)
Pre-CTS scenario: In this case, in order to provide full cycle for the path to be timed; if we have applied any latency to RCLK, we will have to apply the same latency for VCLK as well.
Post-CTS scenario: After CTS is built and clocks are propagated, network latency of RCLK will be overridden by actual latency. But VCLK will not be propagated and its source + network latencies will still be reflected as applied in constraints. If (VCLK_source_latency + VCLK_network_latency_user) is equal to (RCLK_source_latency + RCLK_network_latency_CTS), we will still see the same timing path as we see pre-CTS.
Thus, the solution to the problem is to define a virtual clock and apply output delay with respect to it. Making the source latency of virtual clock equal to network latency of real clock will solve the problem.

Can you think of any other method that can serve the purpose of a virtual clock?

Saturday, November 18, 2023

ICG Enable Timing Issue

As we know Integrated Clock Gating cells are used to reduce dynamic power dissipation in the design, which is being Enable by CTRL logic. To get the glitch free output from ICG cell , it should meet the timing requirement (setup/hold) at enable pin of ICG cell.



In the above figure as we seen ICG cell is driving multiple flops which is being enabled by control logic flop. suppose L2 & L3 is the latency from clock port to ICG & flops. So our ICG cell latency(latency from ICG output clock to flops) will be

                                      ICG latency = L3-L2

Ideally one ICG cell can drive infinite flops, as no. of flops going to increase driven by ICG cell,tool is going to add more buffer in the clock path to balance clock tree, which will increase the ICG latency.

As L3 latency going to increase, results in increase in ICG latency, as clock period is fixed so now we are having lesser clock period than before to meet setup timing at EN pin.
So we can conclude that Larger the ICG latency , more critical the ICG enable timing.
It is always advisable to address ICG timing in place/pre-cts stage, as after CTS it can be too late for the design to address ICG timing violation.
we know that Pre-cts timing analysis used ideal clock latency for all clock pins,that means L2=L3, & ICG latency will be 0.

As ICG latency is 0 ,which will make ICG Enable timing analysis too optimistic, because now ICG cell will get full clock to meet setup at Enable pin(before it get only L3 - ICG Latency). So, In Pre-cts actual ICG violations are not seen, therefore not fixed in the design.
To overcome this design problem ICG optimization is a technique recommended for designs having critical ICG enable timing.In the next post we will discuss about ICG optimization technique, how it is executed.




Thursday, November 22, 2012

RTL - GDS flow


The flow chart for the GDS – RTL flow is shown below :





Steps to each run viz. synthesis, PNR, STA :

• Convert the pin details in milkyway format

• Invoke icc_shell
• Set ICC variables
• Set lib, design, reference, tech file, TLU Plus file, map file ( All common setting), netlist, scan def, sdc file
• Open .lib and design.
• Read input netlist, scan def, sdc file
• Do the floorplan
• Read the pin details.
• Create blockages and power straps
• Enter spare cell details
• Define false paths
• Do coarse placement and check for congestion
• Do routing and check for timing
• Close all drc/ lvs errors and ensure timing is met
• Do DFM improvements ( filler cell insertion, double via, spread wire )
• Ensure timing drc /lvs are clean

Tuesday, April 10, 2012

Industrial Physical Design Flow


VLSI Physical Design Flow is an algorithm with several objectives. Some of them include minimum area, wirelength and power optimization. It also involves preparing timing constraints and making sure, that netlist generated after physical design flow meets those constraints.
Following section will help you to understand the very basic and beginning steps for chip design. It is exactly the way it happens in leading VLSI chip design industries. 




Saturday, April 30, 2011

NEED OF MEMORY TESTING

Although most of these embedded memories are single-port static (and in relatively few cases, dynamic) RAMs today, the high demand for bandwidth in digital television, fast signal processing, and high-speed networking applications will also fuel the need for on-chip multiport memories in the foreseeable future. The reliability of a complex VLSI chip will depend largely on the reliability of these embedded memory blocks. With device dimensions moving rapidly toward the ultimate physical limits of device scaling, which is in the regime of feature sizes of 50 nm or so, a host of complex failure modes is expected to occur in memory circuits.

The task of testing a VLSI chip to guarantee its functionality is extremely complex and often very time consuming. In addition to the problem of testing the chips themselves, the incorporation of the chips into systems has caused test generation’s cost to grow exponentially.

a) Memory testing is an extremely important issue owing to a host of reasons. RAMs are the key components for electronic systems. Memories represent about 30% of the semiconductor market. Embedded memories are dominating the chip yield these days. 
b) Memory testing is becoming highly difficult due to growing density, capacity, and speed. 
c) New architectures and technologies are emerging at a fast pace. Embedded memories   require certain factors to be looked after such as diagnostics & repair, heterogeneity, custom design, power & noise, scheduling, compression, etc. 
d) Cost of memory testing drives the need for more efficient test methodologies. Few of the techniques already in use are IFA, fault modeling and simulation, test algorithm development and evaluation, diagnostics, DFT, BIST, BIRA, BISR, etc.
 
Test automation is required. It calls for failure analysis, fault simulation, ATG, and diagnostics and BIST/BIRA/BISR generation.

Friday, April 29, 2011

Memory - RAM

The Memory of a computing system holds its state information and dominates the chip area. A memory unit (RAM) may contain millions for memory addressable cells. Memory cells are organized into arrays wherein each cell is addressable by a row address and a column address. Memories are the most defect sensitive components as they are fabricated with minimal feature widths. It highly raises the total chip DPM (Defects Per Million) level and thus, calls for high quality tests and repair.

6-transistors SRAM cell

 


RAM Organization

Why This Blog ?

Hi all, this is Amit Raj, from India.

This blog is all about Design and Testing of Digital ICs. I don't want to treat this as only a blog, but a forum, where we can discuss anything but about VLSI.

It can be Verilog - RTL Coding, or Basics of IC Design, or Timing, Placement and Routing, LEC, STA, DFT.

Please feel free to leave any comments or send any new comments to the author for putting here..