SoCs: Design tools -> Smooth interfaces ease IP-to-IP talk

However, hardware IP can be very complex. Often it must be controlled by software running on an embedded microprocessor or DSP core. Usually it has to communicate with other parts of the chip and the processor. And this is where design reuse gets really challenging.

For most companies, design reuse is still a goal, not a reality. A lot of reasons have been given for why this is so hard to achieve and all of them are valid. Culture and documentation have been blamed. Quality assurance and support are big concerns.

Organizations can reorganize around design reuse. For one thing, manage rs can insist that all reusable code be carefully documented. For another, IP providers can improve their quality control. Yet many more things can happen and reuse will still be a problem. Why? Because of the way most IP is written.

Most is written with certain assumptions about the basic chip and system architecture. The most critical assumptions have to do with the interfaces to the other parts of the chip and the software running on the microprocessor core.

Let's look first at the most obvious solution proposed for on-chip hardware communication challenges. A few years ago, some people asked, "Why doesn't everybody use the same bus?" Some work even went into determining the "perfect" bus. It didn't take long for almost everyone involved to realize that there's no one size fits all when it comes to interface design, and providing a wide variety of buses creates clear challenges for such design. As a matter of fact, the interchip bus design can make a tremendous difference in the chip's per formance of the chip, and no design team is going to give up anything to do with getting more performance.

There are some basic concerns that every engineer faces when trying to integrate IP from a variety of sources or when trying to design IP for a variety of uses.

From an IP integration point of view, a system-on-chip (SoC) design is typically so complex that multiple buses with very different characteristics are required to accommodate the different bandwidth requirements of the various parts of the SoC. Finding the right number of buses and types of buses, deciding on arbitration and interrupt priorities and optimizing the size of communication buffers have become important differentiators and can have a major impact on the performance of the system. Interfacing an IP block with a compatible standard bus obviously is simple. However, if the system requires another type of bus, or two IP blocks with different built-in standard buses must be interfaced, then the integration interface can become unnecessarily complicated-that is, an overdesigned interface.

Generic bus

From an IP design point of view, the IP can be designed with a built-in standard bus, which typically is generic and therefore complex, or the IP can be designed with a custom bus based on the requirements of the IP itself, which is the simplest bus. Because of its complexity, a standard bus can negatively influence the performance of the IP and complicate its reuse and design.

To make an IP block compliant with a standard bus, it is essential to make sure that all bus transactions are supported. As a consequence, IP blocks with simple interface requirements must support complex burst and split bus transactions-that is, the IP interface is overdesigned.

A good example of interface overdesign is a peripheral slave device that requires only a medium-to-low-speed interface with simple read and write transactions. Another is a digital-signal-processing hardware block that communicates using ultrahigh-speed point-to-point buses with only one simple transaction type.

A good example of where standard buses can affect the performance of the IP is processors. Processors have complex pipelined, multimaster, multislave high-speed buses that often support split and burst transactions with the memory subsystem. The timing diagram and transactions of these buses are optimized for fast accesses to the memory subsystem in order to maximize the processor's overall performance. Designing a processor toward a fixed standard bus can have a major impact on the processor's performance.

Different processors have different bus architectures. Even different divisions within the same company will use slightly different bus architectures, even with the same type of processor. This problem has been addressed by Motorola Inc. Early this year, Motorola's Semiconductor Products Sector posted four proprietary reuse standards on its Web site: an IP interface standard and IP and virtual component block deliv erables guideline, a Verilog HDL coding standard and a documentation standard. The IP interface standard covers the interblock communication needed for SoC design, including interfaces for interprocessor, system and peripheral buses.

This is certainly a step in the right direction. However, if every company develops its own proprietary reuse standards design will really be challenging. Therefore the standards committees are at work, defining standards that everyone can adopt. Meanwhile, we're in a chicken and egg situation.

From this discussion it can be concluded that, in most cases, it is best to simplify the IP interface to the bare minimum, which is what the CoWare N2C Virtual Bus allows designers to do. This simplifies the design of the IP and the reuse of the IP. By using the virtual bus, designers can automate the reuse of the IP using interface synthesis to automatically generate the appropriate interfaces.

Currently, the design of the hardware/software interfaces is an incre asingly complex manual task. The possible hardware/software information exchanges include software writing to hardware configuration registers, software reading status and counter registers, and the hardware notifying the software about events by means of interrupts.

The design of the interfaces is complicated by the organization of most design teams, where often the hardware and software teams report to different management teams within a company and work in separate buildings. Often, members of the hardware team never meet face-to-face with their software opposite numbers. Imagine what happens when the system specification changes. What assurance does management have that any of those changes are communicated to all team members? What if somebody on the hardware team is not notified about changes to the system specification?

An additional challenge lies in communication between the software and hardware teams. They use different vocabularies to describe the interfaces. The hardware team des igns with clocks, timing diagrams and bus transactions; the software team only cares about tasks and high-level device drivers or memory-mapped variables and interrupt service routines.

The answer to that organizational problem is to begin with an unambiguous and executable system specification that includes an abstract hardware/software interface description. Make everyone design hardware or software independent of the exact interface and use Interface Synthesis to implement, from the unambiguous description, the actual hardware and software interfaces. Then if a hardware block or some software code needs to be changed or reused, it can be done easily because it is designed properly, without the interfaces.

There's a bonus to designing IP correctly in the first place. With Interface Synthesis, IP can be designed to work with a variety of microprocessors without having to read and interpret the 500-page manuals for each microprocessor that describe such interface elements as booth code, ISR and memory-mapped I/O. The time savings are enormous, and the quality of the interfaces is greatly improved.

A very good first step is to make sure the interfaces are separated from the design of IP blocks. Taking that a step further, the question arises: Isn't interface design a tedious, time-consuming, unimaginative task? It's one of those jobs that no one notices when it's done right, but if one little thing isn't perfect everyone notices it, and the SoC doesn't function properly.

Next step

Interface Synthesis, a technology CoWare pioneered with its introduction of the CoWare N2C hardware/software codesign tool and methodology, is the next step forward. Interface Synthesis automatically implements the appropriate interface logic or software between different system functions. The synthesized components include address decoding, interrupt priority encoding, arbitration units, memory-mapped registers, program and data memory, interrupt service routines, boot code, and methods for accessing memory-mapped registers.

Interface Synthesis simplifies the process of assessing and selecting the optimal IP for an application. Designers are able to introduce IP components without having to handcraft the interface logic required to build a new simulation model of the entire system.

With Interface Synthesis, the interface between the IP block and the target processor or system bus can be designed without any detailed knowledge of the processor or bus specification, protocols, timing diagrams, memory map and interrupt vectors. Instead, the designer specifies how the IP block interfaces to a much more abstract virtual bus.

Designing IP correctly by separating the behavior from the interfaces is the next step forward in design productivity.