SoC系统级软件测试

f u n c t i o n a l v e r i f i c a t i o nW h i t e P a P e rHybrid eSl/rtl co-verificationplatform for SyStem levelSoftware teStingpiotr K. luSzczaK, mentor grapHicSprepared for presentation at arm techcon 2011 (class code: atc-100)AbstrActHere’s one of the most oft-cited facts of semiconductor device design today: the increasing complexity ofsocs and multicore designs continues to create new verification challenges. Virtual platforms addresssuch challenges by abstracting designs to the transaction. However, such platforms introduce newproblems, including that hardware-software interface debugging is limited to high-level abstract EsLmodels. combining tLM 2.0 and rtL models allows for detecting hardware and software issues in greaterdetail than is possible with transaction level models alone. this paper discusses an EsL/rtL modelswapping technique that gives flexibility to debug and analyze systems at any development stage and onany hardware representation. the benefits of the technique include greater accuracy, optimizedperformance and faster product delivery.introductionAccording to the latest surveys, most SoC designs include one or more processors. This trend is due to theincreased cost of hardware verification for custom logic, the relatively flat cost of IP development and the broadavailability of synthesizable, high-performance and low-power processors. Verifying devices that include processorsrequires 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 usingsequences 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 softwareexecution on the processor. Typical examples of system software include BIOS or device firmware. The processor’sfirmware in particular can only be verified in relation to the hardware, thus the need for a system-level test thatexercises 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. Oneway to speed things up is to abstract the design to the transaction level and simulate the SoC using a virtualplatform. Executing software on such a platform generates TLM 2.0 transactions.figure 1: General esl flow,including modeling, assembly,verification, analysis and theeventual virtual prototypetHE “Lt” And “At” siMuLAtion ModEs, And tHE LiMitAtions of A tLM-onLy ApproAcHCollecting and analyzing system software interactions with the TLM 2.0 based models allows for easy measurementcertain aspects of simulation coverage, which in turn enables advanced analysis. As shown in figure 1 on theprevious page, a typical ESL flow consists of modeling, platform assembly, verification, analysis and eventualcreation 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. Theacceleration mechanism uses directed memory interface (DMI) for all memory accesses. Because the I/Ocomponents are accessed through the bus, which does not support DMI, the transactions are shown aspronounced spikes in LT simulation.The AT mode, in which CPUs, I/Os and memories are active and show correct transaction timing, enables morerealistic 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 andaverage transaction latency. Additionally, the processor core cache can be traced and analyzed through cachemonitors 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 morespecifically, that such software developed on the virtual platform using SystemC models for particular subsystemsworks with target hardware at the RTL level. A TLM-only approach does not allow for detection, repair andunderstanding of critical problems across different abstraction levels and language boundaries, a limitation whichmay lead to multiple software patches or, worse still, hardware respins. All too often, because of the large amountof legacy RTL IP that will be reused, a detailed RTL functional verification for portion of the design may still benecessary.figure 2: tlm simulationwaveforms for lt and at modesfigure 2: an example of actualpower consumption in atsimulation modeHow A Hybrid pLAtforM cAn HELpA hybrid ESL/RTL verification platform can address these limitations by integrating the RTL model of the subsysteminto the ESL base platform, thus replacing the corresponding SystemC implementation. In this configuration, a UVMtestbench 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 payloadtransactions 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 hybridarchitecture allows for directly connecting some pin-level signals to the processor at the RTL level. One example isinterrupt signals, which, when connected at the signal level, give better control over interrupt timing critical for theembedded system verification flow. Combining transaction level and RTL models exposes more details abouthardware-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 accurateswitchable processor as well. The configuration allows for instruction-level accuracy, including fetching instructionsand reading from/writing to memory either with TLM 2.0 transactions or software memory accesses using acoherent 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 andthe number of executed instructions.figure 4: example of a combinedesl/rtl verification platformfigure 5: a collection of codecoverage dataBy enabling the ability to turning on or off logic simulationtransactions, optimized memory access allows for controllingwhich address spaces need to be mapped to coherent servers.Thus, the ratio between HDL simulation speed and debugvisibility is fully scalable. Cycle-accurate-level simulation is alsopossible when an RTL processor model is used. In this mode,the processor model communicates at the pin-level with otherSoC components. The various processor models make itpossible to dynamically switch simulation accuracy; theswitching mechanism propagates CPU states between ISS/RTLlevels and transfers the contents of caches.The hybrid ESL/RTL platform allows for concurrently observingand debugging hardware and software domains. It does so bylinking the software debugger with the logic simulator, whichgives full visibility of the processor while running the entiredesign in the HDL logic simulator. Since the software debugger is fully synchronizedwith the logic simulator, it’s possible to propagateof four levels of logic into the software’sdebugging environment. This capability allows fordetection of problems that would otherwiseinvisible without four-state logic, such as X statesused in comparisons or computation, or thereferencing of uninitialized memory or registers.figure 6: software execution acceleration mechanismfigure 7: hybrid esl/rtl platformfor hW/sW debuggingfigure 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 trademarksmentioned 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 :concLusionIn 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 abstractESL model■Multiple levels of accuracy (instruction or cycle-accurate)。