Archive for the ‘Uncategorized’ Category
Thursday, August 22nd, 2013
As SoCs become more complex, and the cost of errors grows, it becomes increasingly important that engineers ensure their work is as correct as possible as soon as possible in the design process. They cannot afford to carry errors forward from one stage to the next, where their impact is likely to grow while their causes become obscured.
This requirement is driving a shift in design exploration and hand-off to the register transfer level. Using RTL sign-off eases the integration of heterogeneous IP and makes it easier to check the way that blocks are interfacing with the host design, how clocks will cross these interfaces, power requirements, and testability. It also cuts the simulation load, especially when designs are begin exercised in a system context, which vastly increases the number of states necessary to check functionality.
Initial timing constraints and clocking schemes have to be defined to enable earlier analysis and verification. Power estimation and optimization methods are necessary to provide previews of gate-level performance. The impact of inserting test structures to ease testability has to be considered. There is some good news – working with the design at this level means that each issue can be constrained and addressed by a focused tool, rather than being taken forward to the gate level where they would interact more strongly and hence be more difficult to solve. (more…)
Thursday, August 15th, 2013
Andrew B. Kahng, Professor of CSE and ECE, Univ. of California at San Diego presented a paper on “The ITRS Design Technology and System Drivers Roadmap: Process and Status” at the 50th Design Automation Conference in Austin, TX. This important review of the technology challenges that are in front of the EDA industry and what is the current status is presented here below in this fourth part of a blog series.
4. LAYOUT DENSITY A-FACTORS
In the ITRS System Drivers Chapter and Overall Roadmap Technology Characteristics, A-factors enable the modeling of unit cell areas of SRAM and standard-cell logic circuit fabrics, in terms of the M1 half-pitch, F . SRAM layout density is mainly determined by Mx pitches and poly pitch in a bulk technology. With FinFET devices, the fin pitch ( Pfin ) becomes the dominant factor for SRAM layout. On the other hand, the density of standard cells is mainly decided by the cell height (in M2 tracks) and the poly pitch. Since the 2009 ITRS, the A-factor for a 6T SRAM bitcell has been 60 sq. F, and the A-factor for a 2-input NAND gate has been 175 sq. F . These values are based on various ratios between, e.g., poly, M1, and M2 layer pitches (design rules) as summarized in the left half of Table 1, as well as on the canonical layouts shown in Figures 4(b) and 5(b) .
Thursday, August 8th, 2013
Andrew B. Kahng, Professor of CSE and ECE, Univ. of California at San Diego presented a paper on “The ITRS Design Technology and System Drivers Roadmap: Process and Status” at the 50th Design Automation Conference in Austin, TX. This important review of the technology challenges that are in front of the EDA industry and what is the current status is presented here below in this third part of a blog series.
3. KEY SYSTEM DRIVER MODELS
As noted above, the System Drivers Chapter models and projects key semiconductor product classes that create the need for continued semiconductor innovation [5–7]. The 2011 System Drivers Chapter identifies three microprocessor (MPU) drivers (high-performance (HP), cost-performance (CP) and power-connectivity-cost (PCC)) and three System-On-Chip (SOC) drivers (consumer portable (CP), consumer stationary (CS) and networking (NW)). See footnote 1. Each driver should provide impetus for specific technology objectives, e.g., the SOC-CP driver drives lower leakage (or standby) power consumption, given the severe battery life requirement of mobile devices. For each MPU and SOC system driver, the ITRS roadmaps scaling of parameters such as number of cores, number of SRAM and logic transistors, layout density, frequency and power.
Thursday, August 1st, 2013
Advanced semiconductor processes have made it possible to integrate hundreds of millions of gates of digital logic on a die. What has made this practical, however, has been the shift to block-based design, in which many large functional blocks from a variety of sources are quickly integrated into a new SoC. Without the ability to reuse design blocks, it would be impractical, and perhaps even impossible, to take full advantage of the capabilities of an advanced process in any reasonable timescale – designing all that functionality from scratch is simply too complex.
What abstraction to the block level gives with one hand it tends to takes away with the other. Even if each block can be relied upon to behave properly within its boundaries, a complex SoC design attempts to integrate and then coordinate many such blocks, despite the fact that each may have been designed by a different group using a different strategy. Each block, for example, may expect a different clock rate, may dynamically adjust its clock to match its workload, and may employ sophisticated clock-gating strategies to minimize power consumption.
How bad is the problem becoming? According to a survey last year, 32% of SoC designs underway among those surveyed employed 50 or more clock domains. SoC designers, therefore, are faced with trying to ensure that their systemic and inter-block clocking strategies work as expected, even as thousands of signals pass between tens or even hundreds of different clock domains. Add in power-management strategies that turn blocks on and off to minimize energy use, and therefore leave signals at block boundaries in undetermined states, and complex external interfaces which introduce their own clocking requirements, and the potential for errors multiplies. (more…)
Thursday, July 25th, 2013
Andrew B. Kahng, Professor of CSE and ECE, Univ. of California at San Diego presented a paper on “The ITRS Design Technology and System Drivers Roadmap: Process and Status” at the 50th Design Automation Conference in Austin, TX. This important review of the technology challenges that are in front of the EDA industry and what is the current status is presented here below in this second part of a blog series.
2. DESIGN TECHNOLOGY WORKING GROUP GOALS AND PROCESS
Like every other technology working group in the ITRS, the Design TWG places the interests of its industry and R&D community – i.e., EDA and VLSI CAD – first and foremost. In ITRS cross-TWG interactions, the Design TWG must respond to questions such as “How much variability can designers tolerate?” (Lithography TWG) or “What is the Jmax limit for on-chip global interconnects?” (Interconnect TWG) or “What tradeoff between leakage and drive currents is best for mobile SOCs?” (Process Integration, Devices and Structures (PIDS) TWG). The roadmap for DFT is jointly owned with the Test TWG. The roadmap for off-chip IO bandwidth is jointly owned with the Test TWG and the Assembly and Packaging (A&P) TWG. And the roadmap for 3D/TSV based integration is jointly owned with a number of other TWGs, notably A&P, Test, Interconnect and Front-End Processing (FEP). All of these interactions entail asynchronous, off-line dialogues year-round with designers, EDA technologists and researchers so that perspectives from IC design, and from IC design automation, are correctly represented.
Thursday, July 18th, 2013
Andrew B. Kahng, Professor of CSE and ECE, Univ. of California at San Diego presented a paper on “The ITRS Design Technology and System Drivers Roadmap: Process and Status” at the 50th Design Automation Conference in Austin, TX. This important review of the technology challenges that are in front of the EDA industry and what is the current status is presented here below in this first part of a blog series.
The Design technology working group (TWG) is one of 16 working groups in the International Technology Roadmap for Semiconductors (ITRS) effort. It is responsible for the ITRS’ Design Chapter, which roadmaps design technology requirements and potential solutions for elements of the semiconductor supply chain that are produced by the electronic design automation (EDA) industry. The Design TWG is also responsible for the ITRS’ System Drivers Chapter, which roadmaps the key product classes that drive the leading-edge requirements for process and design technologies. Through these activities, the Design TWG sets a number of fundamental parameters in the overall ITRS: layout density, die size, maximum on-chip clock frequency, total chip power, SOC and MPU architecture models, etc. This paper reviews the process by which the Design TWG evolves its roadmap content, and some of the key modeling and roadmapping questions that the semiconductor and EDA industries will face in the near term.
Thursday, July 11th, 2013
Real Intent CEO Prakash Narain spoke in June with Ed Sperling, Editor-in-Chief of System-Level Design, about where are the pain points in verification; the different types of sign-off; the impact of third-party IP; and can the tools industry keep up with the rising complexity in semiconductor design. Enjoy!
Thursday, July 4th, 2013
In Austin, at the 50th DAC in June, I delivered a poster presentation on “Lending a ‘Formal’ Hand to CDC Verification: A Case Study of Non-Intuitive Failure Signatures”. In this final blog in a series, I discuss the causes for a failure when the counter value of the control logic equals 16 and then look at pulse width results when using both aligned or offset reset signals.
Following a FAIL with counter = 14 and a PASS with counter = 15, here we take a look at a FAIL with counter = 16.
The Control signal is held high by the counter during the second half of the total count of 16 (from 0x8 to 0xf).
Note that when Mux-on is high, the mux is open and the Data signal gets captured in the Rx Data flop.
Take a look at the signals in the vicinity of the two vertical dotted lines on the right. The first dotted line aligns with a change in the Data signal which happens when the counter wraps. Since the mux is open (Mux-on is high) the Data is captured by the Rx Data flop on the first receive clock edge following the change in Data. This is marked by the second dotted line and is a Data Stability failure.
Note that, in order to produce a failing trace in this case, the counter needs to wrap around twice. In order to understand why there is no Data Stability failure in the first full count of the counter, take a look at the Grey oval in the waveforms. When the mux is open (when Mux=on is high), note that the Data remains stable and is not changing. Hence there is no Data Stability issue here.
Thursday, June 27th, 2013
It is interesting when I talk to purchasing managers at semiconductor companies and they use the dollar cost for a tool as the measure of its value.
Tool value can be hard to quantify and a price tag will not tell the whole story. The real cost behind any tool is the engineering effort to use the tool and the real time-saving and efficiency it brings to design teams.
The Meridian CDC solution from Real Intent, for example, is often compared to tools from other vendors. When technical decision makers are involved, the value is very obvious since they can quantify the difference in effort.
It takes much less time to debug the results. Why? Because Meridian CDC analyzes the complete interface of the crossing and it reports how data and control crossings are associated. This generates dramatically fewer violations for review, despite the fact that all analysis rules are always turned on. Needless to say, having all rules on all the time helps in NOT missing design bugs.
Thursday, June 20th, 2013
In Austin, at the 50th DAC earlier this month, I delivered a poster presentation on “Lending a ‘Formal’ Hand to CDC Verification: A Case Study of Non-Intuitive Failure Signatures”. In this second blog in a series, I discuss a set of failures in a common clock domain crossing synchronizer.
The design used for this case study closely mirrors the CDC synchronization scheme shown earlier in Part 1. Two components of the scheme are represented generically in the schematic below. They are
- The logic controlling the loading of the registers in the transmit domain and
- The detection logic on the control signals in the receive domain
A designer can use one of many techniques for implementing the generic components which can be considered as variables for design exploration.
The clock frequencies of the transmit and receive domains, specifically the ratio they imply and the relative reset release of the two clock domains can be considered as the System variables in this experiment.