In the eye of DFM/DFY storm
Abstract:
In the case of digital integrated circuits (ICs including ASICs, ASSP, and systems-on-chip), many people seem to have the impression that the transition to the 65 nm technology node is proving to be "not as bad as expected." In reality, however, we are in the eye of the storm. So far, only a small number of chips have taped out with apparent success. However, there's a gap between tape-out and production. Reports are now coming back that yields are lower than even the pessimistic expected.
A very important point that is often overlooked is that the "D" in both "DFM" and "DFY" stands for "Design." On this basis, post-processing the GDSII files to correct problems introduced by the upstream design tools cannot truly be considered to be DFM/DFY.
The solution is to bring DFM/DFY upstream into the design process to create a design that is correct by construction and to hand-off a design that is as manufacturing-friendly and yield-friendly as possible. The obvious candidate to subsume DFM/DFY analysis and implementation is the routing engine, the "front door" into the manufacturing process. For ASICs, routing currently accounts for approximately 60% of design delays.
Conventional routing engines use only rules-based techniques. However, the number of design rules and recommended rules is increasing so dramatically with each new technology node " and the rules themselves are becoming so complex " that these engines are choking on the sheer number of rules. The answer is to bring model-based techniques into the routing domain and to use both rules-based and model-based techniques, as appropriate
Equipping designers with such a DFM/DFY-aware routing engine will ensure that, when we encounter calm weather, it is because DFM/ DFY issues have been addressed, not because we are in the eye of the storm.
-------------------------------------------------------------------------------------------- ^ Top
SoC Prototyping - An Insight
Abstract:
As the time to market decreases and every bug in a chip costing astronomically high, traditional simulation/verification process fails to instill unshakable confidence before a tape-out. Emulation/Validation has emerged as an important stage in the ASIC/SoC design/verification flow. Increasingly IC design houses are recognizing the importance of validating the functionality of the ASIC/SoC on hardware before tapeout. Not only can we validate our functional hardware paths but also the software could be tested on the emulated platform. This whole new approach has even led to the availability of many a off the shelf emulation platforms available. Off course various design houses also prefer to design their own emulation platforms that suit their product offerings and test methodology. For all these the challenge lies in implementing the whole SoC on the emulation platform (cluster of FPGAs). A typical ARM based SoC would not fit into a single FPGA (even considering the 45/40nm offerings from ALTERA/XILINX).
A typical SoC for a wireless chip may take around 10-15 Xilinx Virtex5 FPGAs to be emulated (not including the MODEM).
-------------------------------------------------------------------------------------------- ^ Top
Porting System Verilog Test Bench towards VMM compliance
Abstract:
VMM is now a widely accepted methodology in the verification industry. This brings every verification component on the same platform and gives a similar look and feel for the users. This paper discusses the importance of porting the test bench implemented in the plain System Verilog to the test bench, which is VMM compliant. It also discusses the issues and merits, which came across during the porting activity of the sample design of AHB2AXI Bridge.
The VMM defines a comprehensive set of rules, recommendations and guidelines for a verification engineer to execute the functional verification task more effectively. We have made an attempt to make use of these advantages offered by VMM over traditional Verilog verification environment. This paper mainly focuses on making layered System Verilog test bench, VMM compliant.
This paper starts with giving brief idea about the various components of existing System Verilog environment. We have also explained how the components have been ported to VMM compliance. While making VMM compliant, we encountered new scenarios, which were missed in the non-VMM compliant environment. This paper also talks about the issues faced while porting.
For a detailed white paper, please write to vlsi@sasken.com.
-------------------------------------------------------------------------------------------- ^ Top
Common Mistakes In System Verilog Verification
Abstract:
System Verilog is the first truly standard language that covers design, assertions, transaction-level modeling and coverage-driven constrained random verification. It supports for high-level data types, object oriented programming, assertions, functional coverage. System Verilog nullifies the integration challenges required when separate languages are used for design and verification. This paper describes Common Mistakes related to the concepts of interfaces, mailbox, randomization, constructors and coverage. These problems are encountered while building the verification environment using System Verilog for AXI2AHB Bridge.
Some of the examples of mistakes explained are
Compilation errors when using interfaces with classes Mailbox has same pointer for all randomized objectsNeed for construction of cover group, Randomization of class objects in another class, Calling base class function from extended class etc.
For a detailed white paper, please write to vlsi@sasken.com.
-------------------------------------------------------------------------------------------- ^ Top
Using VMM memory allocation manager for dma verification
Abstract:
In DMA based designs the proper functionality revolves around the correctness in allocation of memory space for DMA Descriptors and DMA buffers. The correctness in allocation of memory space for DMA descriptors and DMA buffers is critical in ensuring the valid functionality of DMA based designs. To verify the DMA based designs, one might choose a static approach in allocation of memory space for DMA descriptors and DMA buffers. This approach lacks the randomness in the address values and might miss some of the critical bugs in the design. The VMM’s Memory Allocation Manager (MAM) provides a solution for this problem. MAM adds the randomization capabilities to the buffer, descriptor allocation in verification and thus uncovers many bugs in the design.
This paper walks the user through the structure and components of MAM. The specific use case scenarios of this application in the context of DMA verification are described. This paper also explains the customizations done to get some custom features. It concludes with the advantages of using VMM MAM and highlights the other areas where MAM can be used.
For a detailed white paper, please write to vlsi@sasken.com.
-------------------------------------------------------------------------------------------- ^ Top
PLI based verification setup for fast system level verification
Abstract:
System level verification goes in different stages. First stage generally is verification of register access by processor to all modules in the system. It checks whether all registers of each and every module are accessible by the processor in the specified way and POR (Power-on-Reset) values are read correctly. Test cases are coded in C or Assembly language and executed using the processor in the system itself. In this type of verification even though the scope of verification is out side the processor design, most of the simulation time is consumed in simulating the execution of test code by processor design.
This paper discusses a simple method used to reduce the execution time of these test cases by replacing the processor design with a PLI (Procedural Language Interface) based bus interface adaptor. This method works without making any changes to the test cases coded, but by replacing the write / read functions with message functions and replacing processor design with memory interface specific PLI Adaptor.
For a detailed white paper, please write to vlsi@sasken.com.
-------------------------------------------------------------------------------------------- ^ Top
Low Power Means to High-Speed Current Switching
Abstract:
This paper introduces a simple, yet power saving method of switching a high-speed (HS) Current Source (CS). Operating voltage of the CS is ltered by a resistor in non-transmission mode, turning parasitic capacitive coupling into an advantage for faster settling of CS gate bias voltage. This is in contrast with the known adverse effect of current variation due to capacitive coupling during switching. The presented method saves 100% of power consumed by the transmitter in non-transmit mode.
The method is implemented in HS USB 2.0 Transmitter, 90nm standard CMOS process and 3.3V supply. Gate bias of HS CS is settled with 2% accuracy within 2.5ns after switching the 17.8mA current driver. Simulation results are in conformance with high-speed USB 2.0 specifications
For a detailed white paper, please write to vlsi@sasken.com.
-------------------------------------------------------------------------------------------- ^ Top
![]() Low Power DFT Techniques Used in Today’s SOC
Abstract:
Low power methodology has gained much importance on the 90nm process node onwards. There are many techniques that have been adopted in order to reduce power consumption of the chip. The Low Power techniques are across the areas of chip-architecture, synthesis, back-end and off-late DFT. In the light of this, Five low Power DFT techniques are examined. The advantages and disadvantages of each are stated. The approximate power savings using each method are also estimated based on work by our partners and customers. Lastly, general methodology for the expected flow is explained.
For a detailed white paper, please write to vlsi@sasken.com.
-------------------------------------------------------------------------------------------- ^ Top
Basics of C based SoC Verification
Abstract:
As the name suggest “System on Chip” (SoC) is a complete system on single chip and to verify the functionally of this, engineer needs to apply software & hardware approaches side by side. Although most of the time building blocks of SoC are pre-verified as stand-alone modules but one has to make sure how they are behaving in real system in the presence of other blocks integrated along with it and software running on the system. This paper discusses the basic steps involved in SoC verification and few techniques to accelerate the verification and also to make it more effective.
For a detailed white paper, please write to vlsi@sasken.com.
-------------------------------------------------------------------------------------------- ^ Top
Equivalence Checking
Abstract:
Design verification has become a critical task in today’s chip design flow. The design and fabrication process of present day integrated circuits is highly time and cost-intensive. So it becomes important to detect the design errors early in the design cycle and produce error-free designs. With the chip complexity increasing, the verification effort and difficulty has been increased. Verifying the logic correctness of the designs has become more time consuming phase causing time-to-market problems.
Different formal verification techniques are used in the industry today. This paper will discuss the most important and widely used formal verification technique - Equivalence Checking. The focus of this paper is on Combinational Equivalence Checking but Sequential Equivalence Checking is also introduced.
For a detailed white paper, please write to vlsi@sasken.com.
-------------------------------------------------------------------------------------------- ^ Top
Relevance of Gate Level Simulations in today’s Soc Verification
Abstract:
It’s a debatable topic whether to do timing annotated Gate Level Simulations (GLS) or not. There are static methods like Static Timing Analysis (STA) available to verify timings in design. Equivalence Checking (EC) is available to verify that RTL and netlist are equivalent. Then why to carry out complex GLS which takes longer time, efforts and are costly as well? This paper answers this and elaborates the importance of doing timing annotated GLS. It compares GLS with STA and EC. It explains few instances from actual designs where functional and timing issues were caught by GLS avoiding costly silicon re-spin. These were related to flip-flop initializations and glitches.
It explains many reasons to do GLS like checks design boot-up, helps in accurate power consumption calculation, I/O speed characterization and functional test pattern generation. This paper also explains overheads and limitations of GLS. It finally concludes that with first pass silicon success as the ONLY goal considering today’s economic conditions, GLS are highly relevant and worth including in verification flow.
For a detailed white paper, please write to vlsi@sasken.com.
-------------------------------------------------------------------------------------------- ^ Top
Netlist-To-GDSII In Today’s Design
Abstract:
VLSI chip design operates in a very competitive market, requiring fast turnaround in their design cycles. Over the last two decades the complexity of a typical integrated circuit (IC) design has grown exponentially. System-on-chip (SoC) designs targeted to run at gigahertz frequencies incorporating millions of gates are common. Design cycles have shrunk from 18 months or more to 3 to 6 months. Cost and performance targets are quickly driving designs to 90-nanometer (nm) and smaller process geometries.
As process geometries shrink, designing for manufacturability (DFM), managing power leakage and overcoming physical effects, such as signal and power electro migration, power and IR drop, and crosstalk glitch, are increasingly more challenging. To deliver SoC designs that meet cost, performance and time-to-market objectives, SoC designers need a fast, smart, high-capacity and accurate design methodology that predictably achieves timing closure without unnecessary iterations.
This includes design feasibility analysis, exploration, design planning, concurrent block and top-level implementation. The key is to handle multi-million gate designs achieving desired timing QoR with an acceptable turn-around time. This paper will discuss the design methodology used to tapeout a large complex design in Sasken. The objective is to identify the optimal flow at each stage of the design and implementation and establishing a set of guidelines leading to faster design closure.
Keywords: Floorplan, power plan, clock tree synthesis, placement, routing, STA, DRC, LVS, GV, SV, X-talk, RTL
For a detailed white paper, please write to vlsi@sasken.com.
-------------------------------------------------------------------------------------------- ^ Top
Low Power Concepts Synthesis using RTL compiler
Abstract:
Until recently, designers were primarily concerned with improving the performance of their designs (throughput, latency, frequency), and reducing silicon area to lower manufacturing costs. But today a great deal of attention is being paid to low-power IC design. And it has become one of most critical issue in ASIC or system-on-chip (SoC) design. Power is emerging as the most critical issue in chip designs as the market demand for high-speed computation and complex functionality for portable devices in personal computing devices, consumer electronics and wireless communication systems space is increasing day by day.
The importance of using low power techniques is most felt when it comes to portable devices and plays a dominant role in making the decisions related to architecture design of such products. A great deal of progress has been made in this regard and various strategies have been adopted at the different levels of abstraction of chip development cycle. This paper gives an insight of some of these important techniques.
This paper explores the power concepts and examines the strategies to minimize power consumption at the synthesis level by exploring the power-conscious synthesis methodologies using Cadence RTL Compiler. The paper also brings out the comparison between the traditional synthesis and low power synthesis
For a detailed white paper, please write to vlsi@sasken.com.
-------------------------------------------------------------------------------------------- ^ Top
Faster approach for Sub-system Verification
Abstract:
The challenges in SoC/Subsystem verification comprises of verifying the functionality, integration of hardware (HDL) & software (test cases) and managing the regression suite. One of the challenges with it is the interface for stimulus (Software), which has to be run on the SoC/Subsystem using the master or host of the SoC. These masters or hosts are microcontrollers, processors like ARM or DSP. Verification environment is a combination of software (test cases, written in C or ASM) and test bench mostly written in HDL (Verilog, VHDL or System Verilog (SV)), the hex code of the stimulus drives the processor RTL or DSM. The RTL or model of the processor consumes lot of time to translate the opcode into the interface signal and drives the SoC/Subsystem peripheral because of the simulator’s event scheduling.
This paper discusses one of the strategies implemented in the Subsystem verification to reduce the regression/simulation run time. The Subsystem is the part of the SoC and has a host interface. The Sub-system host is connected to the subsystem with inter-connect and shares the system memory.
The test bench has BFM as a host to sub-system, memory models and components like verification models for peripherals.
The Figure 1, gives the generic picture of Subsystem DUT, Test Bench & Test flow. It is important to note that the time consumed in compiling the C/ASM Test case depends upon the size & number of test case. It is assumed that the hex code or binary to be loaded in the system memory is readily available before simulation starts. The test case generally is a combination of boot code and the functional code (actual test case). The software and the HDL test bench communicate with each other either by mailbox approach or GPIO.
We have used the shared memory (mail box type of arrangement) for the communication between the software and the test bench under re-determined handshaking protocol.
It is difficult to establish direct communication between the test cases (written in C/ASM) and the test bench (written in HDL) because of the nature of the language and their execution. Although there are methods like PLI/FLI to do this, besides being complex to create PLI/FLI, they are retarding factors as far as simulations are concerned. That is why we try to avoid the usage of PLI/FLI as far as possible to keep the test bench simple and fast.
The simple and popular way of establishing communication between software and hardware of the test bench is to use mailbox approach. In this method we reserve some part of the system memory to be utilized as test environment resource. So the DUT will avoid these memory locations for functional data storage.
One of the overheads in the SoC or Subsystem’s verification is the simulation time, especially during regressions. There are various reasons of long simulation times for the regression runs. This paper discusses one of the approaches, which is implemented as strategy to reduce regression and simulation run time for Subsystem verification, which has two processors and many peripherals with the host interface to it.
For a detailed white paper, please write to vlsi@sasken.com.
-------------------------------------------------------------------------------------------- ^ Top
Using Emulation Technology for SOC Verification
Abstract:
The technology’s ever evolving need to shrink an entire computing system comprising of processors, on-chip memories, memory interfaces, communication bridges, and peripherals in a single packaged chip has resulted in the evolution of extremely complex SoCs. Though the architecture of these SoCs is complex, it is mostly centered on efficient re-use of the intellectual property (IP) cores that are pre-silicon proven. This has greatly reduced the time-to-market.
Bugs mostly, result from incomplete IP integration, corner cases between S/W and H/W integration. The time and cost of fixing these bugs increase exponentially with respect to the stage where the design process is in. Bugs which are discovered when the design cycle is close to tapeout phase, results in huge schedule impacts. Bugs discovered after the tapeout may not only result in schedule impact but also in silicon re-spins. Reliable verification methods are therefore needed in early design stages.
The various verification options available for functional verification are:
- Software based Simulation -Using Modelsim or any other RTL simulator
- Simulation Acceleration - Hardware assisted Co-simulation
- In-circuit Emulation - Hardware based
- FPGA Prototyping - Hardware / FPGA based
Each of these steps requires different H/W / S/W environment, different kind of EDA tools, different engineering skillets. Also each step operate with different speed has different visibility in terms debug capabilities.
The verification and validation of these SoCs (System on Chip) is still a time consuming task and takes up to about 50 –80% of total design cycle time. This paper describes a potential approach to utilize the various emulation technologies to reduce the SoC verification cycle time.
For a detailed white paper, please write to vlsi@sasken.com. |
