Prototyping use models

As indicated earlier, prototyping is done today using different execution engines. Once a chip development project has started, project managers are asked almost immediately to provide early representations – prototypes – of the “chip-to-be” for various purposes, such as:

Marketing needs material and basic documentation to interact with early adopters.

• Software developers would like executable representations of the design under development to allow them to start porting operating systems

• Hardware developers would also like executable specifications to validate that their implementations are correct.

• Prototypes are in high demand from day one! The need is driven by three main use models: architecture exploration, software development and verification.

Prototyping for architecture exploration

At the beginning of a project, architecture exploration allows chip architects to make basic decisions with respect to the chip topology, performance, power consumption and on-chip communication structures. For example, information gathered early on cache utilization, performance of processors, bus bandwidth, burst rates and memory utilization drives basic architecture decisions.

In an ideal world, chip architects would love to get prototypes with fully accurate models – representing all internals of the design – while running at full speed. Unfortunately, both characteristics typically cannot be achieved by the same model. Fully accurate data cannot be gathered until the final chip comes back from fabrication or at least until late in the design cycle, when RTL is available and verified. At that point, FPGA prototypes can be used to execute the design close to real time.

Chip architects also interact with “early adopter” customers and ideally would like executable specifications to demonstrate key features of the design. However, in reality, chip architects mostly rely on tools like Microsoft Excel™ for basic, static architectural analysis. Often they have to rely on their experience and back of the envelope assessments. As a result, interaction with early adopter customers happens based on written specifications and lots of joint discussions at white boards.

Prototyping for software development

Software developers would ideally like to start their porting of legacy code and development of new software functionality from the get go, i.e., when the hardware development kicks off. They would like to receive an executable representation of the chip, which runs at real-time and accurately reflects all the software related interfaces with the hardware (like register images). Depending on the type of software being developed, users may require different accuracy from the underlying prototype. The type of software to be developed directly determines the requirements regarding how accurately hardware needs to be executed:

• Application software can often be developed without taking the actual target hardware accuracy into account. This is the main premise of SDKs, which allow programming against high-level APIs representing the hardware.
• For middleware and drivers, some representation of timing may be required. For basic cases of performance analysis, timing annotation to caches and memory management units may be sufficient, as they are often more important than static timing of instructions when it comes to performance.

• For real-time software, high-level cycle timing of instructions can be important in combination with micro-architectural effects.

• For time-critical software – for example, the exact response behavior of interrupt service routines (ISRs) – fully cycle-accurate representations are preferred.

Often still today, developers will start software development “blindly,” based on register specifications, but are then plagued by not being in sync with changes the hardware team still may make to the register specifications. For derivative product families, application software is often developed using high-level APIs, which can be executed on a previous generation chip. The underlying drivers, OS and middleware, which become available later, make sure that the APIs remain the same and do not break legacy software.

Prototyping for verification

Early on, the chip environment is represented using traces and traffic generators. Early test benches essentially define the use model scenarios for the chip under development.

In a typical design, just as many bugs hide in the test bench as in the actual design itself. Therefore, it is important to start with the development of test benches for verification as early as possible. Ideally, verification engineers would like an executable representation of the “device under test” (DUT) to be available from the start. Similar to software development’s need for different models, verification has requirements for different levels of accuracy as well.

High level models of the DUT will enable development of verification scenarios. Models of the DUT with accurate registers and pure functional representation of the DUT’s behavior satisfy a fair share of test bench development. For verification of timing and detailed pipeline latencies, timing approximation may initially be sufficient but eventually a cycle-accurate representation at the register transfer level (RTL) will be required.

An important trend in hardware verification is the move of functional verification into software, which executes on processors embedded in the design. In answer to the recent survey question “Do you use software running on the embedded processors in your design for verification of the surrounding hardware?”, more than 50% of the respondents answered that they are already using embedded software for verification, and one in ten of them also use it with a focus on post-silicon validation.

The advantage of this CPU-based approach is verification reuse: FPGA-Based Prototyping Methodology Manual 13

• Tests are executed on processors and developed initially using fast instruction-accurate processor models interacting with transaction-level models (TLM) of the DUT, accessing it through its register interface.

• Later the tests can be reused in mixed TLM/RTL simulations as well as in pure RTL simulations for which the processor is mapped into RTL. • The tests can still be used for hardware prototypes with the processor executing as TLM on the workstation, connected to the hardware via highspeed TLM interfaces.

• Processors executing the tests can also run as RTL in the FPGA prototype or can be brought as chip on a plug-in board into the FPGA prototype.

• Finally, when the chip is back from fabrication, software-based tests can be used for post-silicon verification as well.

TABLE OF CONTENTS

Prototyping for architecture exploration

Prototyping for verification