SystemC based Virtual SoC â an Integrated System Level and Block ...
SystemC based Virtual SoC â an Integrated System Level and Block ... SystemC based Virtual SoC â an Integrated System Level and Block ...
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
- Page 1 and 2: 16 Nov 2004ST-CMG tech-article (v1.
- Page 3: 16 Nov 2004ST-CMG tech-article (v1.
- Page 7: 16 Nov 2004ST-CMG tech-article (v1.
16 Nov 2004ST-CMG tech-article (v1.2)Figure 2: SimVision/TxE/SysProbe <strong>an</strong>alysis environment3- Functional verification: co-simulation TLM <strong>an</strong>d RTLThe <strong>Virtual</strong> <strong>SoC</strong> TLM platform (integrating bus, memories, CPU) was also re-used forfunctional verification at block level <strong>an</strong>d platform level using Incisive <strong>an</strong>d <strong><strong>System</strong>C</strong>. Thisprovided the ability to achieve fast simulations. As <strong>an</strong> 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 <strong>an</strong>d platform views me<strong>an</strong>s that the tests<strong>an</strong>d test harness do not have to be re-implemented in a new l<strong>an</strong>guage <strong>an</strong>d tool set. Athree-step approach was used to achieve block <strong>an</strong>d 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 <strong>SoC</strong>. This implies that the RTLblocks c<strong>an</strong> be verified st<strong>an</strong>d-alone before integrating with the rest of the RTL. Italso me<strong>an</strong>s that function tests used for system level verification c<strong>an</strong> be reused forblock level verification.• The Second step involves connecting the RTL DUT to the TLM testbenchthrough bus functional models (BFM), also known as tr<strong>an</strong>sactors. Thesetr<strong>an</strong>sactors use the <strong><strong>System</strong>C</strong> Verification Library (SCV) to shape the timingpg# 4 of 7
Change language