Programmatic interface generation simplifies software integration

The growing number of SOC (system-on-chip) developments has highlighted for many systems companies the problems associated with parallel development of hardware and software. Well-understood hardware- and software-development programs may exist happily in isolation, but bringing them together in a successful SOC development that is first-time functional and enters the market when planned is proving to be a challenge.

A solution to these difficulties exists, one that is allowing design teams to report huge savings in system-integration time by enabling concurrent hardware development, software development, and system documentation and testing. By capturing project data in a structured database, all developments can continue in isolation with confidence that the entire design team is working with appropriate yet consistent design files. The approach also ensures the ability to make late changes or fix original specification errors consistently across the development team.

A product development, once a company's marketing department blesses it, typically ends up in the hands of a system architect. After analyzing the product requirements and examining architectures to fulfill these requirements, the main outcome will be a split between the functions a design can achieve in hardware and those that a developer programs in software. At this point, the separate hardware- and software-development groups take over their respective tasks: to create and resource project plans and eventually produce their contribution to the overall product. At the end of this stage, the two developments reunite in the system-integration phase, and the company prepares to release the final product. The documentation team is waiting in the wings to ensure that its contribution to the overall product will be in place, ready for that all-important launch date.

Unfortunately, experience reveals many opportunities for information misinterpretation or miscommunication in this seemingly simple process. On large, complex projects, changes often occur during development; for example, marketing might request a new feature, or the development process might reveal a different and more ideal hardware-versus-software split, or the design may require new IP (intellectual-property) blocks. Any of these changes impacts the entire development team; hence, reliable communication of the changes to all affected parties is essential.

The later such changes occur in the development process, the bigger the potential impact becomes. Delays in discovering misinterpretations incur ever-increasing financial penalties. Discovering a design error after the tape-out of a complex SOC can result in additional NRE (nonrecurring-engineering) charges on the order of $1 million. Even worse, discovering a problem in a released product can result in a damaging product-recall cycle. Automatically generating views for software developers, hardware developers, and documentation teams from a central database they created during the architectural definition phase of the program ensures that all parts of the development team work with consistent and up-to-date specifications. Adopting such a process can result in huge savings in engineering efforts.

In a typical architecture of the hardware portion of a project, an embedded processor executes software that controls the system setup and operation (Figure 1). The processor's view of the system takes the form of a series of interface points in its address space. These interface points correspond to registers within each of the IP blocks and usually take the form of memory-mapped registers—connected to the microprocessor via the system bus. A complex SOC often comprises multiple processors, DSP cores, or both. These cores may share a common bus, or the chip may contain a more intricate bus bridge for sharing data.

Regardless of how complex the system becomes, the processor cores' interface to it—that is, its memory-mapped registers—is an unchanging presence. Writable registers control the function of and transfer data to the IP block, whereas readable registers monitor status and transfer data from the IP block. For complex SOCs, register counts often run into the thousands on a single device.

Hardware and software developers can work happily in isolation. For example, early software development can proceed by simply modeling the address space; the development does not require the IP-core logic. For hardware developers, the major task to perform is creating the core-logic function; the register block and bus interface are comparatively simple tasks. But one commonly ignored function remains: the one that joins the hardware and software worlds.

By using a common description of the registers between hardware and software, development teams can ensure that, as the design of an IP block matures, the detailed hardware model can replace the simple register model and that they can easily rerun software tests. A common description also ensures no surprises upon hardware and software integration in latter development stages. Even more important, automating the creation of these low-level functions on both the hardware and the software sides allows valuable engineering resources to concentrate on adding value to the product.

A typical IP-block architecture breaks down into the bus-interface logic, which the bus structure the device uses defines; a register block, which is memory-mapped into the processor-address space; and the IP-core logic, which determines the block function (Figure 2). The register block of each IP block must supply valid status information to the processor via readable registers and supply valid control information to the IP-core logic via writable registers.

Access to the IPE (IP-emulation) registers can come from an embedded system bus, wherein test code integrates with the program code or from a separate system bus that you can then link into other models or components to create a test-and-verification environment. Whichever approach you choose, you can automatically create all of the necessary views from the same database that has sourced the generation of the low-level hardware- and software-interface code, thus maintaining consistency between design and test.

From a central database describing the hardware-to-software interface, you can generate all the aspects of the IP and IPE blocks. These aspects are an RTL description of the bus-interface and register-block portions of the IP block, an RTL description of the bus-interface and register-mirror portions of the IPE block, the system IPE block, and a reference manual that describes the software-to-hardware interface for each IP block in a system.

Because all these views automatically come from a common source, their consistency is guaranteed. This fact ensures correct communication of changes to hardware, software, and documentation teams. Having all views created as soon as the system architecture is fixed also ensures concurrence of all development activities. For example, the software-development team need not wait for hardware development to mature to a certain point before the team can begin to make meaningful progress.

Adding a means of updating register values can help create a more rigorous testing environment for the software. Developers can achieve this objective by adding to the model an IPE block containing a register block that mirrors the behavior of the IP's register block (Figure 3). Each readable register in the IP block matches with a writable register in the IPE block and vice versa. Under processor control, the mirror registers monitor the status of the IP-block registers and update the status registers to prove the behavior of the embedded software.

In addition to generating the processor interface, the same saved data can generate a number of other models that assist in building hardware- and software-test environments. These models can take the form of testbenches for hardware developers or macros and functions for software developers. These models could include a set of software-access functions used to access the register-block portion of the IP block, a set of software-access functions to access the register-mirror portion of the IPE block, a bus-emulation model to exercise the hardware models, and a function-reference manual describing all of the software-access functions. Such tests prove whether the register is read-only, meaning that a write operation does not destroy them; whether the power-on-reset and software-reset values for the register are correct; whether the register map for the design is truly exclusive; and whether the address decode is correct.

Although such tests are a good first step in software development, a design will eventually require more rigorous testing. At that point, the IPE models will come into their own (Figure 4). In this example, the IPE access bus is separate from the actual system bus so that you can isolate the development and compilation of embedded software and test software from each other. Using this type of architecture, software developers can begin testing their embedded software using behavioral models of the IP blocks running as the verification engine. They can progress from developing low-level or driver code to proving the application software that is a key part of the product.

As product development continues and as the design of the actual IP blocks matures, you can replace this structure with simulation models of the hardware design—for example, through a PLI (programming-language-interface)-type link to a simulator—or even with hardware, using programmable-logic devices. You'll now fully experience the benefits of co-development. Because the hardware and software designers have both started their development from a common database description, the register function in the IP-block design is guaranteed to be identical to the model software developers use.

A leading supplier of digital TVs recently adopted a methodology of the type this article describes for a recent project. On examining the requirements for the company's next-generation television, they encountered a more-than-twofold increase in device complexity, growing software content, a need for more programmability to deal with new standards, and no increase in design resources assigned to the project. The need for an on-time release of the SOC design to the product-design group was paramount. First, the development team captured the system specification in a central database, from which they could generate IP-block interface logic for the hardware developers; IP-block interfaces, along with a low-level C API, for the software developers; and processor-register maps for the software developers and documentation teams.

The fact that each of these elements developed from a consistent central database ensured that they were correct by construction and that no ambiguity resulted from misinterpretation of paper specifications. The programmatic generation of each element also ensured that specification changes created the least impact on the development program.

Using this process enabled the company to adopt an incremental strategy to its system integration, adding IP blocks one at a time and subsequently rerunning regressions. This approach ensured quick isolation and correction of hardware and software problems. On this project, the team found and fixed more than 50 hardware bugs before tape-out. With the previous design methodology, they estimated, they'd have identified only one bug. The team easily implemented resulting changes to the central specification into affected modules, and changes created minimum impact on resources.

The use of a separate verification engine to model the IP-block behavior ensured rigorous hardware/software co-verification, eliminating all software errors, before system integration. Applying this approach delivered considerable effort and time savings, as well as an improved ability to identify and purge design bugs early in the development process. These savings included 40-fold improvement in the ability to update software, a 140-fold improvement in the ability to update software tests, a 60-fold improvement in the detection of hardware bugs, and a project that requires no late software changes. Finally, from an economic viewpoint, the team completed the system on time and with an overall budget savings of $5.5 million.