SystemC based Virtual SoC – an Integrated System Level and Block ...

16 Nov 2004ST-CMG tech-article (v1.2)SystemC based Virtual SoC – an Integrated SystemLevel and Block Level Verification approach fromSimulation to Co-EmulationAuthors:Laurent Ducousso (ST), Frank Ghennassia (ST), Joseph Bulone (ST), Neyaz Khan(Cadence), Ascension Vizinho-Coutry (Cadence)Abstract:ST faced two daunting challenges for their next generation product (1), to provide an advanced and fastplatform for s/w development, including ISS and hardware models described in abstraction level, runningat a minimum targeted rate of 1 MHz in the simulation environment and (2) to integrate the system leveland block level verification environments for a large RTL design with a significant firmware component .The Transaction Level Modelling (TLM) capabilities of SystemC were used to deliver a Virtual SoC andhelped to resolve challenge number (1). Though the TLM behaviour was modelled with more abstraction,there was enough accuracy for the software developers to be able to debug their SoC design while runningat 1 MHz. Having this platform available early in the process enabled software engineers to begindeveloping the embedded software for the application. Not only did this bring in the overall projecttimescales, but also the exceptionally close co-operation between the software and hardware teams in theearly phases of the project led to the detection of significant bugs in the hardware specification of thedesign. Because these bugs were found early, they were relatively cheap to fix, and contributed to save a respinof the chip.The Virtual SoC was extended to provide a block level Verification environment for a Low Cost MPEG2and more recently MPEG4 design using Incisive and SystemC. Reusing the system level environment inthis way means that the tests (using images 80x96 pixels) and test harness do not have to be reimplementedin a new language and tool set. In order to speed up the RTL verification regression and runfull size conformal tests (with 1920x1080 and 720x480 pixel images), Transaction Based Acceleration(TBA) and emulation have completed the validation process.In order to accelerate the regression test of the IP, virtual SoC environment used Cadence Incisive and thePalladium for signal-based acceleration, by re-using SystemC high-level of abstraction for the testbenchportion (simulations went from 300 Hz on Incisive up to 10 kHz using signal-based acceleration). Thisperformance will improve further in the future, using Transaction-Based Acceleration methodology.Incisive capabilities included mixed language SystemC/RTL kernel, SimVision for debugging andperformance analysis thanks to TxE 1 . SysProbe methodology, dedicated to verify RTL performance andfunctionality, was then built on top of TxE..1 Transaction Explorer tool from Cadencepg# 1 of 7

16 Nov 2004ST-CMG tech-article (v1.2)1- Introduction: Verification and validation challengesBecause of the increasing complexity of set-top-box chips, the Verification team decidedto follow SystemC/TLM (Transaction Level Modelling) methodology. This allowed SWteams to initiate their SW development early in the design flow and provide an advancedand fast co- simulation platform for s/w development. This included ISS models, runningat a minimum targeted rate of 1 MHz in the simulation environment without the use ofhardware accelerators. Figure 1 illustrates the SoC TLM flow compared to the old flow.Section 2 describes this Virtual SoC platform for 3 usages: SW development, HWverification and architecture exploration and analysis. Section 3 will present STverification process for RTL at block and platform levels for set-top-box chips.In order to complete full verification regression tests (with real image sizes), the VirtualSoC platform was extended to include simulation acceleration. This approach makes useof the Transaction Based Verification (TBV) methodology, which enables the ability tomix SystemC testbench with RTL emulated on the Palladium 2 H/W emulator. This willbe described in section 4. Section 5 will summarize the benefits of the Virtual SoCplatform and will comment the next steps of ST TLM methodology.Traditional FlowSOC platforms in the design flowSpec Archi Design Fab BoardSoftwaredevelopmentSystemIntegrationSystemValidationCurrent flowSoC TLMDesignFabBoardCo-designTLM/ISSSoftwaredevelopmentSystemValidationSystemValidationCo-verificationRTL/ISS/TLMGAINTimeFigure 1: Comparison between traditional and SystemC/TLM flow2 Cadence H/W accelerator & emulator.pg# 2 of 7

16 Nov 2004ST-CMG tech-article (v1.2)2- Virtual SoC TLM platformTransaction Level Modelling (TLM) was pushed by industry and research institutesthrough OSCI to respond to the following tasks:- Embedded software development- Functional verification- Architecture analysis and exploration- HW/SW co-verification, HW validationTLM infrastructure was developed to support modelling communication structures atthree abstraction levels: i.e. Programmer’s View (PV), Programmer’s View with Timing(PVT) and Cycle Accurate (CA), leaving it up to the user to compromise betweensimulation speed and accuracy. ST has played a major role in the OSCI-TLM workinggroup and deployed TLM methodology on multiple projects.The virtual SoC TLM platform was developed at the PV level from Specifications inorder to offer fast simulations for the next phases. This platform has been used asreference model and enabled concurrent SW and HW engineering and close co-operationin early phases of the project. This process lead to the detection of significant bugs earlyin the hardware specification. Because these bugs were found early, they were relativelycheap to fix, and contributed to save a re-spin of the chip.SW engineers could start development before having the board. As example, this wasdone on Graphic Engine blitter and MPEG2 projects; the driver was developed beforehaving a board, that lead to 6 months time gain in comparison with traditional flow (aspointed out in figure 1).HW verification group employed TLM platform because, though more abstract, itaccurately modelled the bit level behaviour of the SoC while running at 1 MHz (this wasachieved on MPEG4 decoder project). This will be fully described in the followingsection.Another domain of utility is architecture exploration and analysis. The SoC TLMplatform, when refined with timing information, can provide relevant information on busbandwidth, peripheral accesses, interrupt latencies, memory conflicts and latency to thearchitects. The SysProbe methodology was built at ST using the flexible transactionrecording, viewing and analysis capabilities of Cadence’s SimVision and TXE. SysProbecould record the transactions generated by proprietary architectural models. It was alsoused for functional and timed validation. By calibrating TLM with back-annotated data[1] it was also possible to record the same transactions generated by either TLM modelsor corresponding RTL models and to compare the results using the environment providedby Cadence’s TXE. This technique was used to verify the performance of the RTL.pg# 3 of 7

16 Nov 2004ST-CMG tech-article (v1.2)Figure 2: SimVision/TxE/SysProbe analysis environment3- Functional verification: co-simulation TLM and RTLThe Virtual SoC TLM platform (integrating bus, memories, CPU) was also re-used forfunctional verification at block level and platform level using Incisive and SystemC. Thisprovided the ability to achieve fast simulations. As an example, for MPEG4 decoder, fullRTL (including complete test bench) would take 6/7 hours. This was reduced to fewminutes with TLM backbone (tests used images 80x96 pixels).Reusing the system level environment at block and platform views means that the testsand test harness do not have to be re-implemented in a new language and tool set. Athree-step approach was used to achieve block and platform level verification:• First, step is to verify the block level. This step used the TLM models of the lowcost MPEG4 already developed for the virtual SoC. This implies that the RTLblocks can be verified stand-alone before integrating with the rest of the RTL. Italso means that function tests used for system level verification can be reused forblock level verification.• The Second step involves connecting the RTL DUT to the TLM testbenchthrough bus functional models (BFM), also known as transactors. Thesetransactors use the SystemC Verification Library (SCV) to shape the timingpg# 4 of 7

16 Nov 2004ST-CMG tech-article (v1.2)characteristics of the traffic across the bus, and the transaction recording andviewing capabilities of Incisive to verify the performance and functionality of theDesign Under Test (DUT).• The third step is to use the fast mixed language simulation and debuggingfacilities of Incisive to verify the full RTL design, by connecting the RTLdescription of the DUT to the SystemC based Virtual SoC Verificationenvironment described in previous sections.Writing tests at the transaction level means that the tests can be used at both system andblock level. But to do effective block level verification, we need to stress the DUT byshaping the timing characteristics of the data. ST uses SCV, the OSCI verification librarysupported by Incisive, to randomize the timing characteristics of the bus traffic. Forexample, we can allow the length of a burst write to vary between a minimum andmaximum number of clock cycles, or we can specify the gap between one burst and thenext. Randomizing traffic characteristics in this way can trap costly bugs that the blockdesigner may not have been able to test for.SysProbe methodology is used together with SimVision as a powerful transaction levelvisualization tool. By visually looking at transactions rather than individual signals in awaveform viewer, functional bugs can be identified and tracked down a lot quicker, andmore efficiently. Once the problem is identified, the verification engineer can switch tothe signal level to work out how to fix the bug.4- Validation: co-emulation TLM-PalladiumThe Validation process is incomplete without testing real condition input to the design.Once the design was converted from SystemC to RTL, simulation performance wasreduced. In the case of the MPEG4 design, full image sizes are 1920x1080 and 720x480.These image sizes could not be fully tested during simulation.The traditional approach at CMG group has been to wait until fully synthesizable andcomplete RTL is available, and then use the Palladium emulator to test full RTLimplementation. The Transaction-Based Verification (TBV) methodology was adopted inorder to get a head start for full-chip verification, early in the development effort. Thisalleviated the need to wait for the availability of complete RTL (including test bench).This methodology allows the design teams to re-use the SystemC testbench, that wasused in the first and second phase, while the design is being converted into RTL. Theperformance gain allows the teams to run long tests and continue to validate their system,while the design under test is getting its final RTL representation.The Incisive TBA solution ( as illustrated in figure 3), which is based on the standard coemulationmodelling interface (SCE-MI), enhances simulation acceleration performanceof the Palladium system by reducing communication between the test bench running onthe workstation and the design under test in the emulation system. Productivity featuresinclude support of variable-length messages, a faster streaming mode, transactionpg# 5 of 7

16 Nov 2004ST-CMG tech-article (v1.2)recording capabilities and support of both timed and un-timed test bench components.This solution enables full congruency with the Incisive unified simulator to shorten bringuptime and assure reusability of the test bench and the verification IP models. ST hopesto reach 100 kHz in comparison of 10 kHz at signal-based acceleration for a full imageformat SD.Figure 3: Transaction Based Acceleration5- Conclusion and future developmentsIn summary, the virtual SoC TLM platform made early SW development possible – up to6 months earlier than the traditional approach. The Validation process was also pulled inby approximately 3 months – by utilizing the TBV methodology. All this was madepossible by using SystemC/Incisive environment, which also provided the ability tomaintain same debugging and transactional environment for both RTL and System-levelverification.The effort to create and update more and more TLM models into the portfolio is anongoing process at ST for efficient System Level Verification. TBA methodology isreally beneficial if one can enhance the speed of co-emulation. While this approach hasalready proven beneficial at ST, there is continued joint effort to improve thismethodology and technique.To further enhance the efficiency and throughput of the Verification effort, CadenceAssertion Based Verification (ABV) is also being investigated, and will potentially beused on future projects.pg# 6 of 7

16 Nov 2004ST-CMG tech-article (v1.2)[1] [Clouard et al., 2002] Clouard, A., Mastrorocco, G., Carbognani, F., Perrin, A. undGhenassia, F. (2002). Towards Bridging the Gap between SoC Transactional and Cycle-Accurate Levels. In Proc. of Design, Automation and Test in Europe -- Design Forum(DATE'02), Paris, France. IEEE CS Press, Los Alamitos)pg# 7 of 7