SoC系统级软件测试

f u n c t i o n a l v e r i f i c a t i o n

W h i t e P a P e r

Hybrid eSl/rtl co-verification

platform for SyStem level

Software teSting

piotr K. luSzczaK, mentor grapHicS

prepared for presentation at arm techcon 2011 (class code: atc-100)

AbstrAct

Here’s one of the most oft-cited facts of semiconductor device design today: the increasing complexity of

socs and multicore designs continues to create new verification challenges. Virtual platforms address

such challenges by abstracting designs to the transaction. However, such platforms introduce new

problems, including that hardware-software interface debugging is limited to high-level abstract EsL

models. combining tLM 2.0 and rtL models allows for detecting hardware and software issues in greater

detail than is possible with transaction level models alone. this paper discusses an EsL/rtL model

swapping technique that gives flexibility to debug and analyze systems at any development stage and on

any hardware representation. the benefits of the technique include greater accuracy, optimized

performance and faster product delivery.

introduction

According to the latest surveys, most SoC designs include one or more processors. This trend is due to the

increased cost of hardware verification for custom logic, the relatively flat cost of IP development and the broad

availability of synthesizable, high-performance and low-power processors. Verifying devices that include processors

requires new techniques since hardware and software are involved in the final product.

There are many approaches to this complex problem. One is traditional stimulation of the entire subsystem using

sequences based on the combination of constrained random and direct tests (the latter to cover corner cases).

While the algorithmic approach enables relatively fast coverage closure, it does not include system-level software

execution on the processor. Typical examples of system software include BIOS or device firmware. The processor’s

firmware in particular can only be verified in relation to the hardware, thus the need for a system-level test that

exercises the program and checks if all elements of the integrated system are functioning properly.

Running software on the processor model can be very slow during event-driven simulation at the RTL level. One

way to speed things up is to abstract the design to the transaction level and simulate the SoC using a virtual

platform. Executing software on such a platform generates TLM 2.0 transactions.

figure 1: General esl flow,

including modeling, assembly,

verification, analysis and the

eventual virtual prototype

tHE “Lt” And “At” siMuLAtion ModEs, And tHE LiMitAtions of A tLM-onLy ApproAcH

Collecting and analyzing system software interactions with the TLM 2.0 based models allows for easy measurement

certain aspects of simulation coverage, which in turn enables advanced analysis. As shown in figure 1 on the

previous page, a typical ESL flow consists of modeling, platform assembly, verification, analysis and eventual

creation of a virtual prototype. There are two possible modes of simulation: loosely-timed (LT) and approximately-

timed (AT). The LT mode allows runs the simulation faster and is suitable for executing simple software tasks. The

acceleration mechanism uses directed memory interface (DMI) for all memory accesses. Because the I/O

components are accessed through the bus, which does not support DMI, the transactions are shown as

pronounced spikes in LT simulation.

The AT mode, in which CPUs, I/Os and memories are active and show correct transaction timing, enables more

realistic simulation. The timing information in this mode can be used to provide system performance data,

including power consumption of different IPs at different times, transaction throughput from specific sockets and

average transaction latency. Additionally, the processor core cache can be traced and analyzed through cache

monitors to allow display of I-cache and D-cache performance.

The TLM level runs the virtual platform fast enough to execute system level software at a reasonable speed.

However, the pure ESL verification platform lacks the ability to verify that the system level software, or more

specifically, that such software developed on the virtual platform using SystemC models for particular subsystems

works with target hardware at the RTL level. A TLM-only approach does not allow for detection, repair and

understanding of critical problems across different abstraction levels and language boundaries, a limitation which

may lead to multiple software patches or, worse still, hardware respins. All too often, because of the large amount

of legacy RTL IP that will be reused, a detailed RTL functional verification for portion of the design may still be

necessary.

figure 2: tlm simulation

waveforms for lt and at modes

figure 2: an example of actual

power consumption in at

simulation mode

How A Hybrid pLAtforM cAn HELp

A hybrid ESL/RTL verification platform can address these limitations by integrating the RTL model of the subsystem

into the ESL base platform, thus replacing the corresponding SystemC implementation. In this configuration, a UVM

testbench is used to convert abstract TLM 2.0 transactions representing bus accesses on the SoC’s bus fabric to pin-

level representation on the RTL subsystem interface. The testbench also converts the TLM 2.0 general payload

transactions into sequences that are passed to the verification IP (VIP) component. On completion of a bus cycle,

the VIP returns a response that is passed back to the virtual platform as a TLM 2.0 response.

In addition, the ESL CPU model is swapped for a model that provides both a signal and TLM interface. Such hybrid

architecture allows for directly connecting some pin-level signals to the processor at the RTL level. One example is

interrupt signals, which, when connected at the signal level, give better control over interrupt timing critical for the

embedded system verification flow. Combining transaction level and RTL models exposes more details about

hardware-software issues than does pure TLM abstraction.

Since the hybrid configuration uses a processor model with a mixed TLM/RTL interface, it allows for an accurate

switchable processor as well. The configuration allows for instruction-level accuracy, including fetching instructions

and reading from/writing to memory either with TLM 2.0 transactions or software memory accesses using a

coherent memory server implemented as an API connected directly to the instruction set simulator (ISS) of the CPU.

In this case, the program and data memory is mapped as optimized accesses. This mechanism reduces the TLM/

RTL traffic to I/O communications and allows for visualizing both the number of hardware and software cycles and

the number of executed instructions.

figure 4: example of a combined

esl/rtl verification platform

figure 5: a collection of code

coverage data

By enabling the ability to turning on or off logic simulation

transactions, optimized memory access allows for controlling

which address spaces need to be mapped to coherent servers.

Thus, the ratio between HDL simulation speed and debug

visibility is fully scalable. Cycle-accurate-level simulation is also

possible when an RTL processor model is used. In this mode,

the processor model communicates at the pin-level with other

SoC components. The various processor models make it

possible to dynamically switch simulation accuracy; the

switching mechanism propagates CPU states between ISS/RTL

levels and transfers the contents of caches.

The hybrid ESL/RTL platform allows for concurrently observing

and debugging hardware and software domains. It does so by

linking the software debugger with the logic simulator, which

gives full visibility of the processor while running the entire

design in the HDL logic simulator. Since the software debugger is fully synchronized

with the logic simulator, it’s possible to propagate

of four levels of logic into the software’s

debugging environment. This capability allows for

detection of problems that would otherwise

invisible without four-state logic, such as X states

used in comparisons or computation, or the

referencing of uninitialized memory or registers.

figure 6: software execution acceleration mechanism

figure 7: hybrid esl/rtl platform

for hW/sW debugging

figure 8: arm? 1176 cpU register window showing X states

?2011 mentor graphics corporation, all rights reserved. this document contains information that is proprietary to mentor graphics corporation and may be duplicated in whole or in part by the original recipient for internal business purposes only, provided that this entire notice appears in all copies. in accepting this document, the recipient agrees to make every reasonable effort to prevent unauthorized use of this information. all trademarks

mentioned in this document are the trademarks of their respective owners.

f o r t h e l a t e s t p r o d u c t i n f o r m a t i o n , c a l l u s o r v i s i t :w w w .m e n t o r .c o m concLusion

In sum, the hybrid ESL/RTL coverification platform provides the following benefits:

■Higher speed compared to pure RTL simulation

■Ability to check properties of RTL code using target software running on the CPU

■Ability to debug critical timing of software functions at the transactional and pin level

■Full visibility of the processor while running the entire design in the HDL logic simulator

■Ability to debug the hardware-software interface at a greater level of detail than is possible with an abstract

ESL model

■Multiple levels of accuracy (instruction or cycle-accurate)