SOCs: IP is the new abstraction

Reusable IP, not system-level language, has become the new level of abstraction.

Ron Wilson, Editor-at-Large -- EDN, August 11, 2011

“Reusable IP [intellectual property] is the new level of abstraction,” says Ajoy Bose, chairman, president, and chief executive officer of Atrenta. If you examine what SOC-design teams are doing, you’ll find that creating an SOC is a process of finding, characterizing, and assembling previously used IP. Design-creation tools, whether SystemC, Verilog, or schematics, find a role only in filling in the blanks—the proprietary functions and connective tissue of the IC. But today’s design flows, as broad-spectrum-EDA companies, the foundries, and most SOC designers conceive them, have been slow to recognize this reality. Look at your tools, and you would think that every SOC begins with a set of functional requirements and a clean sheet of paper. Instead, consider what really goes on in an SOC design and what conclusions you can extract from these observations.

The new abstraction

Synopsys Chairman and Chief Executive Officer Aart de Geus likes Legos. At least, he likes to use them as an analogy for silicon IP. He points out that fitting together IP to create an SOC has its similarities to fitting together Lego blocks to build a toy. IP blocks are abstractions of the RTL inside them, just as Lego blocks are far simpler than crafting a spaceship or a dinosaur from wood or plastic. You can run a long way with the analogy before it begins to break down.


Moving down the design flow, the two approaches continue to diverge. Through functional verification; synthesis; analysis; detailed clock, power, and test insertion; back-end design; and closure, the traditional flow continuously removes abstraction, creating more implementation detail until the requirements have become layers of polygons. At each new level, the flow stops to verify that the design still meets the requirements.

The IP-centric flow, again, is nearly the opposite. The point is to assemble the IP into a system that meets the requirements and uncovers as little new information about the IP’s entrails as possible. “Don’t get stuck debugging the IP during the assembly process,” says Bose.

That scenario is the ideal and, for many teams, attractive. “In China, for example, methodology is about how quickly you can go from definition to IP list to assembly,” says de Geus.

That situation is often not the reality, however. “At least some functions today are so well-defined that you could in principle treat them as black boxes all through the flow, but I have yet to see it,” says Taher Madraswala, vice president of engineering at Open-Silicon. “In reality, you end up taking apart your black boxes in synthesis and gate-level optimization.” To address these issues, you must walk through an ideal design flow, discovering the gaps between vision and reality. You must consider IP selection, assembly, implementation, and closure.

IP selection

The move from requirements to an IP BOM (bill of materials) is variable and, unfortunately, manual. How you get from A to B depends on the nature of the system, the availability of IP, the design team’s experience with reuse, marketing’s plans for differentiating the chip, and corporate policies, among other things. The one thing the process does not depend on is automation. Synopsys’ de Geus points out that, in principle, there should be no barrier to automation.

At RTL, he observes, Design Compiler effectively infers relatively complex blocks of the company’s DesignWare from the Verilog source. For larger IP blocks, however, automation is uneven. “With IP, the blocks are less generic, and more human selection is involved,” he says.

In some cases, manual IP selection can approach the ease of an automated tool. For example, many smaller SOCs still adhere to a simple, microcontroller-like architecture: a CPU core, a local cache, and a collection of peripheral interfaces. All the blocks you need are often available from third-party IP libraries, complete with AMBA (advanced-microcontroller-bus-architecture)-interface pins, ready to plug together. In other cases, the choice of IP is not obvious from the requirements. Say, for example, that your smartphone SOC has several authentication and encryption requirements. Do you license a large and expensive third-party cryptographic engine or choose a smaller cryptographically oriented datapath coprocessor? Alternatively, do you develop your own block in The MathWorks’ Matlab and synthesize it, or do you get a faster—or a second—CPU core and handle the requirements in software?

Choosing a function does not end the process. Functionally similar blocks can differ in many ways, including performance, area, power, interface requirements, configurability, provisions for clock and power controls, verification coverage, and use history. Much of this information should be on the IP block’s data sheet, but some may require interrogating previous users of the block or even a bit of reverse-engineering.

The logical problem of inferring a complex IP block from an executable SOC-requirements file is probably solvable. Most requirements documents are still in human languages, not executable form, however. Further, most of the supporting information necessary for selecting a piece of IP is scattered, lacks standard formats, and may be proprietary. Clearly, automating IP selection requires a lot of work.

One intriguing, largely unexplored possibility exists. You normally think of formal verification as involving verification tools. The ability to formally test the truth of a property has applications outside traditional verification, however, according to Oz Levia, vice president of marketing and business development at Jasper Design Automation. For example, designers can use Jasper’s ActiveDesign to explore RTL during development, helping to steer RTL-code creation. Extending this idea, Levia describes how Jasper and ARM engineers teamed to manually convert the English-language specification for ARM’s memory-coherency protocol into an executable spec, from which Jasper synthesized a set of assertions. In principle, a design team could use this process to create a set of assertions from requirements and then use a formal tool to investigate how nearly an IP block fits the requirements. Programmable or configurable IP would create challenges, but the procedure might at least generate a statement of work for fitting a block of IP into a design.

Assembly

IP assembly is the essence of the IP-centric flow. Some designers use the word “assembly” instead of “integration” to make an important distinction. The ideal at this stage is to treat the IP blocks as configurable black boxes, writing only the RTL that is necessary to glue the boxes together after you have configured them. This situation differs greatly from the increasing exploration of the blocks that the word “integration” implies.

The ideal assembly process necessarily begins with system-level simulation. In another sense, system simulation is the verification phase of IP selection; you are proving that the pieces you selected can come together in a way that will meet the system requirements. “In an IP-assembly flow, system verification and validation get massively more emphasis,” says de Geus. “Often, you need a rapid prototype just to prove that the software will run on the chip.”

The importance of rapid prototyping implies that transaction-level models of IP blocks can be valuable. But the IP vendor sometimes doesn’t have transaction-level models, or the models are no longer correct for the current version of the IP. You can nearly always use the soft IP’s RTL source, though, to create an FPGA-based rapid prototype—hence the importance of FPGA prototyping to IP-centric design.

You can also make other early assessments during assembly. Static analyzers can check the IP for rules violations and best-practices compliance. Estimators can often come reasonably close on power, performance, and area of the finished chip. “Today, there is more uncertainty about the results using high-level synthesis than using soft IP,” says Atrenta’s Bose.

In an ideal world, once you have put the blocks together in the prototype, verified the behavior of the system, and explored its probable characteristics, the only verification you would need to do would be of the connective tissue between the existing blocks and of the new blocks. But different situations approach this ideal to differing degrees.

Perhaps the closest approach to ideal is when the IP, the interconnect, and the IC implementation all come from one source (Figure 1). For one example of this situation, see sidebar “An FPGA view.” This good fortune does occur in real life, but only in vertically integrated companies with strong design-reuse cultures, such as IBM, parts of STMicroelectronics, several of the major Japanese companies, and both NXP and Freescale before private-equity ownership refocused their priorities. Without both a strong corporate reuse culture and firm control over the IP-development process, it is difficult to get close to a pure black-box assembly flow. “People still tend to lag on the little bit of extra work necessary to enable reuse,” says Bose, who states that Japan’s STARC (Semiconductor Technology Academic Research Center) produced an excellent reuse manual. Some teams that develop IP lack both the discipline and the management support to make their design reusable at this level, however.

The next closest to an ideal environment is one in which an industry standard, such as AMBA, defines all the interconnect between the blocks, and all the IP complies with the standard (Figure 2). In this case, assembly is a matter of making sure signal names and polarities agree and that all the interfaces can operate at the desired frequencies. Without a unifying bus standard, things get more complex. You have to understand the interfaces on the instances of configured IP blocks and, if necessary, create additional RTL glue to execute transactions between the blocks, and you must verify all of this work.

The art, according to Open-Silicon’s Madraswala, is to find a way to verify the interactions without verifying all the internals of the IP. “You can exploit the fact that the IP has been used before,” he says. “You look at your schedule and determine where you want to spend your verification time. You might write assertions or tests to verify the logical integration requirements in the IP data sheet, rather than doing a full verification plan. But experience is vital in knowing what you do and don’t have to check.” This verification approach relies heavily on simulation rather than formal tools, Madraswala adds.

Implementation

At this point, the IP-centric design flow begins to reconverge with tradition. Soft IP blocks, new blocks, and interconnect all go through synthesis and on to scan insertion, place, and route. Hard IP also enters the flow for placement and routing. The team then closes the design. In some respects, however, the IP-centric design remains distinct.

One difference, Madraswala says, is the approach to power management. “Tuning the design for power management is becoming a separate phase of the design flow,” he says. “It is becoming its own art and science.” Madraswala explains that, when you’ve designed a block yourself, you can use synthesis switches for reregistering to ease timing; for fine-grained clock gating; and for other netlist-level-optimization techniques, most of which benefit power consumption.

Other tools can, for example, alter clock skews to manage peak clock currents. You can do some of this work with synthesis switches, but engineers still manually perform some of these tasks, according to Tobias Bjerregaard, chief executive officer at Teklatech. All of these techniques can be valuable, but it may not be wise to use them all with third-party IP.

“We may not have the original source code, so we can’t do equivalence checks,” says Madraswala. “Often, we don’t have the right to change the design of the block.” The question of how much optimization a licensee can do before violating the terms of the warranty on an IP block is difficult.

Synopsys’ de Geus is also skeptical about relying on equivalence checkers—for a different reason. “The formal tools are constantly chasing what synthesis can generate,” he says. “For instance, the synthesis tools can do delay borrowing, but the formal equivalence checkers may not see the reorganized circuit as equivalent to the original.”

Consequently, Open-Silicon’s Madraswala suggests applying clock and power gating to IP at the block level. “We put a wrapper around the code and make it behave the way we want it to,” he explains. This approach avoids modifying the third-party code. Physical design, Madraswala says, remains traditional. Hard-IP blocks join the flow for placement and routing, relying on the vendor’s integration guidelines. The company runs a DRC [design-rule check] on the block to ensure that it complies with the current rule deck and performs a visual review of the integration with the vendor, according to Madraswala. “Sometimes, there are guidelines that they haven’t written down,” he says. Open-Silicon follows this process with a DRC of the flattened design, but Madraswala claims that no problems exist 99% of the time.

The back-end flow benefits relatively little from IP-based design. Except for FPGA designs, you cannot ignore DRC, extraction or timing, signal-integrity, and power-integrity closures. Too much art and too many details, such as different constraints, power-management strategies, and approaches to DFT (design for test), remain in these areas. These differences may show up only in the integrated chip. Yet, the ideal of an IP-centric design flow—selecting and snapping together blocks, verifying the interconnect, and pushing a button to get a finished design—remains.

Such a flow would require great discipline from IP designers. “The genius of Legos was only half in thinking of the plugs and sockets,” says de Geus. “The other half was figuring out how to maintain the very tight tolerances so that the plugs and sockets would work over and over again, without jamming or loosening up.” And so it is with further automation of the IP-centric flow: The gating achievement may be increasing standardization and craft in the creation of the IP.

You can reach Editor-at-Large Ron Wilson at 1-415-947-6317 and ron.wilson@ubm.com.

---

For More Information
ARM	Atrenta	Freescale Semiconductor
IBM	Jasper Design Automation	Lego
MathWorks	Microsemi Corp	NXP Semiconductors
Open-Silicon	STMicroelectronics	Synopsys
Teklatech

---