ESL-based flow eases complex SoC design

The notion of design and verification gaps (the ability to design and verify fast enough to use silicon capacity) has been well acknowledged in the industry. One response has been the development of a healthy design and verification intellectual-property (IP) market that employs reuse to close the gaps.

Simultaneously, the industry has been looking at ways to improve engineering productivity by offering improved register-transfer-level (RTL) verification tools with advanced features, such as constrained-random test generation, functional coverage metrics and assertions made available through such languages as SystemVerilog.

Along with those trends, the industry has introduced design and verification tools that operate at higher levels of abstraction, such as the electronic system level (ESL), supported through languages such as SystemC.

Designing at higher levels of abstraction-for example, through transaction-level architecture models-indeed improves designer productivity. Not having to deal with all the detail of an RTL model allows engineers to quickly design architectures that can be analyzed and shown to be effective for the target application.

Additionally, virtual platforms-or software models of complete embedded systems, including complex systems-on-chip-are being used for presilicon software development. These virtual platforms are very high-level functional models of the SoC, typically running at 10 MHz to 20 MHz or even faster. Such platforms enable software development for the SoC to start many months earlier when compared with a traditional flow, using prototypes or emulators, which requires the RTL to be available.

These two developments have led to an emerging ESL-based design flow for complex SoCs. This flow requires a high-speed virtual platform early in the project cycle to enable true concurrent hardware and software development. Using this virtual platform, software engineers can port operating systems, write drivers and develop the applications specific for the chip, so that by the time the RTL is available the software is ready as well.

Simultaneously, on the hardware side, a detailed architecture model is created as a first step. Such an architecture model typically models the SoC in a cycle-accurate fashion. This model is used to ensure that the right architectural trade-offs are made, such as decisions on the bus infrastructure, buffer sizing and so forth, before committing to the RTL implementation phase.

A practical notion of equivalence can be obtained by creating a common set of tests that can drive the virtual platform model, the architecture model and the RTL model. When all three models pass this set of tests, the models are considered equivalent. This leads directly to the idea of a single testbench. Such a testbench not only defines and ensures the equivalence of the models but also is critical in creating an ESL-based SoC development flow (see figure).

To interact with models at different abstraction levels, the testbench must have an architecture based on the same levels of abstraction used to model the SoC design. With such a testbench, a golden test suite can then be defined to ensure the equivalence of the various models at different levels of abstraction during the SoC development cycle.

The requirements for this type of testbench are quite challenging. On the one hand, it needs to efficiently create a variety of scenarios to drive the virtual platform model. Then those scenarios need to be refined and mapped onto cycle-based transactions to drive the architecture model. Finally, the transactions need to be mapped onto signals to connect to the RTL world. On the other hand, the testbench needs to interact with the software running on the design-for example, to control when a particular interrupt is created. To realize this, the features required to effectively verify all three abstraction levels-virtual platform, architecture and RTL-are needed.

Although modern verification methodologies have primarily focused on verifying the RTL, they have in fact already adopted a layered testbench architecture. The key abstraction layers in this methodology are the scenario, function and command layers.

The scenario layer uses constrained-random stimulus generators to produce the data streams that represent all possible usage scenarios. The function layer takes those data streams, turns them into streams of individual transactions-for example, read/write transactions for a specific bus-and performs detailed protocol checking. Finally, the command layer takes the individual transactions and drives the input of the RTL model.

Throughout this process, coverage is measured.

This methodology supports a top-down approach to building a verification environment. The approach allows a team to build a complete verification environment early in the development process, even before any RTL code has been developed.

The environment then becomes the "golden reference" for verifying additional verification components and the RTL design. If the architecture model is cycle-accurate, it is easy to add in the RTL when it is ready.

To perform all these tasks effectively, powerful features such as constrained-random stimulus generation, coverage metrics and assertions already required for the RTL verification, combined with an object-oriented programming style, provide a highly effective environment to implement the higher layers of the testbench as well. Users can also verify the architecture models as well the virtual platform models, ensuring that all models stay mutually consistent during the SoC development process.

Rindert Schutten (rindert.schutten@synopsys.com) is director of marketing for the System Level Solutions Verification Group at Synopsys Inc. (Mountain View, Calif.).

See related chart