June 18, 1998

Multicore chips challenge system-on-chip designers

Jim Lipman, Technical Editor

Combining high-speed digital-logic cores, memory arrays, and analog blocks amplifies the problems of chip-design decisions concerning tasks such as on-chip buses, testability, and system placement and routing. Reviewing the difficulties of designing chips with multiple cores can help you overcome multicore chip-design hurdles.

Semiconductor processing of deep-submicron chips lets you do multimillion-gate system-on-chip (SOC) designs. The only way to efficiently design such logically dense chips is by embedding cores, also called "intellectual-property (IP) blocks" or "megacells," on these chips. Ideally, these cores should be reusable, meaning you can embed the same core on different chip designs.

As core-based chip complexity has grown, so have the problems of designing multicore chips. Many factors cause the obstacles chip designers face with multicore SOCs. Cores come from many sources, both from within a company and from third-party vendors, and may have different forms and different design styles. You may not have as much knowledge about internal-core details as you would like, making overall system design more difficult with these cores. Also, you may have to embed vastly different core types in one chip. Understanding the source of these and other design problems and how they affect your design strategies helps you overcome the hurdles of multicore design.

Multicores multiply problems

Designing chips using multiple IP blocks is difficult. However, the push toward true SOC logic densities coupled with decreasing design times requires the use of reusable, predesigned, and preverified cores for your chips. Design problems occur because the cores you use often differ widely from each other. Core differences result from a number of factors.

The actual form a core takes can vary. On one end, you have soft cores, which come in either an HDL, Verilog or VHDL, or as a netlist. Soft cores are flexible and portable; because they are not process-specific, you can use them on chips redesigned for process migration or for multiple sourcing of the same process. The drawback of soft cores is that their performance is not "solid"; implementing in different processes can result in performance variations. The other major type of core is a hard core, which has a fixed layout for a specific process or is available in netlist format with placement and routing information. Lacking soft-core flexibility, hard cores have well-known performance characteristics, including fixed cell placement and interconnections.

Another type of core, firm, has both hard- and soft-core attributes. These cores have some structure and topology to make performance more predictable. Firm cores have a range of representations, from floorplanned RTL blocks to a fully placed netlist. Because it is a compromise between a soft and a hard core, a firm core is more flexible and portable than a hard core but has better defined performance than a soft core. Soft, firm, and hard cores require different design methodologies. Mixing them on the same chip gives you more design problems than a chip using all the same type cores.

You can get IP blocks from ASIC vendors, EDA companies, third-party IP companies, or your own organization. Unfortunately, a standard to which cores must conform does not exist. This lack of a standard means that if you use externally supplied cores for your design, each core vendor's product may have different documentation, design style, testability, and so on. The Virtual Socket Initiative Alliance (VSIA, www.vsi.org) is working on the problem of common core deliverables to ease core mix-and-match designs, but the results of the alliance's work are only starting to emerge (see sidebar "VSIA and the multicore challenge").

Not surprisingly, chips with multiple cores are significantly denser in logic and functionality than single-chip or non-core-based designs (Figure 1). Increased density means larger chips, more power, and increased package complexity. In addition, as complexity increases, so does design time and design-verification difficulty.

One of the biggest problems you face when designing multicore chips is connecting the cores with a viable bus structure. On-chip buses must satisfy a different set of conditions than do board-level buses, such as PCI. Although you design both on-chip and board-level buses to reliably transfer data at a desired rate, you also design a board-level bus to minimize bus signals, because extra signals add packaging and pc-board cost. An on-chip bus takes silicon area, but this area usually has little or no effect on chip-package size or cost. An on-chip bus connecting IP blocks faces the problem of dealing with different interfaces on different blocks. This problem is far worse than the interface problem a board-level bus faces, because board-level components have more standardized interfaces than do chip cores.

Minimize delay and noise

Chip buses also must overcome data-rate problems. Pentium systems have boards that operate at 100 MHz. For the same system, portions of the chip with the CPU can operate as much as three times faster than the boards. Higher clock rates mean more difficult bus-design problems for minimizing delay and noise.

Many chip companies have developed proprietary bus architectures--a satisfactory approach for their own cores but not a solution to the mixed-and-matched core-bus problem. Palmchip and Sonics are working on the general SOC core-bus problem. Palmchip, for example, developed the CoreFrame on-chip bus architecture, which separates the bus into two parts, PalmBus and MBus (Figure 2). Separating the processor-to-peripheral I/O (PalmBus) and peripheral-to-memory DMA (MBus) functions lets the synthesizable CoreFrame provide as much as 264-Mbyte/sec bandwidth at 66 MHz and support 32-bit peripherals.

Sonics takes a different approach to the SOC-bus problem. The company's Integration Architecture uses a silicon backplane in a logic-backplane module to connect the various on-chip cores and then go off-chip to other system components (Figure 3). Integration Architecture uses module interfaces between the silicon backplane and the IP blocks, decoupling backplane performance from core performance. You can connect separate SOCs and other system chips, such as board-level memories, through each chip's silicon backplane to a single logic backplane. The silicon-backplane protocol controls addressing and data transfer between cores (Reference 1). The cost of implementing the Sonics Integration Architecture on your chip depends on the design, with some up-front costs and an additional expense in royalties from sales of your chip.

Multicore design-for-test issues

Core differences complicate how you test a chip using multiple cores (Reference 2). Depending on the logic a core uses, core testability may be either scan-based or BIST. Cores you get from an outside source or ones your company developed should come with a test suite and a specified degree of fault coverage. If a core's fault coverage core is too low, either the vendor must supply a test suite with higher coverage, or you must supplement the test suite yourself. Changing a third party's core test suite may be difficult, depending on how much information you have on the internal structure of that block. To protect investment in its IP, a vendor may give you little or no information about a core's insides (see sidebar "Protecting IP").

Even with adequate testability for each core, you still have to combine potentially different core-test methodologies into a unified test plan. The plan should also include memories and other structure blocks, such as datapaths. You usually base this test scheme on an 1149.1-compatible boundary-scan interface, which you then connect to external simulation or test equipment. No EDA tools exist that completely automate the integration of individual SOC core-DFT (design-for-test) logic into a unified test. However, some tools make the job easier for fully digital chips. Two of these tools are Duet Technologies' VisibleCores and Mentor Graphics' CTIntegrator (Reference 2).

Including analog cores in a mostly digital chip worsens the test problem. Analog blocks require different testability strategies and test equipment from those of digital blocks. One pioneering company in BIST technology, LogicVision, recently integrated its digital and analog chip- and board-level tools into one diagnostic test environment, icBIST 3.0 (Figure 4). The environment contains digital-logic, memory, and analog-block BIST tools, along with logic-scan tools. The DFT tool suite also includes legacy IP-core support, at-speed test of high-speed logic, and logic- and memory-BIST diagnostics.

You use icBIST for functional (not timing) testing of your chip. The tool produces Verilog or VHDL soft cores that reside on a chip, typically taking 2000 to 10,000 logic gates. These cores implement BIST logic for at-speed testing of digital-logic and memory blocks (SRAM, DRAM, and ROM), along with PLL and ADC analog blocks, all of which you can test with conventional digital-test equipment. The tool assembles the test blocks into a scan chain accessed with 1149.1 boundary scan. The icBIST tool also does at-speed testing of board-level SRAM and DRAM chips along with board-level interconnects. LogicVision offers icBIST 3.0 on a per-chip-design basis starting at $30,000. This price includes logic BIST, 1149.1 boundary scan, and full-scan automatic test-pattern generation but does not include any memory- or board-level test software. The cost for icBIST can increase substantially based on how extensive a set of tests and diagnostics you want.

When you develop software for an embedded block, you face the same problem that an engineer trying to test that block faces: core access. You need access not only to the core's I/O ports, but also to its internal nodes and registers via a detailed model. Because vendors often do not supply a core with these internal details (to protect IP), developing and testing software on an embedded core is difficult.

Mixed-signal considerations

Mixing analog and digital cores on a common chip means spending time to ensure that digital-core operation does not adversely affect analog blocks. The major problems you need to address with mixing both types of cores are crosstalk, ground noise, and thermal interaction.

Digital switching induces spurious signals into the analog circuitry, causing crosstalk. Switching high-speed and high-current digital logic causes the most crosstalk problems, so you should keep analog blocks away from these areas. This problem also means not having analog cores near clock lines and output buffers. You may have to also shield sensitive analog-block input lines during chip routing to reduce noise pickup to acceptable levels.

Ground noise is also a problem for analog circuitry. Digital switching may cause variations in signal ground, because of current variations during the switching cycle. Analog blocks are more sensitive to this problem than are digital blocks. Pay careful attention to your chip's power-grid design, widening ground lines and adding power and ground pins as necessary to keep ground noise below the problem level. Many mixed-signal designs even require a separate power grid for analog and digital circuitry, a placement-and-routing-tool capability you may need to have to do your design.

Analog circuits' susceptibility to thermal variations, which cause drift, is the third major problem with mixing analog and digital blocks on silicon. You need careful core placement to keep analog cores away from digital "hot spots" and to prevent thermal interaction that degrades chip performance.

Because of processing trade-offs, designers cannot simultaneously optimize analog and digital circuitry on the same chip. (Same-chip digital logic and some types of memory, such as DRAM, also require processing compromises.) Analog blocks require some processing features, such as multiple polysilicon layers, to maximize their performance. On multicore designs, vendors fabricate these analog blocks in a process geared toward high-performance digital logic. On a digital process, analog performance is worse than on a fully analog process, making your mixed analog/digital multicore-chip design even more difficult.

Physical implementation

Once you verify your design at the logic level, generating the physical layout brings on a new set of problems. Difficulties with core placement, chip routing, and timing verification all increase with multicore chips.

Deciding where to place your cores becomes harder as the number of cores increases, particularly if you need to mix analog and digital cores on a chip. The most common place-and-route tools, Cadence's Silicon Ensemble and Avant!'s Aquarius, have timing-driven place-and-route features but lack signal-integrity constraint-driven placement and routing (Reference 3). Avant!'s new Apollo place-and-route tool has noise-driven features but has not been available long enough for much evaluation.

Core porosity, the ability to route through a hard core, is another potential problem area. Dense, hard blocks, such as embedded memories, and analog blocks pose serious obstacles to chip routers. The routing tool has to route around the block, adding interconnect length and parasitic delay and potentially generating noise. Other digital cores have varying degrees of routing blockages, depending on the logic they contain. If you obtain hard cores from a vendor, make sure you get information that helps your placement-and-routing tool to route through the core.

The timing models that place-and-route tools use can also cause problems if they are inconsistent with other design tools, particularly those for digital-core logic synthesis. Inconsistent timing models in synthesis and place-and-route tools may result in excessive iterations from synthesis to placement and routing to timing verification with back-annotated parasitics from the physical layout. It is important that your place-and-route tool and synthesis tool produce consistent timing-constraint-driven results; otherwise, you waste valuable design time with unnecessary iterations between the two design tasks.

Off-chip problems

Chip complexity and the presence of analog or mixed-signal blocks complicate your choice of chip package and analysis of that package. More on-chip functionality usually translates to more package pins, a trend that is leading package developers to BGA and flip-chip technology with more than 1000 I/O pins and as many as 2000 total package pins (Reference 4). High-pin-count packages complicate pc-board design; as chip connections go up, board designers have to deal with more complex routing to the chip package and, possibly, additional board layers to handle the routing complexity.

Complicated on-chip clocking and interactions between analog and digital cores on some multicore chips require a thorough analysis of package parasitics and their effect on chip performance. EDA tools for designing complex, high-pin-count packages, such as Encore BGA from Xynetix, are useful but carry a hefty price tag. Encore BGA sells for $50,000, and a recently announced autorouting option, the Interconnect Compiler, adds $20,000 to this cost. Another tool for any-angle BGA autorouting is Zuken-Redac's new Route Editor 9.0, which works with the company's Visula pc-board/multichip-module-layout software. Route Editor comes with or without high-speed-route capability. The price of the editor starts at $14,960, and Visula costs $22,500.

Accurate thermal design and analysis is important in two ways. First, very-logic-dense chips operating at high speed generate as much as 50W of power. Dissipating this power burdens the system designer. On a silicon level, chips combining analog and digital blocks require more core-level on-chip power analysis. This analysis ensures that blocks dissipating relatively large amounts of power are not close to sensitive analog blocks. Many EDA vendors offer power-analysis tools at the RTL, gate level, and physical level that you can use to verify that chip power and thermal interaction between blocks are within acceptable levels.

References

1. Wingard, D, and A Kurosawa, "Integration Architecture for System-on-a-Chip Design," 1998 Custom Integrated Circuit Conference Proceedings, May 11 to 14, pg 85.
2. Lipman, Jim, "Add testability now to core-based chips, or pay later," EDN, Feb 16, 1998, pg 65.
3. Lipman, Jim, "Chip place-and-route tools lay it on the line," EDN, March 26, 1998, pg 71.
4. Lipman, Jim, "New IC packages really pack in the leads," EDN, Sept 1, 1997, pg 93.

Acknowledgments

I want to thank Jeff Hilbert of LSI Logic (www.lsilogic.com), JC Parker and Tony Parker of Lucent Technologies (www.lucent.com/micro), Hary Iosub and Paul McAlinden of Motorola (www.motorola.com/wireless-semi), Alex Goldstein and Michael Tran of NEC Electronics (www.nec.com), Farzad Zarrinfar and Heon-Joon Kim of Samsung Americas (www.sec.samsung.com), Bob Payne of VLSI Technology (www.vlsi.com), and Larry Rosenberg of the VSIA (www.vsi.org) for their expertise on and insight into the problems that multicore-chip designers face.

VSIA and the multicore challenge

Doug Fairbairn, president, VSIA

The Virtual Socket Initiative Alliance (VSIA, www.vsi.org) tackles the multicore, system-on-chip design challenge. This challenge involves importing, understanding, integrating, verifying, and testing a set of complex virtual components (VCs), which is IC-hardware intellectual property (IP). Without a set of standards that brings order to this problem, it becomes overwhelming.

The first thing a designer finds is that the format and completeness of information that come with VCs vary widely. In response, VSIA has published an architecture specification that identifies the minimum and preferred set of deliverables for a VC (Table A). This architecture specification clearly points out the documentation, simulation models, design data, and other supporting material a VC provider should supply to minimize the challenge of VC selection and integration.

As a next step, VSIA plans to release this month a set of specifications that takes this standardization effort much further by specifying the format of these deliverables. These first specifications address hard VCs and analog blocks for integration in largely digital chips. Vendors sell hard VCs in the form of physical layouts, or hard cores. You usually use these VCs for high-performance, high-value blocks, such as mPs.

This year, VSIA will publish initial specifications dealing with on-chip buses, test, and system-level design. The first step is to release these specifications to VSIA members for their review and then to make the specifications available to the public after internal review and even implementation of pilot programs, as necessary. Complementing these design-related specifications is a document describing the optimum methods available for IP protection--a problem for which one perfect solution does not exist.

VSIA is on track to deliver a set of specifications that significantly eases the tasks associated with using IP blocks, whether from internal sources or third parties. In addition, others in the industry are making good progress on related issues, such as VC directory services and business models.

Protecting IP

A major problem with intellectual-property (IP) blocks is how to protect them from unlicensed use. Unfortunately, the higher the level of protection, the more difficult it is for a legitimate designer to get core details, which are necessary for a good design. Larry Rosenberg, Technical Committee chairman for the Virtual Socket Initiative Alliance (VSIA), breaks IP-block protection into three categories: watermarking, encryption, and deterrent. Watermarking an IP block is useful for detecting IP theft but does not directly help prevent theft. Various types of watermarking are currently available; Reference 1 describes one unique watermarking method under development. Deterrents against IP theft are still evolving, according to Rosenberg. Legal ramifications for IP theft are poorly defined.

The most widely known IP-block-protection method is model protection with encryption or secure-model generation (Reference 2). Limitations of secure-model generation are that it is best suited for soft-core models, generally in Verilog or VHDL RTL code, and that it is most useful for IP export, from a vendor to a licensee.

Steve Carlson, marketing vice president of Escalade, points out that encryption and compilation, two techniques for soft-core protection, are not quite the same. True encryption is a reversible process; with correct decryption, you can recover the original source code. Compilation is irreversible, making it almost impossible to recover source code after someone has compiled it. Topdown Design Solutions, Summit Design, Escalade, and Synopsys offer products that protect core models with model-source-code compilation and let designers simulate the protected models.

Topdown's TopProtect works with either VHDL or Verilog models, compiling the models into binary native-code object models that run on Unix-based simulators. TopProtect-generated models interface to each simulator with a Verilog or VHDL "wrapper" that goes with the binary model. You can currently get wrappers and associated model managers for Cadence's Verilog-XL and NC-Verilog; Mentor Graphics' ModelSim, and Synopsys' VCS simulators. Prices for the basic tool starts at $80,000, but additional per-model and other software costs bring the total to $200,000 to $250,000.

Summit targets Visual IP (VIP) at core creators and silicon vendors. The product creates and distributes protected IP models and related documentation. It includes an IP Model Compiler to create Visual IP models and an IP Model Manager that reads and simulates the models. The VIP model is a binary file of the HDL model, data-sheet specifications, simulation vectors, and other simulation data. Model Manager, which has an embedded simulator and links to third-party simulators, decodes the VIP model. VIP also works with VHDL and Verilog. The software supports Mentor's ModelSim, Cadence's Leapfrog and Verilog-XL, and Synopsys' VCS and VSS simulators. VIP runs under Windows NT/95 or Unix with prices starting at $100,000.

IP Guard, Escalade's new entry into the model-protection arena, works with C, Verilog, and VHDL models. Using proprietary compilation, IP Guard optimizes and reduces the model, using irreversible operations, into a Verilog- or VHDL-simulatable model. You can put timing diagnostics, such as checks for setup-and-hold, state-dependent delays, and transition-dependent outputs, into the protected model. Escalade also adds debugging features, including internal-register viewing, instruction tracing, and check pointing, to help verify the models. IP Guard runs on Unix and Windows platforms and has a starting price of $224,000, bundled with 40 hours consulting time and three copies of DesignBook, Escalade's integrated design-entry, analysis, and implementation tool suite.

VMC (Verilog Model Compiler) is the oldest of the four secure-model-generation tools. Chronologic, a Viewlogic company, developed VMC, but Synopsys now sells it. VMC compiles Verilog code into a binary object file that you can simulate with Synopsys' VCS simulator or any other Verilog simulator that supports the Open Verilog International programming-language interface. A VMC license costs $250,000, but for $30,000 per model Synopsys creates the VMC models for you. Synopsys also recently announced its Desktop ModelFactory product for core-model creation. The tool creates either C or, using VMC, Verilog models that, with a special interface, run on a range of simulators. Desktop ModelFactory is also available as a model-creation service for $30,000 per model.

References A

1. Charbon, E, "Hierarchical fingerprinting in IC design," 1998 Custom Integrated Circuit Conference Proceedings, May 11 to 14, pg 295.
2. Carlson, Steve, "Protected design simulation models," Escalade Corp, May 1988.

Jim Lipman, Technical Editor

You can reach Jim Lipman at 1-925-606- 370, fax 1-925-606-1563, ednlipman@mcimail.com.

| EDN Access | Feedback | Table of Contents |

Copyright © 1998 EDN Magazine, EDN Access. EDN is a registered trademark of Reed Properties Inc, used under license. EDN is published by Cahners Business Information, a unit of Reed Elsevier Inc.