Today’s verification challenge is immense. One SoC may be defined by more than 30 million lines of design RTL and testbench code. It may embed 10 or more sophisticated communications protocols (think USB, and mobile connectivity on a handset, for example), and have as many as 200 power domains to optimize energy consumption. Verifying such a chip may involve using thousands of servers, many with 150Gbytes or more of memory, writing and testing hundreds of thousands of assertions, and producing and interpreting terabytes of coverage data.

It’s little wonder, then, that the cost of verifying a leading-edge chip has risen 30% a year since 2001, so that it is now three times what it was back then, and that verification engineers outnumber design engineers by two to one.

To tackle the verification challenge, design and verification managers must find ways to achieve a series of order-of-magnitude productivity improvements in their verification strategies. This may mean greater reuse of testbenches, updated methodologies, and the authoring and application of verification IP. They will also have to leverage next-generation technologies that enable significantly more throughput from their server farms, and introduce debug automation and debug strategies that can detect and prevent more bugs, more quickly.

Time to market is key

The relentless competition in consumer and other markets is creating tremendous pressure to tape out designs. This pressure is intensified by the increasing complexity of the core SoCs, which integrate ever more digital functions, are adding analog functions, implement sophisticated power-management strategies, and embed a rapidly growing amount of software. For design and verification teams, this means that the challenge is evolving from taping out a functional hardware design to delivering that hardware with correctly functioning software onboard as well. This added complexity now increasingly drives decisions about verification strategies.

Performance matters

Due to the complexity of today’s SoCs, leading-edge chip design teams must apply a variety of verification techniques to gain the confidence to tape out a design.

Exhaustive simulation demands large server farms, and some companies are spending millions, if not billions, of dollars to build and run the IT infrastructure necessary to do high-performance verification. The total cost of ownership for these server farms includes the cost of acquiring the hardware and regularly updating it, powering and cooling it, and administering the whole set-up. No company wants to incur these costs, but they know that every improvement they make in verification performance will have a material effect on their bottom line. They also know that the cost of missing a market opportunity because of a faulty chip is so punitive that teams must run as many simulation cycles, and get as close to full chip coverage, as they can.

To achieve improved verification performance, companies are turning to techniques such as constrained random verification. This involves writing complex testbenches that generate random, but meaningful, vectors for the design. These testbenches themselves must be verified before use, a process that can be accelerated using fast constraint solvers. The better the testbench, the more effective the test, and hence the greater the return on the IT infrastructure that runs it. So performance, whether it is measured in pure CPU cycles or the effectiveness of a particular testbench, is critical to meeting the ‘time to tape-out’ and ‘time to software’ challenges.

Debug challenges multiply

Surveys and studies suggest that 70 percent of the effort involved in taping out a complex SoC is spent on verification. Half of that, or 35 per cent of the total, is spent on debugging the chip, the interaction between the chip and its software, and the testbenches.

The scope of debug is also growing, as issues such as power management, hardware/software co-design, and the introduction of analog or mixed-signal blocks, create new challenges.

For example, turning a chip’s functional blocks on and off to reduce power consumption introduces thousands of unknown (X) states during simulation, which then have to be sorted into real bugs and simulation artifacts and correlated with the designer’s power intent. X-propagation has always been difficult to debug, but with low-power designs, both the verification and debug processes require the X states to be modeled more accurately and to be propagated more correctly during simulation.

In hardware/software debug, designers need to be able to see the relationship between their C or assembler code and the RTL with which it was interacting when a fault occurred. Debugging the interaction of analog or mixed-signal blocks and digital blocks introduces another set of challenges.

These are just some examples of the way in which the scope of the debug task is broadening. What makes the issue even more challenging is that these debug domains interact – a faulty analog circuit may create a digital logic bug that causes the chip’s software to misbehave.

Multiple strategies

In the face of these challenges, design and verification managers must develop a set of strategies that, working together, provide them with a level of design coverage and debug insight that gives them the confidence to tape out the chip.

This means making trade-offs between various forms of verification, in terms of their coverage, speed and costs, and various forms of debug, in terms of their efficacy. It also means taking into account the costs of moving from one approach to the next and the possibility of introducing inconsistencies as they progress from approach to approach.

There is no standard verification strategy. For example, in one market sector I have seen two companies making competing chips that use verification strategies that are almost polar opposites.  One company builds FPGA-based prototype boards in order to run as many cycles as possible. The other relies on simulation and coverage management and rejects hardware prototyping.  The right approach is to use both. Essentially, one should use all possible strategies at one’s disposal. There is no one-size-fits-all approach.

The challenge for design and verification managers, and the tools vendors that support them, is to raise confidence in each methodology, and to make it possible to move between approaches very easily. For example, standard server-based simulation offers flexibility, so long as compile times remain within practical limits. Emulation offers greater speed, once the design has been set up on the emulator. An FPGA prototype might be even faster, but it will lack the access to internal signals of a simulator or emulator.

The difficulty for managers is to understand the tradeoffs involved in each of these approaches and how to move between them for the best overall result. For example, different design teams will hand off from simulation to emulation at different points in their process, depending on how confident they are with the revisions they are likely to need to make. In a simulation, the typical change-and-compile cycle is 3 to 4 minutes. In emulation, making the same change takes a bit longer so verification teams need to reach a version of their design that is a bit more stable before moving to emulation.

Design managers also need to marshal the skills that support each strategy, from server-farm management for the simulation phase to design-partitioning and logical-to-physical mapping in the FPGA prototyping phase. The skill here is to know when to make the transition between each verification approach for best overall effect, and then to have the people and resources on hand to make that transition as smooth as possible.

Debug roadmap

The broadening frontier of the debug task makes the verification issue more complex. Along with knowing when to move between different verification strategies, and how much verification is enough, design managers also need to develop a consistent debug strategy for the various forms of verification. Currently, there is no systematic unified debugger that works across all these different ways of exercising a design.

As a step towards a more systemic approach to debug, Synopsys has acquired SpringSoft so that we can offer the de facto standard Verdi as an open platform upon which users, third parties and ourselves, can innovate effectively by offering plug-ins and extensions to tackle emerging debug issues.

Verdi has powerful underlying abilities, such as an understanding of how a design is synthesised from RTL into gates that is expressed in a single database, which others will be able to build upon. We’re already adding ways to show verification coverage in Verdi’s graphical user interface, so that users can relate coverage and debug. We will soon be adding new capabilities, such as hardware/software debug and support for analog and mixed signal debug, over time.

Verification management

Design and verification managers will need technologies with which they can see how the many forms of verification and debug interrelate, so that they can develop better insights into the tradeoffs they are making as a design progresses to completion. Such technologies should be flexible enough to handle many forms of verification. They should also be able to present many types of metrics, and do a good job of turning those metrics into actionable information upon which design managers can make timely decisions that lead to the most efficient and effective overall verification strategy for their designs. And they should enable design and verification managers to explore a variety of verification strategies against key parameters, such as coverage and cost.

There’s one truth that the managers of large SoC projects must live by: time to market is king. Effective verification strategies, be they better ways to write testbenches, greater reuse, or a well thought-out approach to debug, are vital to getting big designs out of the door on time and with a reasonable level of confidence.

Michael Sanie is senior director, verification marketing, Synopsys

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.

What tools are available to improve the quality of RTL code before it reaches the simulation stage? Linting tools have evolved to the point where they can handle full-chip designs of 500 million gates or more, and yet still offer concise reporting. Timing constraints management and checking ensures correct timing for the block and full-chip level, so long as any changes in the RTL are reflected in the SDC files for the design. (The SDC itself needs to be verified for correctness and consistency, and is essential for sign-off grade analyses such as clock design crossing.)

Reset analysis ensures that the design will come in a known good state, and in later iterations of the design may be used to save chip area and routing resources through a more intelligent application of reset signals.

Automatic formal verification techniques can be used to find obscure functional bugs in the RTL, especially in finite state machines, and root out issues, such as bus contention or dead code, which violate the implicit intent of the RTL.

Clock domain crossing analysis, so important in these days of design reuse, IP, and complex power management schemes, can be carried out using a combination of formal and structural methods, which helps trap the corner case combinations of timing and functionality that lead to errors.

Power analysis and optimization techniques address issues such as reset checking, retention flop and isolation-cell analysis and optimization, clock/power gating, and sequential/combinational optimizations. These interventions can be so extensive that it makes sense to go back to the linting stage to recheck the design, and to clear the way for DFT analysis and optimization.

Working at the RTL sign-off level means that even those without DFT expertise can develop DFT strategies and analyze them for the testability that they bring to the design.

As a last step, it is important to manage the way that the simulation and synthesis processes handle the unknown (X) states thrown up by power management strategies that turn blocks on and off, and clocks crossing domains. A proper analysis of this issue can reveal functional bugs that have been hidden at the RTL level by too much optimism about the impact of X states, and reduce the impact of excessive pessimism about the impact of X states after synthesis.

Combining these static verification steps can clean up the RTL and so reduce the simulation burden of testing its function, and the synthesis burden of trying to implement conflicted code. And it means that the design will be as correct as possible as soon as possible, helping meet time to market goals.

3D-IC packages may accommodate multiple heterogeneous die, such as logic, memory, analog, RF, and micro-electrical mechanical systems (MEMS). Each of these die can use different process nodes, such as 28nm for high-speed logic and 130nm for analog. This provides an alternative to system-on-chip (SoC) integration, potentially postponing an expensive move to a new process node for all of the functionality developers want to place in a single package.

While there is great interest in this emerging technology, development is still at an early stage. There are clear requirements that an effective 3D-IC flow must satisfy to bring the cost, integration and performance benefits that the technology promises.

Use of the TSV, for example, introduces design, integration and test challenges. TSVs are copper vias with diameters that may range from 1 to 30um, and they make it possible to integrate multiple stacked dies in a single package.

With 3D-IC, a die containing TSVs can be attached to the package substrate using conventional flip-chip technology. A second die is attached to the first using the TSVs to route connections — not just to the adjacent IC but to the underlying PCB through the package’s redistribution layer.

Compared to a wire-bonded system-in-package (SiP), 3D-ICs constructed using TSVs offer reduced RLC parasitics, better performance, more power savings, and a denser implementation. Compared to a 2.5D silicon interposer approach, a vertical 3D die stack offers a higher level of integration, smaller form factor, and faster design cycle. But a 3D stack raises some additional challenges, including thermal, timing, and power management concerns.

Although 3D-ICs with TSVs do not require a revolutionary new 3D design system, they do require some new capabilities that need to be added to existing toolsets for digital design, analog/custom design, and IC/package co-design. The end goal is to optimize system cost with the shortest possible turnaround time. If 3D-ICs cannot be both cost and time effective, they will not enjoy widespread adoption. To that end, we have identified and are working toward supporting eight requirements for design tool flows that support 3D-IC:

1. System-level exploration

The cost and benefits of 3D-IC can be subtle as there are many tradeoffs that engineering teams can use during design to bring some functions onto a monolithic die that will make economic sense under certain circumstances. In other cases, the desire for flexibility or to reduce design risk can favor the migration of functions to other die within a single package.

Sometimes called ‘pathfinding’, 3D-IC system-level exploration will help users partition designs into separate chips, select the appropriate silicon technology for each chip, determine where functionality goes, choose the best die order in the stack, and optimize connectivity between chips.

Existing system-level exploration tools can provide early power, area, and cost estimates, and allow what-if explorations across architectures, silicon IP choices, and foundry processes. These tools are being to serve stacked die implementations and package considerations and to carry this intent through the design process.

2. 3D floorplanning

Once the technology selection and partitioning choices have been, floorplanning is vital. Although the pin-to-pin distances within a package are much shorter than those of PCB traces, the decisions over type of integration and how functions are distributed will have direct impacts on performance.

For example, TSVs are very large compared to logic gates and other circuit features. Thus, the number and location of TSVs is crucial. With too many TSVs, the wire length goes up. TSVs cause coupling, which can be reduced by adding space to their keep-out zones – but this adds to the area. TSVs also cause mechanical stress, which can impact the performance of nearby devices.

Given these considerations, a TSV-aware 3D floorplanning capability is quite challenging. It must provide an abstraction level to capture all the die, and provide a unified representation of intent for placement and routing tools.

A 3D floorplanner should work in the X, Y, and Z directions, and should have visibility into the top and bottom of each die. This helps optimize the placement of blocks, TSVs, and micro-bumps, and shortens interconnect distances, thus improving performance and power. For continuous design convergence, micro-bump and TSV assignments should take into account the floorplans on adjacent die.

Ideally, a 3D floorplan will be aware of thermal issues and will help avoid hotspots. It will also help users determine the optimal placement of die into stacks. The order of the stack is important. Die in the middle are most susceptible to thermal problems.

3. Implementation

The techniques used by tools for synthesis, placement, and routing change in the 3D-IC environment. For example, there are new layout rules that may be driven by features on adjacent die. The back-side redistribution layer (RDL) is a new layout layer. And given their size, TSVs themselves are a significant new layout feature.

A digital implementation system that supports 3D-ICs must be “double-sided aware,” taking into account both the top and bottom of each die. This may call for a new modeling and database infrastructure, TSV-specific tools, and support for a variety of stacking styles.

Power planning for a single-die IC is hard enough. With a 3D stack, it gets more complex. Designers need to provide enough power to drive all of the die, including the top-most die. Designers must manage vertical voltage drop and reliably simulate system power consumption. Tools need to support power distribution for TSVs and micro-bumps. A unified representation of power intent should be carried across the entire 3D-IC design.

Place and route tools should include thermal constraints to avoid hot spots. Routing tools need to handle TSVs and micro-bumps properly, route signals across multiple die, and verify the bump alignment between adjacent die.

Managing clocks across multiple die while avoiding skew is another challenge. If there are different clocks for different die, the designer must figure out how to synchronize them.

Analog implementation environments also need to add support for 3D-ICs. Examples of useful capabilities include multi-chip visualization with background views; support for bump, TSV, and reverse-side routing; and connectivity extraction maintained through TSV connections.

Throughout the design convergence process, design intent must be maintained and checked, and the necessary abstraction techniques must be applied for proper implementation and analysis.

4. Extraction and analysis

Extraction and analysis tools are crucial for design convergence in any IC-design environment. However, existing extraction and analysis tools need to be extended for 3D-ICs. For example, the tools must consider RLC parasitics for TSVs, micro-bumps, and interposer routing. Further, analysis tools must be 3D-aware. Timing, signal integrity, power, and thermal gradients must be analyzed across multiple die. Multi-die static timing must be validated, with an understanding of interactions between multiple die and with the package.

Because the metal stack creates heat gradients, thermal analysis and signoff is critical, especially for die located in the middle of the stack. Further, the substrate thinning required for 3D stacks results in relatively poor heat dissipation. After placement and routing, thermal signoff is needed to ensure hot spots are below specified limits, and that thermal effects do not have a negative impact on performance or leakage.

Signoff raises new questions with 3D-IC stacks. For example, can design rule checking (DRC) and layout-versus-schematics (LVS) run on the entire stack? Can timing be verified for the entire stack? Is there any crosstalk between die?

Electromagnetic interference (EMI) is a possible concern for 3D-ICs, raising a potential need for analysis tools. A multi-die package offers less shielding than a single-die package, and thus offers more likelihood that emissions could escape.

Finally, to facilitate TSV connections, the wafer is thinned to implement a 3D-IC. This causes stress and adds susceptibility to thermal changes, which need to be accounted for in the design.

5. Design for test (DFT)

Test raises many challenges for 3D-ICs, including access to die inside a stack and proper handling of thinned wafers. Both new standards and tool support are required to help validate that design intent is maintained once 3D-IC silicon is realized, and to diagnose issues properly if the system doesn’t behave as intended.

Like conventional single-die IC test, 3D-IC test must be considered at two levels – wafer test (for the silicon die), and package test (after die assembly into the package). The difference is that in the 3D-IC fabrication, there are many more intermediate steps, such as die stacking and TSV bonding. This provides many more opportunities for wafer test before final assembly and packaging.

Wafer test is needed for cost optimization. If a die is bad, it can be thrown away before it is placed in a package. If a package-level test fails, the entire package would have to be thrown away. Thus, wafer test is highly desirable, especially early in the product lifecycle while defects may still be relatively high.

But wafer test for 3D-ICs is challenging for three reasons. First, today’s probe technology is unable to handle the finer pitch and dimensions of TSV tips, and is generally limited to handling several hundred probes, whereas the TSVs may have several thousand probes. Second, probe technology leaves scrub marks that can potentially cause problems with the downstream bonding step. Finally, wafer test requires the creation of a known-good die (KGD) stack. To stack known-good die, the wafer must be thinned by about 75 per cent so the tips of the TSVs can be exposed. However, as the thinned wafer is contacted by a wafer probe, there’s a danger of damaging the wafer.

3D-ICs also introduce new intra-die defects. These may be introduced by new manufacturing steps such as wafer thinning, or by bonding the top of a TSV to another wafer. Thermal effects are another potential sources of defects, because excessive heat may be generated from the densely packed stack of dies. Thermo-mechanical stress is caused by different thermal coefficients of the various materials in the stack. Despite the differences in the manufacturing steps, the resulting faults (shorts, opens, delay defects) appear to be similar to what we see in conventional ICs. It is possible that new fault models may be required as we get more empirical data.

Modeling defects through TSV-based interconnects is a new area. These defects may be introduced in the fabrication or the bonding of TSVs. Fortunately, defects introduced through TSVs can be mapped to existing fault models, such as opens, shorts, static, delay, and bridging faults. However, a methodology is needed to map TSV defects to known fault types.

A sound methodology for 3D-IC test includes a DFT architecture that provides efficient ways to control and observe individual die from the chip I/Os, while providing different test access modes (such as a mode for a known good die test or a known good stack test). Conventional DFT architectural approaches and techniques such as on-chip compression, boundary scan, memory built-in self-test (MBIST), reduced pin count testing, and on-chip clocking for at-speed test are broadly applicable, and need to be configured and optimized to meet 3D controllability and observability goals. The trick is one of making an intelligent allocation of DFT resources across the multiple die to minimize the area overhead, while meeting constraints for test cost and shipped product quality.

6. IC/package co-design

Developers of 3D-ICs need to remember that any electronic product includes three different fabrics – chips, packages, and boards. Designing the chip first and throwing it “over the wall” to package and board designers will not result in design convergence on an optimal, cost-effective solution.

If the chip, package and board are not designed co-operatively, the interconnect will not be optimized, and extra vias will be needed to handle signals that cross from one point to another. As a result, performance will be reduced, additional board layers may be needed, and board and package costs may rise. Further, without co-design, timing, power, and signal integrity will not be optimized.

IC/package co-design is important for 3D-ICs because there are a large number of I/Os, and because the cost of packaging goes higher with multiple die in one package. Without co-optimization, the package could end up costing more than the silicon die. Important capabilities include I/O feasibility planning, connectivity management, 3D visualization, SiP layout, and support for multi-fabric analog and RF circuitry. To ensure complete design convergence, the packaging tool must understand the IC and package design intent, and should effectively abstract the IC design database to provide constraint-driven layout of the package substrate.

The board must be considered as well. 3D die stacks result in additional interconnect that will have to find its way down to the board. As more connectivity is handled inside the package, there’s less complexity on the board. The board designer needs to know what’s going to be positioned near the 3D package. By positioning and rotating components properly, the designer can reduce the number of layers required for the board.

Some companies drive co-design from the board up. They know where components will go on the board, and those locations are fixed. They then design the package that contains the stacked die in order to optimize connectivity, and to allow the minimum number of layers on the PCB. But it’s not so important where co-design starts – what’s important is that it is done to assure convergence for the 3D-IC silicon-realization process.

7. A flexible ecosystem

To be successful, 3D-ICs need to be designed and produced in a cost-effective way, with sufficient turnaround time to meet market windows. This will be possible only with a robust and well-defined supply chain ecosystem, including semiconductor design companies, EDA vendors, IP suppliers, foundries, and outsourced semiconductor assembly and test (OSAT) providers.

Boundaries between the different players may start to blur. For example, when are TSVs created and who is responsible? Possible implementation steps include:

• Via first – wafer processing starts with TSVs and is done by the foundry.
• Via middle – TSVs are created after transistors, but before back end of line (BEOL), by the foundry.
• Via last – TSVs are created after BEOL, probably by the OSAT.

Since one size does not fit all with 3D-ICs, the supply chain needs to be adaptable to customer needs.

Many customers will want to line up a second-source 3D packaging service provider before production is started. Additionally, key strategic alliances between memory suppliers, logic IDMs, foundries, and packaging subcontractors will need to be forged.

Foundries are establishing design rules, create models and libraries, and provide process design kits (PDKs) and reference flows. One example of a design rule is to avoid placing TSVs too close to active devices, because they cause mechanical stress that may change the performance of the device. Tools must be aware of recommended TSV diameters and pitches. They need to understand distances between TSVs as well as the width of metal routing to TSVs.

OSATs will play a role in assembling early 3D stacks and interposer configurations, combining die from different foundries, and developing tests for 3D stacks – but in the long term they will have to compete with foundries who are pulling OSAT tasks in-house.

8. 3D-IC standards

Standards will become an important part of the 3D-IC ecosystem. An initial standards effort may focus on defining a taxonomy of terms. Down the road, I/O standardization between interfaces such as memory, logic, and interposer layers will be helpful.

Meanwhile, the 3D-IC Alliance is focusing on the manufacturing side, and has released the Intimate Memory Interconnect Standard (IMIS) to standardize vertical interconnect requirements. Another area calling out for standardization is 3D-IC test. Two emerging standards – IEEE 1149.7 compact JTAG and IEEE P1687 internal JTAG (iJTAG)—can be deployed together to embed test structures in 3D-ICs.

The IEEE 1500 standard for embedded core test makes the pins of an IP core controllable and observable.

The same principle could potentially be used to access individual die in a 3D stack. The IEEE 1500 “core test wrapper” concept places a DFT wrapper around a core. In a 3D-IC, this concept could place an entire die in a wrapper and make it accessible through a product-level I/O interface. The same test patterns could be reused at the package test level.

Conclusion

From a design standpoint, the good news is that extensive retooling is not needed for 3D-ICs. Although there are clear requirements for 3D-IC development, the fundamental underpinning for tools is in place. There is no need to acquire a new ‘3D’ design system. There are also no apparent showstoppers in process technology. However, new capabilities are needed in the areas discussed above, such as architectural analysis, floorplanning, place and route, thermal analysis, timing, signal integrity, IC/package co-design, and test.

Above all, a comprehensive solution is needed. Many 3D stacks will combine digital and analog/RF circuitry, requiring a strong analog/mixed-signal capability. Because of the unique packaging requirements of stacked die, an IC/package co-design capability is a must. Additionally, fitting 3D-ICs on a board is challenging, requiring a capable PCB layout system with appropriate analysis tools. Thus, anyone who presents a complete “solution” must provide expertise in digital, analog, IC, package, and PCB design.

About the author

Steve Carlson is marketing group director for silicon realization at Cadence Design Systems.

Contact

Cadence Design Systems
2655 Seely Avenue
San Jose, CA 95134

T: +1 (408) 943 1234
W: www.cadence.com

There are numerous challenges to ensuring a ‘clean design’. They include signal integrity, reliable timing, well behaved waveforms, acceptable crosstalk, adequate power distribution, and electromagnetic interference (EMI) levels that meet global regulatory requirements. These can no longer be overcome by using outdated design methods and procedures that lack adequate simulation coverage, and performance verification techniques that jeopardize first time design success or profitable performance yields.

Everything matters

For today’s high-speed designs, everything matters. That includes the electrical performance characteristics of the connectors, the properties of the PCB interconnect and dielectric, the test and measurement setup, and of course the design tools employed.

Many designs use leading-edge FPGAs to target 40G/100G Ethernet applications. Others use multi-GHz microprocessors for laptops and tablets. And often, they incorporate DDR2/DDR3 wide bus memories. All require very dense interconnect implementations with lightning fast signals. The ‘Everything Matters’ world of design demands an approach that quickly and accurately checks electrical performance robustness as schematic and layout design proceeds.

We can think of such a capability as synonymous with a yearly health checkup that includes X-rays/MRIs and various other tests. Those tests help lead to a diagnosis and hopefully a remedy or care plan to rectify any problem. The equivalent for PCB design is an EDA tool that runs appropriate tests on a layout to identify potential electrical rule violations so that more in-depth simulation and analysis can be proscribed to prevent catastrophic design flaws slipping through the final sign-off gate (Figure 1).

Design intellectual property

In their efforts to manage complexity, teams rely heavily on master designers with extensive experience and know-how. They help to develop sets of guidelines, blueprints for success that can be carefully followed throughout the design process.

Many companies consider this special design knowledge and know-how proprietary. Often, they consider it to be among their most sensitive intellectual property (IP). Converting this IP into usable guidelines poses several challenges and risks.

It end-users typically have a broad range of skills and understanding themselves that must be considered during guideline development. The guidelines must avoid any ambiguous and be complete. Nevertheless, the intent of the master designer is often misunderstood or the rule is applied incorrectly. This issue is further complicated once individual design/CAD teams need to interpret and derive actionable physical and electrical design rules to be followed during circuit design and layout.

Physical design rules tend to be straightforward. They often deal with common routing issues like trace spacing, width, via clearances, and so on. Constructing electrical rules can be more challenging.

Each electrical rule has an impact on the final geometrical layout but is based upon a much deeper understanding of the electrical behavior of certain physical representations. Electrical rules are intended to help the layout team avoid inadvertently creating EMI, electromagnetic compatibility (EMC) and electromagnetic coupling. They are also meant to ensure signal integrity (SI) and power integrity (PI). As one would expect, arranging, say, the physical layout of components, signal interconnects, and power planes to comply with electrical rules is not intuitive. It usually depends on visual inspection and measurement to confirm rules are being followed.

As in-house guidelines are more and more frequently augmented by others from targeted IC vendors, many resulting designs are ultimately coming to include some significant deviation from the combined rules in one way or another. As design complexity and performance increase, the risk of such deviation also logically increases. Senior managers struggle with this dilemma every day.

Electrical rules-driven performance verification

Faithfully following electrical rules derived from design guidelines provides an adequate, but not always mandatory, condition for a successful design. Often, design tradeoffs exist where overdesign to meet one rule saves enough design margin for another rule to pass without violations.

This common occurrence may lead you to believe that not all guidelines are necessary and that some may even mask the real performance condition of the design. The goal for any electrical rule checking (ERC)-driven performance verification flow should be to verify if overall electrical performance meets expectations, not the enforcement of each individual physical routing rule.

One new approach to consider is a design flow that allows design teams to ‘DARE’ – that is, to easily Detect, Analyze, Repair, and Evaluate potential electrical design flaws early and often as the layout hardens (Figure 2).

Once the design requirements have been determined and pre-layout circuit design starts wrapping up, layout begins. Here, performance-critical portions of the design can be among the first layout structures to be checked and verified against performance objectives. Using HyperLynx ERC early and often to guide layout designers towards performance-friendly physical implementations will reduce the rework required as more of the layout topology hardens.

Running ERC to detect potential performance design flaws enables the layout team to iterate immediately as they seek to resolve issues through layout alternatives. However, some SI/PI design flaws do require a deeper understanding. These are candidates for simulation under HyperLynx SI, HyperLynx PI, or HyperLynx 3D EM to analyze and quantify the severity of the violation.

Critical design flaws are then flagged and passed back to the layout team for further repair. This simulation triage process continues as the layout matures and until all ERC violations have been addressed either through layout repair or an engineering-led violation mitigation design practice. At that point, a final performance evaluation ERC run should be run as part of larger electrical rule signoff procedure to double check that no catastrophic flaws have been missed.

Adopting this type of ERC-driven performance verification methodology truly reduces the chances of hard-to-detect electrical design flaws passing manufacturing signoff. Furthermore, overall design quality is improved as are design performance margins. And every design still benefits from a master designer’s quality review before release.

Keep it clean with ERC

ERC not only helps improve simulation coverage, but also provides a secure method for capturing and applying sensitive master designer know-how.

The Mentor Graphics HyperLynx ERC tool helps keep designs clean of hard-to-detect electrical design flaws. It supports custom rule definition using standard scripting languages.

Rule developers leverage work converting design guidelines to actionable layout rule modes by capturing intent in the form of programmable electrical rule descriptions. The IP contained within each description can be encrypted, locking the contents from outside tampering. The encrypted rule set can then safely be shared with internal design teams or with business partners and customers (see Figure 3).

Encryption opens the door for ERC developers to consider enriching rule sets with sensitive design know-how in the form of algorithmically-rich computational light rules. This fills a gap between those design teams that do not use any simulation tools and those that rely on SI/PI experts for help with performance verification. In the former case, design teams lack the expertise to adequately operate sophisticated SI/PI tools but do desire to improve design performance predictability. In the latter case, there typically are not enough SI/PI experts available to the team or enough time to exhaustively simulate the entire design.

These performance indicator rules are really lightweight analysis engines. They are not intended to replace the SI/PI analysis tool, but rather to be used to better screen potential electrical design faults by reporting a quantitative measure of ‘goodness’ against SI/PI metrics. Faults detected by these types of rule sets help the design team focus on precise locations that warrant deeper SI/PI simulation and analysis. Or better yet, they can direct the layout team to iterate, attempting to resolve violations through alternative layouts without requiring help from an SI/PI expert.

Only rule violations that cannot be resolved through layout iterations reach the SI/PI expert, where deeper simulation and analysis is applied to help quantify the seriousness of the violation and determine if other rule violation mitigation techniques should be employed. Using this methodology helps guarantee that the complete design is being checked and only mission-critical performance issues are being passed on to the SI/PI experts for resolution.

Taking ERC to the next level

Most designers will see the value in an ERC-driven performance verification methodology. But some may ask, “How does this new way of driving performance analysis fit into the real world way of doing design that entails multiple PCBs, multiple geographically dispersed design teams, and chipsets originating from multiple vendors?”  The answer is two-fold:

1. The pervasive availability of separate private (internal-use only) and public (customer/partner use) rules sets helps ensures designers are checking the right things.
2. The adoption of an ERC solution that supports multi-rule sets, multi-user, and multi-engine models is one that fits the preferred design strategies prevalent among many enterprise-wide ventures.

As IC vendors, ODM vendors, and others realize that an encrypted ERC rule set is an elegant way of delivering lightweight analysis engines for performance checking, the number and variety of commercially available rule sets will increase. Vendors, design centers and customer marketing/support teams can use them to ensure that chipset-centric design guidelines are observed during the layout process. This will help make sure that a PCB moves to manufacturing on time and the forecast delivery for IC vendor chipsets is not disrupted.

In cases where certain PCBs within a multi-board system are outsourced to an ODM, ERC rule sets can augment/replace visual inspection methods used during typical incoming inspection and design reviews. The ODMs certainly possess extensive design knowledge for most contracted designs. Each ODM can develop an encrypted ERC rule set to be used as part of standard in-house design practices and it can be passed on to customers to help speed up their incoming inspection and acceptance of the design.

Encrypted HyperLynx ERC rule sets enable universities, consultants, material suppliers and component providers in the PCB design and manufacturing food chain to deliver their own electrical rule IP securely to PCB engineers. This will become increasingly important as PCB speeds increase and thereby require more exhaustive performance verification.

Component manufacturers especially can help their customers ensure proper use of their products by providing rule sets that determine the power delivery/isolation rules or recommended interconnect topologies for critical signals that should followed. The types and varieties of rule sets that improve overall design quality and performance margins are left to the clever minds of the rule set developer.

In cases where multiple PCBs are designed across geographically dispersed design teams, you need a work flow where ERC occurs concurrently with layout. Under this model, layout engineers can choose to run multiple rule sets on a network of computers. A concurrent analysis tool manager (Figure 5) enables many different ERC runs based upon multiple rule sets to be assigned to different network servers as layout progresses. As the number of PCBs under design, the number of designers actively performing layout, and design sizes and rule set complexity increase, there will be a growing need to launch multiple rule checks and to manage violation resolution concurrently with the layout.

Electrical rule checks help ensure a clean design

The electrical performance of all PCBs comprising an entire system can now be assessed in a timely manner for compliance against original design performance goals. As rule violations are detected, the simulation triage described earlier is applied to ensure only critical errors receive more detailed SI/PI simulations to evaluate whether or not each violation requires repair. Higher quality designs with better design margins that reach production volume sooner are the benefits to those companies that ‘DARE’ to change the way they verify electrical performance.

About the author

Rod Dudzinski is responsible for IE3D market and business development at Mentor Graphics. He has a successful history of leading the development and introduction of new IC place and route, timing/circuit simulation and modeling, and EM Synthesis products into the EDA marketplace. Rod’s experience spans 25 years. Prior to Mentor, Rod held positions at Zeland Software, Lorentz Solution, Cooper & Chyan Technologies and Cadence Design Systems.

Contact

Mentor Graphics
Corporate Office
8005 SW Boeckman Rd
Wilsonville
OR 97070
USA

T: +1 800 547 3000
W: www.mentor.com

It’s no longer possible to design all the subsystems of an SoC from scratch and expect to get the chip out in a reasonable timeframe, so today’s SoCs are complex integrations of new logic, IP blocks brought forward from previous designs, and functional and interface IP licensed in from third parties. Some companies are even using third-party IP to build their system interconnect, on the basis of that its communications management support and interfaces to other IP blocks will help get a design out more quickly. In effect, an SoC is a sea of interfaces.

The use of IP enables complex products such as the iPad, which is good for the consumer, but brings integration challenges for SoC designers and the verification teams that ensure their designs will work as planned. Individual IP blocks may be as complex as entire SoCs of five years ago, and may have internal clocking and power-management strategies which SoC designers need to be aware of. The integration of these complex blocks means that clock signals may have to negotiate up to 100 asynchronous clock domains as they cross block interfaces. Similarly, systemic power management strategies may involve coordinating power management within a block and among many blocks.

Managing the verification of such complex systems is challenging. The designs are large, so designers need tools with very high capacities. They need to be able to control the rising tide of uncertainty caused by clock signals that cross domains, and power-management strategies that create unknown (X) logic states when they blocks are turned on and off. Most of all, designers need these tools to tackle such problems at the highest level of abstraction possible, to speed up the verification process and stop the issues multiplying and becoming more obscure as the RTL design is decomposed to gates. Clock domain crossing (CDC) tools, engineered to recognize and analyze crossings for problems, are essential to help control the verification complexity involved in tackling a full SoC.

With the right tools, overcoming these issues can mean more than just a problem solved: by applying the right analytic tools, the design can actually be functionally improved. For example, linting tools that give early indications of potential design-for-test problems help avoid synthesizing untestable logic. Tools that understand the X states that are created at domain boundaries in complex designs, and how they propagate, can help avoid too much optimism about their impact at the RTL level (where X states can hide real issues), and too much pessimism about their impact at the gate level. The result: better analysis leads to better designs.

The same is true with ‘resetability analysis’, which considers whether it is necessary to take a reset signal to every node that the design says needs one, or whether it is possible to restrict the distribution of reset signals to a subset of critical nodes. If an early analysis shows that some nodes can do without a reset signal without affecting the logical function, which means less routing and lower power consumption on the final chip. Again: better analysis leads to a better design.

As SoCs have become more complex, so has the task of verifying that what is implemented on chip is what the designer intended. No single verification approach can deliver the certainty that design teams need to tape out, but a suite of tools that each address a particular issue can help build that confidence. Applying the tools may also do more than avoid errors: better analysis early in the design process can avoid issues propagating, and, by highlighting which issues matter and which can be safely ignored, give designers the freedom to improve their designs.

Contact

This creates a number of ‘short-channel’ effects, including:

- Threshold voltage roll-off: The threshold voltage of the device is reduced because the depletion regions of the source and drain intrude into the channel, change its effective geometry and therefore make it easier for current to flow from source to drain. The lowered threshold voltage makes it more difficult to turn the transistor fully Off, increasing its leakage current and therefore power consumption.

- Drain-induced barrier lowering (DIBL): As the source and drain get closer together, they become electrostatically coupled, such that the drain bias can affect the potential barrier to current flow at the source junction, increasing the threshold voltage roll-off, and hence the leakage.

- Charge mobility degradation: Atomistic effects such as surface scattering, velocity saturation, impact ionization, and hot-electron effects, reduce the mobility of both electron and hole charge carriers. Device architects have tried various ways to strain the crystal lattice of the channel to make it easier for charge carriers to flow through it, hence restoring its conductivity.

- Threshold voltage variation: This is due to statistical irregularities in dopant concentration, which become significant when the devices are so small.

Short-channel effects have negated many of the benefits of scaling transistors from 28nm to 20nm and have led to concerns about the economic viability of planar semiconductor processes at 20nm and below.

Alternative transistor designs

The industry has responded by suggesting two alternate device architectures, known as finFET and FD-SOI, that mitigate the effects. The finFET moves the channel out of the bulk silicon into a vertical fin and wraps it on three sides with a gate electrode, improving the electrostatic control of the channel. The silicon-on-insulator (SOI) transistor is a planar device whose channel is built in such a thin (shallow) silicon layer that the gate electrode can exercise full electrostatic control of the charge carriers in it.

FinFETs

FinFETs (Guide) are built as shown in this diagram.

The strong electrostatic control afforded by ensuring that the gate is close to all areas of the channel makes it easier to control the device’s threshold voltage, reducing leakage between source and drain, as well as making it possible to switch it more quickly.

FinFETs can be made on regular silicon wafers, or on SOI wafers, as shown.

Building finFETs on SOI is simpler than building them in bulk, because the etch process that forms the fin comes to a natural stop when it reaches the buried oxide layer of SOI, rather than having to be controlled by a timed etch process, subject to process variation, in bulk silicon. Building finFETs on SOI may also lead to more rectangular fins with more regular heights, since on bulk silicon the shallow trench isolation oxide that is necessary to insulate one fin from the next can’t be planarized, leading to variability in the height of the fin above the oxide.

The main manufacturing challenges for finFETs are:

- controlling the etch along the edges of these tall structures to generate uniform fin widths and achieve good edge verticality

- uniformly doping the resulting complex 3D surfaces

- depositing all the films used in the gate stack so that they conform to the surface of the fin

Meeting these challenges requires new materials and more processing steps than used in bulk or SOI devices, making them more expensive to produce.

From an electrical perspective, the gate length (L) of a finFET is equal to the thickness of the gate (t_fin), while the gate width (W_eff) is the periphery of the gate along both sides on the fin plus the thickness of the fin: W = 2 * H + t, as shown.

The fin’s thinness enables strong electrostatic control over the channel’s charge carriers, but limits the number of carriers and hence the channel’s drive strength. To overcome this problem, multiple fins can be connected in parallel, all driven by the same gate. The consequence of the finFET’s topology is that the choice of device width is restricted to multiples of W_eff.

Benefits and risks of finFETs

Fully depleted silicon-on-insulator

Another way to control short-channel effects in deep submicron transistors is to make planar devices on SOI wafers, forming the channel in a thin silicon layer above the buried oxide. As discussed, the silicon layer is so thin that the gate can influence the whole channel and so completely shut off conduction.

There are two types of SOI devices: partially depleted (PD-SOI) and fully depleted SOI (FD-SOI).

In PD-SOI, the silicon film is 50nm to 90nm thick, so the gate’s influence cannot reach through the channel’s full depth, making the PD-SOI device behave like a slightly better bulk MOSFET.

In FD-SOI (Guide) the silicon film is 5nm to 20nm thick, so that the gate’s influence penetrates the full depth of the channel. The conduction channel doesn’t need to be doped, which eliminates a source of process variability, and the fact that it sits on an insulating layer means there is nowhere for unwanted current paths to form. This in turn relaxes the performance necessary from the gate, and so means that a thicker gate oxide can be used, reducing gate leakage. One advantage of FDSOI over finFETs is that it is possible to back-bias the channels through substrate contacts and so gain even greater control over the threshold voltage.

The primary disadvantage of FD-SOI is the cost of SOI wafers, which is due to the difficulty of accurately controlling the silicon film thickness across the entire wafer. The film thickness is important because the threshold voltage is dependent upon it, so if the film thickness varies across the wafer, so will the device performance. Some manufacturers claim to be able to control the film thickness across a 300mm wafer to within +/-0.5nm.

One drawback of FD-SOI is that it is harder to implement multiple V_t circuitry, which is useful for creating areas of higher-performance or lower-power devices, because it is not possible to alter the channel doping to affect the devices’ threshold voltage. Instead, the threshold voltage is controlled by tuning the gate-stack materials. However, a combination of doping and active biasing can be used to alter the threshold of a target group of transistors that have a common sub-oxide backplane. Another disadvantage of FD-SOI is that it is not possible to selectively strain the channel to improve carrier mobility.

Benefits and risks of FD-SOI

Designing with finFETs

Layout

Early results suggest that the impact on digital design of using finFETs need not be that great if conservative approaches are taken. It should be possible to migrate circuits created for advanced planar processes to finFETs, using a lot of modeling and simulation to recheck the circuit performance.

One key difference between finFET-based design and that using conventional planar devices is that the freedom to choose the device’s drive strength is reduced as the drive strength can only be increased during layout by adding fins. The effective width of the device becomes quantized, and the quantization effect is worse for smaller transistors for which the next step up from the minimum-size device is one that is twice as wide.

In terms of optimization for power, the finFET provides circuit designers with the opportunity to trade leakage for switching speed and create fast/medium/slow versions of the base transistor.

Design rule checking

DRC for finFETs implies fin-related checks – such as of fin width and fin-to-fin spacing – that are similar to regular planar checks. There are also a number of checks that are specific to finFET processes, such as checking that fins and poly are confined to regular, lithographically-friendly pitches in a fixed orientation.

A typical set of finFET physical verification rules contains the elements listed in Table 1 and illustrated in Figure 9:

RX and RXFIN are drawn layers. RX is drawn as in prior technologies except for some gridding constraints imposed by RXFIN.

RXFIN over RX is ‘active’. RXFIN not over RX is ‘dummy’. An RXFIN will often have portions that are active and portions that are dummy.

Active portions must be surrounded by three dummies. This is enforced through the RXFIN_enclosure rules.

RXFIN_enclosure is a generated shape that encloses a region of fins with a common pitch.

Layout vs schematic

Device parameter extraction for finFETs is similar to planar devices, including the need to consider layout-dependent effects. Unlike planar devices, the key feature of gate width cannot be measured directly from the two-dimensional layout. The effective gate width depends on the fin height, the distance that the fin protrudes above the oxide surface. However, all the fins are the same height, so Hfin can be entered as a process  parameter and used to calculate effective device width, as before.

Another LVS concern for finFETs is the need to accurately extract the source/drain resistance, which forms a significant component of the transistor’s parasitic series resistance.

Designing with FD-SOI

Layout

In principle, it is possible to directly port a cell library from a bulk process on to an FD-SOI process. However, the results will not be as good as dedicated cell libraries designed to take advantage of the different balance of capacitances in FD-SOI devices and the reduced variability of undoped channels.

The SOI Consortium has proposed a ‘safe’ way to adopt FD-SOI, using hybrid FD-SOI/bulk co-integration. In this approach, IP cores that are deemed too risky to redesign are placed on to areas of the wafer that expose the bulk silicon, while synthesized logic optimized to use FD-SOI structures is placed on areas of the wafer that retain the buried oxide layer.

The use of FD-SOI could have a significant impact on design if designers take up the opportunity to dynamically back-bias the channel, which gives better control over VT variability and so improves device switching speed.

DRC/LVS

Since FD-SOI is a planar technology, DRC and LVS checking is the same as for existing bulk technologies.

Conclusion

Short-channel effects severely limit the performance of bulk planar transistors at process nodes below 90nm.Two alternative devices are being proposed for process nodes below 20nm: finFETs and FD-SOI. Both are practical solutions that solve the major short-channel difficulties, both have been proven on real designs, and both are backed by major semiconductor companies. It is not yet clear which technology will predominate or if they will continue to co-exist.

In terms of physical verification, both processes are well supported by Synopsys’ physical verification tools. All new physical checks are well within the capabilities of Synopsys’ DRC solution, and the new device parameters can be extracted with Synopsys’ LVS tools.

(To read what attendees at the December 2012 International Electron Device Meeting felt about the relative merits of finFETs and FD-SOI in practice, click here.)

Authors

Marc Swinnen received a Master’s Degree in Electrical Engineering from the Catholic University of Leuven in Belgium and an MBA from San Jose State University. He has over 20 years of experience in Marketing and Technical Support at various EDA companies. Marc has been at Synopsys for 7 years, where he is Senior Product Marketing Manager working with IC Validator.

Ron Duncan is a Sr. Manager at Synopsys in Mountain View, CA.  His team supports IC Validator and PrimeYield. Ron has worked at Hewlett Packard, ISS and Avant!, prior to Synopsys. His semiconductor and EDA experience spans physical design and verification, circuit simulation, device design, mask synthesis, TCAD and semiconductor manufacturing.  He holds electrical engineering degrees from MIT and Cornell. 

System-on-chip (SoC) verification environments have not been very software-aware, limiting the productivity and quality gains available from better hardware-software integration. Software engineers face the same time-to-market pressures as their hardware counterparts, and sometimes greater ones if design-in customers want early access to the chip. We must knock down the wall between the two disciplines.

There is now a productized technology that can help do just that by making hardware models available early to software engineers. Hardware and software can be designed, verified, and improved in unison, boosting productivity.

The Great Wall

FPGA prototyping

FPGA prototypes are widely used but impose a serial flow. The software team cannot get a development board until the RTL is finished. If the design is a moving target and is a multi-processor SoC with more than a few million gates, this inserts unnecessary delay into HW/SW integration.

Then, when designs become too large to fit onto one FPGA board, mapping the RTL becomes a real problem. The typical performance of FPGA software means it can take many hours or days to compile and then place-and-route a design on the full prototype. ECOs expand the turnaround time further before verification can resume.

Add to that the difficulties in gaining enough visibility into a design for effective debugging with standard FPGA verification techniques, and the whole process becomes yet more difficult and unproductive.

Accelerated simulation with VIP

Accelerated simulation using verification IP speeds up hardware design. But it does not bring the software and integration teams into the loop.

Although testbench-based simulation environments (e.g., SystemVerilog/UVM for hardware verification) are ideal for testing and debugging RTL IP, software developers cannot easily run their tests and use their tools concurrently in this environment. We need an alternative approach to system-level verification.

Emulation

Emulation can make a difference, but in-circuit emulation (ICE) effectively strands the emulator in the lab. Access becomes a special privilege, largely confined to hardware engineers. Software teams get very limited access or companies must buy and maintain multiple emulator setups.

Multiple emulators—each perhaps needing multiple hardware speed adaptors to model protocol host and peripheral connections—fill the lab with fault-vulnerable cables, present pin limitations, and incur high costs.

Fenced in

Thus, there remains an unnecessarily high wall between hardware and software engineers: different verification silos; different languages; related but disconnected problems.

The verification process must reflect the importance of software, since it constitutes a large and increasing share of any SoC, is updated more frequently than hardware, and may be being worked upon by ten times as many engineers as the hardware.

In consumer electronics, hardware will often undergo a respin every few months. This leaves almost no time for software teams to do their work if they need to wait for hardware prototypes.

Tear down the wall

A new virtual lab use-model for emulation helps tear down the wall, shortens development time, and enhances verification robustness.

It replaces physical hardware models with virtual peripherals that run target hardware protocols in software, moving the emulator out of the lab and into the datacenter. The emulator can be accessed like a server by everyone in the company. Virtual labs provide stable 24/7 emulation environments in which hardware and software meet and evolve together.

Virtual models can be connected or disconnected in software by choosing a particular configuration of a compiled design under test (DUT) rather than by connecting different pieces of hardware with cables. The emulator can be accessed simultaneously by software, hardware, and integration engineers without disruption. This approach can be applied both to a single project and to multiple projects running at the same time.

Where ICE typically provides access for a handful of engineers per emulator, a virtual lab can provide access for hundreds. That’s a dramatic expansion of a valuable resource.

With 24/7 remote access and lower downtime due to fewer physical connection issues (no more kicked cables or running out of pins), the cost-benefit advantages over ICE become even greater.

Plus, because users can run host connections through a virtual machine, they don’t have to worry about crashing the verification process if they address a memory that does not yet exist.

With a virtual lab, the global software team gets access to hardware while it is still in RTL, running against multiple peripherals, on a single emulator. Developers can target it from remote PCs, using the real OS, drivers, stack, and applications rather than hardware targets running on speed adaptors.

A virtual lab using independently validated protocol models, and running on a Mentor Graphics Veloce emulator, brings the SoC verification environment closer to the real, externally-connected one with which the target device will ultimately interact. The protocol models are the same IP and same software, delivering the same functionality as ICE-based speed adapter solutions. But they are now delivered as software products, or Veloce VirtuaLAB components.

As more embedded software is verified with hardware in virtual labs, the productivity of SoC verification immediately increases. Going forward, the technique will raise our understanding of how software debug can be improved, and thereby also improve the efficiency of hardware-software integration.

Further enhancing the virtual lab

Multicore SoCs are encountering limitations in traditional hardware-based debug connections, such as JTAG. This is also driving interest in software-based alternatives.

JTAG is intrusive because it suspends the target processor during interactive debug, performing thousands of additional clock cycles while the state of the rest of the design advances. In a multiprocessor design, this means other processors continue clocking normally, becoming out of sync with the target processor. What is debugged would not occur in the real software-hardware environment, rendering the process ineffective.

Mentor Graphics’ Codelink software provides a non-intrusive debug connection that passively streams data from the design (i.e., monitoring rather than interrupting the process as JTAG does). Codelink offers a more transparent way of performing multiprocessor design debug, and the virtual lab is a key enabler both for using it in emulation and delivering it to teams worldwide.

Conclusion

The virtual lab method puts emulation into the datacenter, providing server-like access. It is all about bringing software engineering into the heart of verification. Software and integration engineers have been knocking on the wall long enough; it’s time we knocked it down.

Author 

Richard Pugh is the product marketing manager for Mentor’s Emulation Division.

Contact

Mentor Graphics
Corporate Office
8005 SW Boeckman Rd
Wilsonville
OR 97070
USA

T: +1 800 547 3000
W: www.mentor.com

Overall, engineers need an infrastructure that reduces risk, reflects shrinking project deadlines and brings greater consistency to the IP-to-SoC flow. Let’s look at why you should and how you can achieve that.

The risks of mix-and-match

It is often the case that the IP-to-SoC FPGA-based prototyping process will involve different tools and different boards across the two stages. Bridging this divide is where many of the problems arise. They can be illustrated by looking at the main obstacles presented in terms of how the IP is delivered to the SoC team. Typically, this is done in one of three ways:

1.  As RTL
2.  Encapsulated as a ‘physical’ hardware deliverable
3.  As both an IP block and an FPGA binary

1. RTL deliverables

The RTL option has the benefits that it represents a portable ‘soft’ delivery and provides such flexibility that the code can be tailored to fit any SoC platform.

But SoC teams will often find themselves duplicating much of the earlier IP prototyping and verification effort.

If the platform and tools on which the IP was developed differ from those being used by the SoC team, there is a greater likelihood of model mismatches. This mismatch issue is obviously a concern where working with third-party IP suppliers.

However, a further issue arises for third-party partners: the lack of sufficient protection for the IP. Externally and internally, some encryption is desirable.

2. Physical hardware deliverables

A physical board offers the advantages of validated delivery in a format that should have been tuned to the configuration of the prototype. So, it should only involve a single prototyping effort, shouldn’t it?

Well, it might, but it is also expensive: there are now two prototyping boards where only one was probably necessary. However, this may be the design team’s preferred way of working. Still, there are other factors to consider.

In our inconsistent mix-and-match world, connecting the IP board to the SoC board typically entails extra work creating adapters and custom interfaces, both of which then need their own debug. There is also no guarantee of clock synchronization.

3. FPGA binaries

An FPGA binary looks like an all-round winner. It’s validated, it’s tuned and it involves a single prototyping effort.

But you can only feed forward these binaries where you are using the same FPGA platform at both the IP and SoC prototyping stages. Any mix-and-match of in-house and third-party boards makes it effectively impossible to do.

Consistency with HAPS-70

The obvious answer is to align your IP and SoC prototyping environments as closely as possible.

We’ve discussed juggling the use of different types of board and design software at the stages in your IP-to-SoC prototyping flow. Beyond that though, it’s fair to ask how many of the tools needed to realize both the IP and the SoC the prototyping board vendor provides. Often, the beyond-silicon support is limited and the gaps are significant.

Synopsys has developed an integrated flow based around existing tools and its Xilinx Virtex-7 2000T-based family of HAPS-70 boards, embracing both the hardware and the software needed to provide consistency. You can thereby minimize risk and reduce prototyping time.

Let’s look again at the three IP delivery models but in the context of HAPS-70.

1. HAPS-70 and RTL deliverables

IP can be developed and prepared for FPGA-based prototyping utilizing Synopsys’ Certify and Synplify Premier software tools. These tools are applicable to usage at both the individual IP level and higher SoC level. This enables direct script reuse, saves time and increases confidence in the block being fed through.

The target hardware is also consistent at both stages. HAPS-70 has a modular and symmetrical system architecture to smooth the transfer from, say, a single to a multi-FPGA-based system. Moving daughter boards and related connection pin-outs has a minimal effect on timing and performance as the HAPS-70 I/O connector banks directly map to the super logic regions (SLRs) found on the 2000T. The 1:1 SLR-to-bank-to-HapsTrak connector ensures uniform timing characteristics.

2. HAPS-70 and physical deliverables

Simply put, you’re now working withing the same IP-to-SoC flow, the same environment. There’s a single IP FPGA bit image file for both the IP and SoC stages. Connection between the two systems is over the common HapsTrak interface. Translation and debug risks are thus mitigated. Clocks and resets are synchronized by the inbuilt HAPS-70 capabilities.

The system allows for high-speed time-domain multiplexing between systems to raise FPGA-based prototype performance. Configuration over UMRBus is quick and easy. And the IP can now be locked and encrypted.

3. HAPS-70 and FPGA binaries

Here again, the use of the same consistent platform overcomes the otherwise near insuperable obstacle facing this IP-to-SoC prototyping model.

In addition to your ability to feed through the same FPGA bit file of your IP, there are the further benefits that both daughter board placement and the connectors are identical.

What we all really need

By the time that a typical SoC project has reached FPGA-based prototyping, the design team wants to focus on issues that could affect the user experience in the target design. Do the various IP blocks in the design function as intended and fit together in the whole? What happens when you expose them to real-world inputs and multi-processor software?

If the prototyping infrastructure itself introduces delays and irrelevant bugs, the technique’s advantages are greatly diminished. The rational answer then is to adopt an IP-to-SoC infrastructure that offers most consistency from initial IP development through to final silicon.

HAPS-70 has been configured to do just that. With IP and SoC teams working in the same environment, communication between them will improve. And your engineers can focus on the needs of the final silicon as quickly and as efficiently as possible.

Until recently, there were two main ways to set up embedded software development tools:

1. Purchase proprietary tools from one of the specialist vendors. Such tools are not cheap, as they offer specialist functionality to a limited market (compared with desktop software development tools, for example). But good quality support is generally available, which is reassuring to a developer on a tight deadline.
2. Obtain open source tools by downloading them at no cost.

The second option sounds attractive. For many, ‘open source’ means ‘free of charge’. However, this is only true really for the software download. The real costs are down the line. There are many issues to resolve. All take time and time = money.

• Which specific tools do you need?
• Have you got the right desktop tools to build the embedded tools?
• Which versions of the toolchain components do you need?
• Which patches should be applied?
• Do you know what works with what? (This table gives some clues as to the challenge)
• How do you configure the toolchain components? (There are thousands of options!)
• What CPUs do you need to support?
• Do you need big- or little-endian support or both?
• Have you got the test suites to validate the tools?

An understanding of the cost of resolving these issues has led many developers to seek a ‘Third Way’. A number of specialist vendors supply embedded toolchains. These are based on open source technology and pre-configured ready for use. Value is added by including other tools and offering professional grade support instead of necessitating hours posting on forums.

This is a cost effective approach that offers the economy of open source software with the security and backup of a commercial product. More information can be found in this whitepaper.

Colin’s regular blog is located at: http://blogs.mentor.com/colinwalls. He can be reached by email at colin underscore walls at mentor dot com.

Of most concern to custom/analog designers are the challenges that arise from manufacturing complexity. On top of increasing timing, power, and area challenges, the 20nm process generation brings with it the deep and complex interdependency of manufacturing and variability. The five main challenges of 20nm custom and analog design comprise the use of double patterning; layout-dependent effects (LDE); the use of new types of local interconnect layers; a massively increased collection of design rules; and increasing device complexity and variation. Concerns about manufacturability issues vary according to design style. For example, analog and I/O designers are most concerned about LDE, circuit specifications, and area versus performance tradeoffs. Memory and standard cell designers are very concerned about density, and as such, double patterning and local interconnect are key concerns.

The solution to 20nm custom/analog challenges lies not only in new point tools, but in a new custom design methodology. In this methodology, circuit (schematic) and layout designers will work in close collaboration, and will have the ability to rapidly exchange information. Circuit designers will be able to obtain early parasitic estimates before the layout is completed. The flow will use in-design, signoff-quality engines as opposed to attempting to fix everything during the final signoff stage. And all tools will be “double patterning-aware” and ready for 20nm.

1. Double Patterning

The most-discussed manufacturability issue at 20nm is double patterning. This technology splits a layer into two separate masks so that 193nm lithography can print structures that are too close together to resolve with a single mask. This technology is needed to get current 193nm lithography equipment to print correctly when metal pitches are below 80nm, which will be the case for at least some of the metal layers for almost any 20nm design.

When double patterning is used, each mask is exposed separately, and the exposures overlap to create features that are half the pitch that would otherwise be printable with 193nm lithography.

The concept may be simple, but managing double patterning is difficult. It requires a two-color layout decomposition process in which alternate colors (such as red and green) are used to indicate which features will be placed on which mask. This results in added design rules that restrict the placement and proximity of layout features. For example, traces that are the same color can’t be placed too closely together.

It is very easy to create a design-rule checking (DRC) “loop,” which is a coloring conflict that cannot converge on a solution that works. And in many cases, it will be necessary to trace back a number of steps to unravel how the loop was created.

Handling double patterning properly is a major concern for custom designers of standard cells, memories, and I/Os. These designers must be cognizant of coloring as they create layouts to optimize area. It is difficult to achieve a high density while making the design decomposable. According to some reports, standard cells that previously took four hours to lay out sometimes take a week at 20nm, because designers have to keep re-running verification as they try to pack decomposable cells as tightly as possible.

Analog designers are concerned about the mismatches that an additional mask can cause. Double patterning impacts electrical performance because different masks on a given layer will shift during the manufacturing process. This mask shift causes variations that have a direct impact on RC and the interconnect. As a result, parasitic matching can become very challenging between elements that are rendered using different masks.

EDA tools can help automate the colorized decomposition process and can help ensure correctness. In a 20nm-aware toolset, all physical design tools should be double patterning‒aware, including placement, routing, extraction, and physical verification. For example, extraction must be able to predict the capacitance variation resulting from mask shift.

Another capability that’s needed is automated color-aware layout. Here, color conflicts are avoided as the layout designer draws shapes and places cells. Once a shape is dropped into place, the tool automatically makes any needed coloring changes. Locking color choices down in the design phase sets a constraint for the manufacturer and helps to ensure that matching is correct by placing pairs of nets or devices on the same mask.

Instead of running signoff verification once every four hours, a quick double patterning check should be run after every editing command. In this way errors can be fixed quickly, and designers don’t end up with DRC loops that may take many steps to unwind.

2. Layout-Dependent Effects

At 20nm, it’s not enough to model the performance of a transistor or cell in isolation. The environment around a device will change its behavior, a phenomenon captured by the term LDE. Although LDE became apparent at 28nm, the problem has grown significantly worse at 20nm, where cells are much closer together. At 20nm, up to 30 per cent of device performance can be attributed to the layout ‘context’. For example, the voltage threshold of a transistor will change based on how close the device is to the edge of a well – this is called the well proximity effect.

Other modifiers of device performance include the distance between gates – including dummy poly – which has a direct effect on the drain current of the transistor. This is known as the poly spacing effect. Another major cause of LDE is mechanical stress, which is often intentionally induced to improve CMOS transistor performance. For example, a dual stress liner is a silicon nitride (SiN) capping layer that is intentionally deposited to be compressive on PMOS and tensile on NMOS. Such stresses improve the performance of either form of transistor. Nonetheless, it results in variability that may make it difficult to close timing. Stress is also unintentionally induced through technologies such as shallow trench isolation, which isolates transistors and determines active-to-active spacing.

LDE cannot be modeled in Pcells (parametized cells) or device models. As a result, it is no longer enough to create a schematic, pick a topology, run a simulation, and throw it over the wall to a layout designer. At 20nm, circuit designers have to consider layout context as well as device topology, and they need to simulate with layout effects prior to layout completion. This may sound paradoxical, but it is possible to identify devices that are sensitive to LDE and thus allow the designer to recognize which components need greater care in layout. Less sensitive devices can be placed closer to well boundaries, for example. Circuit designers can also make use of LDE simulation using partial layouts and LDE-aware layout module generators. Layout engineers can use LDE hotspot detection and fixing.

The underlying technology that is needed is context-driven placement and optimization that can determine how different cells are going to interact and how the layout context affects timing and power. The design tool should take care of LDE during both schematic and layout phases. But it’s not just about tools. Circuit and layout designers have to learn to work together in new ways, with a much higher level of cooperation.

3. Interconnect layers

For many custom designers, 20nm is all about density. Local interconnect (LI) layers – also called middle-of-line (MOL) layers – offer a way to achieve very dense local routing below the first metal layer. There may be several of these layers available in a given process, and most don’t use contacts. Instead, they connect by shape overlap without any need for a cut layer. Getting rid of contacts makes routing denser because contacts are bigger than nets, and can’t be placed too close to nets.

However, designers need to be aware that LI layers have their own restrictive design rules. For example, LI shapes can only be rectangles, and they often have fixed directions with length constraints.

4. Design rules

At 20nm, there may be more than 5,000 design rule checks. Some 1,000 new rules have been added since the 90nm process node, and double patterning alone requires 30 to 40 checks. The 20nm node adds another 400 new advanced rules such as wrong width and wrong spacing, discrete width and spacing, and special rules for pin access on cells. Custom and mixed-signal designers will face directional orientation rules, specific rules regarding length/width and transistor proximity, and new rules governing legal inter-digitation patterns.

An important point to remember is that 20nm doesn’t just bring in more rules; it brings in more complex rules. Simple rules of thumb or memorization won’t work any more. What’s needed is a design system that can check design rules as the design progresses, rather than waiting for a final signoff check.

5. Device complexity and variation

Transistors at 20nm are very small and very fast, and variation is a constant challenge. Transistors are sensitive to channel length and channel doping, and transistor behavior is subject to short-channel effects. Custom designers must minimize leakage, ensure reliability, and achieve reasonable yields.

The reality is that 20nm transistors were designed for achieving high densities in digital design, not for optimizing leakage or gain in custom/analog design. A limited set of device sizes are available for design. Width and length parameters are limited to a small set of values, and with fewer choices, manually tuning transistors to meet specs (such as gain) is difficult.

Below 20nm many, if not most, designs will use a new type of transistor called a FinFET. In a FinFET, the transistor gate wraps around three sides of the transistor’s elevated channel, or ‘fin’. This forms conducting channels on three sides of the vertical fin structure, providing much more control over current than planar transistors. Multiple fins can be used to provide additional current. FinFETs promise greatly reduced power at a given level of performance.

However, FinFETs raise some challenges for custom/analog designers. One constraint is that all the fins on the transistors on a given chip must be the same width and height. Designers can add fins to increase the width, but this can only be done in discrete increments—you can add 2 fins or 3 fins, but not 2.75 fins. In contrast, planar transistors can be adjusted to any channel width in order to meet specifications.

Other challenges include additional design rules, manufacturing variations in the width and height of fins, and metal and via resistance. SPICE models with additional parameters will be needed for the FinFETs, and simulators must be able to interpret them. Extraction tools must be aware of the capacitance and resistance that arises from 3D transistor structures. Layout tools will have to be optimized to handle FinFETs. And like any new technology, FinFETS will require ecosystem support including EDA tools, process design kits (PDKs), physical IP, and silicon-proven manufacturing processes.

A new methodology

To resolve the challenges described in the above sections, every tool in the custom/analog flow needs to be aware of the changes that 20nm brings, including double patterning, LDE, local interconnect, complex design rules, device variation, and FinFETs. But it is not enough to just improve tools. What is needed is a new methodology that provides a higher level of automation than existing flows. In this methodology, circuit and layout designers will exchange and share information, ”partial layout” will provide early estimates of parasitics and LDE, and an in-design signoff approach will greatly shorten final signoff runs.

The traditional custom/analog flow is a manual, “throw it over the wall” approach. Circuit designers do schematic entry and run an ideal simulation without layout parasitics. The design is tossed to layout designers who handle device creation, manual placement, and manual routing. Next comes physical verification, extraction, and a final simulation. It’s a time-consuming, serial methodology in which issues are exposed very late in the design process, and many design iterations may occur. Without changing this approach, blocks that took four hours to lay out at 28nm could easily take a week at 20nm.

What is required is a more automated and collaborative methodology. Here, circuit designers draw schematics, just like they always have. But they also pass constraints to the layout designers, and run a pre-layout parasitic and LDE estimation. On the right side of the diagram, both circuit designers and layout designers can use Modgens – a Cadence term for automatic module generators – to quickly generate layouts for structures such as differential pairs, current mirrors, and resistor arrays. Although not final “DRC-clean” layouts, these automatically generated layouts allow accurate physical effects to be extracted, analyzed, and simulated. Modules can then be fed into an analog placer and assembled into a floorplan.

Layout engineers then perform device placement, routing, in-design signoff, and extraction. In short, the basic roles of circuit designers and layout designers remain the same, but there is an ongoing and rapid exchange of information and a high degree of collaboration. Constraints flow easily between the schematic and layout environments.

Automatic module generators help enable “partial layout,” which is the ability to quickly generate an extracted layout view so circuit designers can run simulations with real parasitic and LDE information. In this way, the electrical and mismatch problems that might be caused by layout effects can be spotted and remedied early in the design cycle. The module generators, however, must be ready for 20nm, with place-and-route engine support for 20nm design rules, complex abutment support, array-based FinFET configurations, coloring for double patterning, and LDE awareness.

Another approach for bringing physical effects into initial simulations is incremental design. Here, designers lay out the pieces they care about with assisted or full automation, and gather as much physical and electrical information as they can. This results in a partial layout extraction. The emphasis is on placement rather than routing. The point is that designers are not taking the time to do a full layout, just what’s necessary to generate the desired parasitic information.

Finally, in-design signoff is a must at 20nm. If a designer makes a mistake during layout, the feedback should come immediately, not four hours or a month later. Otherwise many design iterations may be needed for each block, with each iteration taking longer than it took to do the original design. There are two types of interactive editing checks that can help avoid those iterations. One is “in-edit checking,” which warns of errors while geometry is being created. Another is “post-edit signoff-quality checking,” which exercises a more robust check after each edit is completed.
The key to in-design signoff is having “signoff-quality” engines that run during the design flow. This does not remove the need for a final signoff check, but it greatly reduces the amount of time and potentially the number of licenses that a final check might consume.

Conclusion

The performance, power, and density advantages of the sub-25nm nodes will provide competitive advantages to those who adopt them. Although there are a number of design and manufacturing challenges, the good news is that the challenges are manageable – but only if we look beyond individual tools and rethink the ways that custom and analog circuits are designed.

What’s needed is a new custom/analog methodology in which schematic and layout designers work in close cooperation, schematic designers can run prototype layouts to gather parasitic and LDE information, and signoff- quality engines permit “in-design signoff” that catches the vast majority of errors before the final signoff phase. Cadence Design Systems fully supports such a methodology today.

About the author

Steve Carlson is marketing group director for silicon realization at Cadence Design Systems.

Contact

Cadence Design Systems
2655 Seely Avenue
San Jose, CA 95134

T: +1 (408) 943 1234
W: www.cadence.com