The growing use of ever-larger IP blocks reflects design engineering's desperate need to increase productivity and reduce risk as ASIC densities skyrocket. One issue poses a major obstacle to the widespread implementation and reuse of cores: No methodology has emerged as an industry standard for IP evaluation. Market analysts speak glowingly of system-on-a-chip (SOC) designs while third-party IP continues to grow by leaps and bounds. In this environment, a sound evaluation methodology is vital to assure the quality of IP generated by both independent developers and within internal corporate development groups.

How does an IP user assess the quality, interoperability, and reusability of a core? What key factors in an IP developer's methodology will give design teams a high degree of confidence in the reliability and manufacturability of the IP they plan to integrate into their design? And, how does the continual migration by ASIC manufacturers into deep-submicron process technologies affect a developer's decision to use hard or soft IP?

ASIC-like approach

One key indicator that an IP block will meet the goals its creators originally specified is evidence that it was designed using many of the same disciplines, rules, and methodologies typically employed by ASIC designers. In the ASIC design flow, it's widely accepted that the key to a bug-free implementation is an RTL coding style that takes into account the physical mapping later in the flow. Yet in many instances, IP developers today will supply simple RTL or gate-level interfaces and let the SOC designer or ASIC vendor determine not only how the technology will be mapped, but floorplanning, layout, and verification issues as well. Oftentimes, when designers attempt to lay out these devices, they feature weak code design with internally derived clocks and poorly designed clock structures. Inevitably these blocks lead to major problems at the layout stage.

Figure 1 - Vega information displayed

Graphical display illustrates RTL structure, while design issues can be traced through the hierarchy.

Given that the quality of the RTL code can have a profound impact on the success of a design, adherence to strict coding guidelines is the first step toward ensuring minimal problems later in the design flow. Accordingly, one key question to ask when evaluating an IP block is what kind of RTL-coding guidelines did the designers use? Did the original designer keep functional and physical hierarchies as similar as possible? Were modules designed to be easily testable? Were compilation units kept to a reasonable size? Were clocks brought out and back into the modules where they were generated? Was a consistent reset style used?

Designers at LSI Logic are expected to adhere to a broad array of RTL-coding guidelines covering areas of design including hierarchy, hierarchy connections, handling data-crossing clock domains, clock and reset signals, memory integration, logic depth, and high-fanout nets. To automate this task, designers use an internally-generated tool called Vega (VHDL/Verilog expertise and gate synthesis automation) to evaluate, early in the design cycle, an IP block's clock structure (see Figure 1). Vega tools read the gate-level netlist of the IP to extract critical design information. The gate level netlist may be a fast technology-independent mappingof the RTL code, or a fully synthesised netlist. A graphical display allows designers to comprehend the structure of the IP block and facilitates the process of tracing design issues through the hierarchy.

During its analysis, the Vega tools review the design hierarchy, clock, reset, and RAM write-enable sources, whether the hierarchy is pure or mixed, the presence of registered or non-registered module outputs, chip-level busses, registers of various types, high fanouts, and logic depth. As an example, company RTL-coding guidelines recommend keeping the functional hierarchy of a design pure. A functional unit should contain collections of other functional units or functionality, but not both. Otherwise, synthesis scripts, time budgeting, and the back annotation of custom wireload models becomes increasingly complicated. Vega tools generate a report, which outlines the hierarchical purity of each functional unit (see Figure 2).

Figure 2 - Crossing the great divide

Generating rules reports and synthesis scripts automatically assists in streamlining the IP evaluation process.

Design flow

As a natural extension of the ASIC domain, the design of an IP block should follow the same basic design flow traditionally employed by ASIC designers. Designers at LSI Logic have begun to use many of the same steps and checklists for IP as the company employs in its ASIC development (see Table).

Within the ASIC flow, the seven-step process begins with the design kick-off. At this stage, the initial design specification is written and reviewed. From there, designers begin writing RTL code using company guidelines and rules. Early development focuses on block-level RTL checks. Eventually designers move into an RTL verification stage, begin initial synthesis, and start floorplanning and placement efforts. There are also guidelines and rules for the synthesis scripts, floorplanning, and placement.

The second signoff occurs at the completion of the first netlist. The netlist is reviewed against existing guidelines and, once approved, work is begun on a trial layout. Stage three in the design flow looks at the completed trial layout and offers designers an opportunity to establish a floorplan and die size.

At that point, the design team runs final synthesis and the netlist is floorplanned and placed. The fourth signoff reviews placement timing, where timing margins and test vectors are examined and cell placement is frozen. The fifth signoff focuses on review of the final completed layout and gives designers an opportunity to re-examine integrity checks. Routing is frozen with timing closure.

Step six moves to the test phase and marks the release of the test program and prototype. In the last step of the process, designers give final approval of the prototype and customers grant final signoff and approval of the silicon.

The same flow is followed for the design of an IP block as for an ASIC, with the exception of the last two-signoff steps. These are modified to review the IP test plan and lead vehicle silicon rather than the ASIC test vectors and ASIC silicon in a normal ASIC flow.

Once a designer ensures that a particular IP block has been designed under rigorous RTL coding and synthesis guidelines, a close examination of four key issues can help determine how successfully and easily that block will into then integrate into the user's design.

Proven in silicon

One of the first questions to ask is: has the IP been debugged and proven in silicon or is it just a simulation? It's a given in the ASIC industry that errors and bugs are commonly uncovered in the design of a core in the first few times it's implemented in silicon. As design teams debug and refine it, however, the quality and predictability of a block increases dramatically. The higher the number of design-ins, the better the assumed quality of the IP block.

To gain a high level of confidence in an IP block, however, design teams should not only look for blocks which have been repeatedly implemented in silicon, but those which have also been used in highly similar applications. That principle is particularly important for larger, more complex blocks.

At the same time, the number of times a function block has been ported from one generation process technology to the next offers additional proof of concept. With each port of the technology, the RTL goes through another debug process and the scripts become more and more automated.

Distinguishing advantages

Hard cores offer a distinct advantage over so-called "soft" cores" in the area of process technology. As modules which have already been routed and proven in silicon, hard cores reduce the risk of project failure by giving designers excellent insight into the performance of the core. Many, in fact, are available as a stand-alone demo chip, allowing the use of a demonstration board to simplify software integration.

As ASIC manufacturers migrate down the technology process curve and delve deeper into the deep-submicron arena, this distinction will prove increasingly important. At these levels, wire loading dominates cell delay and performance becomes technology and layout dependent. As a result, teams pushing the limits of performance will face less risk when they design an ASIC with hard cores where timing is fixed. Using a hard core with a completed layout will also simplify the task of integrating multiple IP blocks.

Not only are clock, global, and critical nets closely controlled for capacitance and timing on a hard core, routing is also controlled to avoid crosstalk, metal migration, metal utilization, and metal-antenna effects. And since overall power drain and thermal effects are routinely monitored and controlled, the designer ends up with a robust core with excellent timing margins and physical characteristics.

In contrast, completing layout on a soft core is a challenging task in itself, let alone when critical timing paths and an optimal floorplan for the block are unknown, as is the case with third-party IP. As subtle layout effects play a larger role in the timing of the chip, any aspect of a design which reduces the complexity of that task will result in fewer problems and a higher likelihood of success.

Standards compliance

Standardization is the next key issue to examine. Is there an accepted industry standard for the function in question and, if so, does the IP core under examination comply with that standard? This issue is particularly relevant to designers using commodity interface functions. Perhaps the most common example is the PCI interface. Used extensively throughout a wide array of designs, a design team's decision to build or buy a PCI block off the shelf is most often driven by time-to-market issues. While purchasing a PCI block will theoretically save a team significant time in their development cycle, those timesavings are based on the assumption that the IP performing up to expectations. One way to guarantee performance is to ensure that the IP meets accepted industry standards for PCI compliance.

The second critical aspect of compliance a designer must examine is how many test suites have been applied to the block and is it compliant with system standards. While commonly used interface blocks such as PCI or USB may comply with industry standards, one school of thought says that there is no 100-percent proven PCI block. The sheer number of potential combinations of signals prohibits a supplier from making that guarantee. Instead, the designer has to ask how many test cases have been applied to this particular block to get a sense of its quality and completeness.

One indication of the importance of this issue is the fact that while some leading ASIC manufacturers prefer to build rather than buy their own PCI interface blocks, they will typically purchase their test suites to prove compliance from third-party IP suppliers. Why? Because over the years, those test suites have been developed and for so many different applications and for so many customers that they can offer more complete test coverage than any test suite developed by an in-house development group.

Test

Test strategy is the third key consideration in IP selection. Many designers decide not to address this issue until late in the design cycle. Yet is it very important that the designer ask what test methodology is employed in the IP block and whether it's compatible with the test methodology planned for the larger ASIC? For example, one test methodology may be relevant for an ASIC's core and another for its peripherals.

Figure 3 - Matching milestones to flow

Strategies for IP evaluation should be integrated into the design flow.

Most leading ASIC manufacturers argue that in today's deep-submicron SOC market, it's imperative that the IP supplier insert scan chains into the block to make testing of the IP - as well as the overall ASIC - as simple as possible. ASIC manufacturers typically rely on a test-bus architecture to give designers access to the IP on the outside of the chip, no matter where the IP is located. Coreware designed by LSI Logic includes full-scan capability. CPU cores such as MIPS use JTAG to give designers access to debug mode and visibility into what is happening inside the silicon.

Going forward, it's already apparent that next-generation solutions will demand even greater ASIC test automation. For most ASIC designs, that will require the addition of built-in self test (BIST) capability. LSI Logic offers RTL RAM BIST as standard on all RAM. The company is also in the process of adopting tools from Logic Vision to insert logic BIST in future IP, which will allow designers to generate on-board test vectors and capture and analyze those vectors on a block-by-block basis. As ASICs grow increasingly dense and complex and time spent on test escalates, ASIC-wide BIST, with its ability to offer designers comprehensive testing in a limited time and to run with higher speed clocks than conventional vectors, will look increasingly attractive.

Methodology is the final, crucial area of consideration, particularly as the variety of tool chains and design flows have proliferated (see Figure 3). Can the IP be integrated simply and easily into the design team's tool flow? Are all the views available for the tools the team wants to use?

This issue is particularly important for those design teams considering moving to a customer-owned type of tooling flow. If the IP under consideration doesn't support the views needed for the tools the team plans to use, the designers will have to spend considerable time and energy to generate the views they need. That, in turn, can dramatically slow the development cycle and threaten time-to-market schedules.

For those design teams relying on an ASIC vendor's tool flow, this task will likely be simplified. But even there, some ASIC vendors will limit their tool support or offer varied levels of tool support depending on the tools or design process used. Rather than let the IP user worry about mapping to the technology, floorplanning, layout and verification tools in the design flow, some ASIC vendors take a more flexible approach. They supply a fixed methodology during the IP-design phase and thereby generate easy to integrate and highly re-usable IP blocks.

One key characteristic to look for with an ASIC vendor is a methodology that includes not only information relating to the core, but also the multiple interfaces and shells which enable the designer to easily integrate the core with both the user's preferred tools and the rest of the design. As an example, many IP delivery mechanisms feature weak integration into floorplanning and layout tools. While this is often a complex task, it's crucial to ensuring time/delay budgeting information of the global wires between sub-modules into the synthesis tool. IP blocks that fail to meet this requirement often exhibit weak initial synthesis constraints.

One last thing

As designers come under increasing pressure to improve their productivity and meet aggressive time-to-market goals, they will turn to the integration and reuse of ever-larger blocks of logic. The ability to evaluate and quickly ascertain the quality and reliability of those blocks will play an increasingly important role in the success or failure of design projects. Clearly IP blocks which have been written under strict RTL coding and synthesis guidelines, which have been developed using many of the same disciplines and practices as those employed by ASIC designers, and which meet accepted industry requirements for test, standardization and methodology, will offer designers the greatest chance of design success.

Tim Daniels has worked for LSI Logic for eight years in the areas of applications engineering, tools support, and ASIC methodology. For the last three years, he has worked in technical marketing, concentrating on tools and methodology. Earlier in his career, Daniels designed ASICs for telecom and mobile radio applications with Plessey Defence and Marconi in the UK.

To voice an opinion on this or any other article in Integrated System Design, please e-mail your comments to sdean@cmp.com.