Architectural Exploration using ESL Modelling

A SoC combines hardware and software and communicates with the outside world via various interfaces. An ESL Model of a SoC is able to simulate the complete system behaviour. This includes running all of the software that the real SoC will run in a largely unmodified form. The acronym ESL stands for `Electronic System Level'. An alternative name for an ESL model is `Virtual Platform'.

The performance of an ESL model must be good enough to execute large programs in a reasonable time. This typically means achieving at least one percent of real system performance. An ESL model is normally accurate in terms of memory layout and content, but many other hardware details are commonly neglected unless they are of special relevance to the test being run. This is the principle means of gaining high performance.

Another way to apply an ESL model to complex software is `checkpoint and replay'. This is useful if a lot of software must run before the point of interest is approached. A checkpoint is chosen, such as the point after boot and operating system start. At the checkpoint, all of the state from the model is saved to a checkpoint file. Information could be captured from the real system in principle, but the ESL model may not be identical to the real system and minor discrepancies may arise, or instrumenting the real system may be tricky (especially if it does not exist yet). Since the checkpoint serves as the basis for a number of experiments, time invested in generating it is amortised.

To conduct an experiment, the ESL model is loaded with the checkpoint data and modelling rolls forward from that point. The model may be switched to a greater level of detail than used for preparing the checkpoint, either globally or just for some sub-systems. For instance a high-level model of an I/O block may be switched to an RTL model.

We can model our hardware system at various levels of detail following the taxonomy:

• Functional Modelling: The `output' from a simulation run is accurate.
• Memory Accurate Modelling: The contents and layout of memory is accurate.
• Untimed TLM: No time stamps recorded on transactions.
• Loosely-timed TLM: The number of transactions is accurate, but order may be wrong.
• Approximately-timed TLM: The number and order of transactions is accurate.
• Cycle-Accurate Level Modelling: The number of clock cycles consumed is accurate.
• Event-Level Modelling: The ordering of net changes within a clock cycle is accurate.

An ESL methodology aims:

Aim 1: To model with good performance a complete SoC using full software/firmware.

Aim 2: To allow seamless and successive replacement of high-level parts of the model with low-level models/implementations when available and when interested in their detail.

So, an ESL methodology must provide:

• Tangible, lightweight rapidly-generated prototype of full SoC architecture.

• Rapid Architectural Evaluation: determine bus bandwidth and memory use for a candidate architecture. Easy to adjust major design parameters.

• Algorithmic Accuracy: Get real output from an early system, hosting the real application/firmware, possibly in real-time.

• Timing information: Get timing numbers for performance (accurate or loose timing).

• Power information: Get power consumption estimates to evaluate chip temperature and system battery life.

• Firmware development: Integrate high-level behavioural models of major components with their device drivers to run test software and applications before tape-out.

Enhancements beyond that are:

• Synthesise high-level models to form parts of the fabricated system (e.g. using HLS)(but today manual re-coding is mainly used).
• Embed assertions in the high-level models and use these same assertions through to tape out.