This article by Victor Reyes and Kurt of Synopsys talks about how SystemC based virtual prototypes enables the new methodologies for improving functional safety of automotive systems
Read more ..
Read more ..
|
0 Comments
This article is the summary of a paper presented at DVCon India 2015, jointly by Freescale Semiconductors and CircuitSutra Technologies Developing the virtual model of a CPU and effectively using it in a virtual platform is a pretty complex task. One of the major contributing factors for this complexity is to ensure the correct behavior of the cpu model. The effects of a bug in a cpu model usually have a high cost in terms of its detection at a later stage. However, bugs can be prevented by effectively testing the model. In this paper we discuss the approach followed to build a framework for such verification. Execution of any cpu instruction depends on the input state determined by system register settings and instruction operands and can alter the state of its registers, memory, exception and MMU during execution. The basic underlying principle of the framework is to compare the output state of the cpu model against the golden reference model for every cpu instruction that is executed. If the states of the cpu model matches as that of golden reference model, the behavior of the cpu model is taken to be correct. One of the challenges in the verification of the cpu model is to ensure that the test case data is comprehensive enough to cover maximum possibilities for the cpu model. Solution for this problem lies in the randomization of test case data and instruction set. Our methodology follows following variations of randomization: Our framework test case randomization includes instructions with valid operands and constrained setting of system registers such that no exception of interrupt condition is encountered. Instruction with valid operands and random setting of system registers to cover interrupt/exception scenarios and instructions with random operands and random system register settings In this section we discuss about our verification framework, its constituents and test case scenarios. There are four basic building blocks for the framework - Test generator, the CPU model that is to be verified, golden reference model and the test output validation.  Test generator takes as input the ISA and list of constraints that needs to be considered while generating a test case. Constraints can be specific to Instruction type or can be applicable to set of instructions. The constraint list can vary as per the ISA and according to the different test case scenarios being exercised. Our framework considers constraints like randomization of core registers, instruction operands for both valid and invalid instructions. Handling of scenarios like addresses alignment, address range, self-modifying code while generating test case for load/store instructions. Randomization of conditional flags in case of conditional instructions. Specific cases like 128 bit registers in case SIMD and Floating point instructions are handled accordingly. In this section we discuss about the class of test suites generated in our framework, so as to ensure maximum coverage of the cpu model. Our framework considers the below mentioned variations of test scenarios. Single starter / Jump starter test suites - This class of test cases deals with testing the basic functionality of every instruction - Integer, Floating Point, SIMD, Crypto: Arithmetic, Logical, Load, Store, Branch, System, etc. Operands are constrained to avoid generating exception and register data is randomized. Jump starter test suites exercises the same behavior as of single starter but in repeated manner. 100s of same instruction with different/random operands executing back to back Instruction test mix suites - This class of test cases deals with testing a random sequence of valid instructions. Operands are again constrained to avoid generating exception and register data is also randomized here. Random single starter, jump starter and test mix suites - Focus is on randomization of control register and handling of exception state. Test suite with random data and operands - All system registers are fully randomized along with the randomization of code. Handles negative test case scenarios and exception handling mechanism. Test suites for MMU validation - In this class of test suites we discuss about the various test data for validation of MMU. Test case for MMU include scenarios like individual control of MMU at different exception level, support for virtual address, validation of different translation levels and translation lookaside buffer [TLB] caching Extensive testing of the CPU model helped us in fixings bugs at an early stage, result being s/w boot up with minimal effort.  Benefits of using virtual prototype even when the real hardware or hardware prototype is available The article covers how to effectively use the SystemC, TLM2.0 based virtual prototype for setting up advanced methodologies for development & testing of embedded software. Virtual prototypes are becoming an important component of design and verification flows for SoC, embedded software, and complete electronic systems. Virtual prototype is a fast simulation model of the hardware system, and provides an environment where the target platform binary can be run as-is, at speeds comparable to hardware speeds, using the same development environment. The well known advantage of using virtual prototypes is that it enables the early software development much before the hardware design is complete, that helps to reduce the time to market for an electronics product, and is the primary motivation for investing in the virtual platform development. Does it mean that virtual prototype becomes useless when the real hardware becomes available? More and more companies are using virtual prototype even after the real hardware becomes available. This article covers powerful features of virtual prototype which makes it suitable to be used for the development and verification of complex embedded software, even after the hardware becomes available. To setup the effective flow for embedded software development and testing using virtual prototype, it is necessary to have strong understanding of these differentiating features. With hardware getting increasingly commoditized, companies are focusing on software to provide market differentiation. This puts pressure on software content creation requirements which are driving engineering organizations to fundamentally reevaluate their embedded system engineering processes. Sheer size of the embedded software code and the complexity of the software in the embedded device increases the chances for bugs and demand rigorous test and validation of the complete system. Hence it becomes necessary to implement modern efficient practices in place of traditional methods for embedded software development. Virtual prototypes integrates with the same standard embedded software tools that works with hardware boards, hence embedded software engineers can seamlessly migrate from using the hardware board to the virtual prototypes for standard development and debug methodologies. Virtual prototypes also integrates with the new set of tools which allow advanced hardware level debug analysis and hardware-software co-debug. These tools are called Virtual Prototyping tools, and provides the additional features that makes using virtual prototypes more powerful as compared to using hardware boards. To effectively use these additional features, and to setup advanced methodologies, the existing skills of embedded software engineers are not sufficient. Hence embedded software engineers need to be educated about these new methodologies. Another approach that few companies have successfully deployed is to have a small methodology team to support the rest of the embedded software team with the advanced virtual prototype based methodology. CircuitSutra works with several customers and act as their methodology team for effective deployment of virtual prototypes in their embedded software development & verification flow. Instruction trace: The CPU models used in the virtual prototypes, provides option to dump CPU instruction traces when an embedded code is run on the VP. This advanced instruction tracing provides information about the instruction type, address and opcode of the instruction along with updated register values. Software logs through semihosting: As we all know, the most common method for debugging any software is to print the log messages from different parts of the code. The embedded SW engineers generally use hardware boards or real embedded products to run and test their software, hence they are not able to use this powerful debug method. However, if you use virtual prototype, then you may print the messages from the embedded software code on the terminal window or the log file on the host computer in a non-intrusive way. For achieving this functionality, VP uses the semihosting feature which allows to use the I/O resources of the host computer in the VP. Hardware logs: Another important feature of virtual platform is that debug / information messages can be printed from within the hardware as well. From these messages you may judge what specific functionality of the hardware IP was invoked, what was the state of specific register / buffer / signal etc. when a specific embedded code was executing in the virtual platform. SystemC tracing features enables one to monitor signals and interfaces against time scale. Logging and other checks can be added – in configurable manner - to the platform to monitor for significant events without modifying the source code. Severity levels of the logs can be tweaked by the user, depending upon one’s requirement to dump different level of information. HW or Virtual prototype logs plays a vital role in debugging and analysing the response of the system. The sequence of the HW logs alongside with Embedded SW logs provides more information about how the functionality of embedded SW and the hardware IP works together in lock in fashion. This helps to precisely identify the buggy component of sub-system, and to debug the corner case scenarios. Configuration & bring up: Most of the virtual prototyping tools provide the scripting interface for monitoring & controlling the internal state of the system. Before a hardware board / setup can be used, it have to be properly configured and bring up in a specific state. Most of the time it is a tedious, error prone and time consuming activity. Virtual prototypes provides the scripting interface through which you may load the value into internal registers and memories. It enables you to quickly bring the system into any desired state, and significantly reduce the bringup time. A hardware board / setup supports different configuration states for different applications. With virtual prototypes you may create any number of setup with different value of configuration state, without worrying about re-configuring the same board again or without having to purchase larger number of hardware boards. In case of complex hardware setups, you do not have to physically visit the lab to change the configuration. Automated unit testing: One of the primary use case of the Virtual Platform is to develop the automated unit testing framework for the testing of embedded software, which could be in the form of; bare-metal applications, base hardware layer software, device drivers, or full-fledged OS applications, etc. The features explained above: Instruction tracing, Embedded SW logs & HW logs, Scripting interface etc.. - play a vital role for creating automated unit test cases. A typical unit testcase will start with a small C / assembly code, cross compiled using tool chain, run it on the VP, generate trace and logs, compare with golden logs to decide pass fail. A top level script may be developed to run thousands of such unit test cases. A more comprehensive setup may be created to monitor various quality parameters like coverage, memory profiling, etc.. The growing amount of embedded code has to be maintained and enhanced throughout the lifecycle of product. Every time you make changes to certain functionality of embedded code, you need to ensure that no other feature is broken. Hence you need to have right processes in place that allows you to monitor and maintain the quality of embedded software. Automated unit test suite can be part of your daily / nightly regression. It is always desirable to have automation because manual processes don’t scale. Such an automation is not feasible with physical hardware, as it's difficult to invoke the hardware from within a script. Automation using virtual prototypes also enables you to parallelize your testing. Thousands of testcases can be run in parallel on the server farm. It also enhances the ability of the organization to react to the test failures. If a bug is introduced due to some recent code change, it gets detected in time, and corrective action can be taken quickly. Automation allows you to significantly increase the amount of testing that gets done with each iteration or software release, without having to increase the number of specialized hardware required and without having to increase the team involved in manual testing. Visibility, Controllability and Reproducibility: Virtual Platform allows the users to halt the simulation of complete system at any point, and observe the state of specific software, hardware IP block, sub-system, value of registers, interfaces, internal buffers, memory etc.. You can simultaneously visualize what is happening inside the software and hardware. It helps to debug and resolve the bugs related to hardware - software interaction. Such a visibility is not feasible while using the hardware board, by putting a breakpoint through a debugger you may halt the software running on one CPU, but rest of the system (other CPUs, timers etc..) keeps on running, hence it is not possible to see the correct state of the system at a particular instance. This is feasible with the virtual prototype, because VP itself is a software and can be stopped / debugged just like any other software. After halting the simulation at a certain instance, users may also change the state of the system by manually changing the values of registers, signals, memory etc… and then continue the simulation from there. It helps to test the behaviour of the system (software & hardware) in corner case scenarios which are hard to reproduce with real hardware in normal development setup. Another important feature of virtual prototype is its ability to reproduce the same scenario again and again due to determinate execution. By providing same sequence of inputs and following the same steps, you may bring the simulation in precisely same state again and again. It is also possible to record and replay the simulation using VP tools. Some virtual prototyping tools also provide the functionality to save & restore the state of the system. This allows you to save a snapshot of the entire simulation in a file. This snapshot may be shared with other team members or third parties who may restore the state, and continue with the simulation from that point. Some virtual prototyping tools also provides the reverse execution capability. You may halt the simulation at any stage, and go step by step backward in your code. This can help you find exactly where the fault originated. VP’s ability to be co-debugged with SW, along with variety of traces to enable & disable, makes one to gain a higher degree of confidence while reproducing the error scenario. Also, it provides increased visibility into, and control of the platform which greatly assists in knowing step-by-step or stage-by-stage response of the VP and thus by narrowing down the SW bugs in a timely manner. Reproducing the complex system scenarios: Virtual prototypes also serves as a post-silicon reference platform for simulating scenarios that are difficult to replicate and control on the real hardware. For example in automotive, there is need to be able to simulate and test potentially fatal corner cases in software without crashing real cars. Error injection: As we discussed, in the VP it is possible to manually change the internal state of the hardware (registers, memory, signals, etc.). Using this mechanism it is feasible to bring the system into some error state, and check the behaviour of embedded software. Also in the virtual prototype, it is possible to provide the data at the interfaces (uart, i2c, CAN, LIN etc.. ) from a dummy model that act as a traffic generator or from a file. Protocol errors may be introduced in this traffic being fed into the virtual prototype of electronic system / SoC. This is effective mechanism to check the robustness of embedded software and how does it react to the error situations. Such Error or Fault Injections helps one to understand the response of the system which may occur as a rare case scenario. Such debugging capabilities are difficult or nearly impossible to do it on real hardware, even with a hardware debugger or other mechanisms. Avoiding bulky hardware prototypes and lab setups: Many times it requires to develop bulky hardware prototypes and specialized lab setup for the development and testing of embedded software. Target hardware setups may not be made available all the time to all the engineers working in cross geographical teams. Specialized hardware setup is generally a scarce resource and developers / teams have to compete with each other to get access. Virtual platforms can be installed on the computer / laptop of every embedded software developer just like any other software tool. Cost of developing the hardware labs may be quite high. Virtual prototypes are also adaptive to frequent changes as compared to hardware setups, hence are more reusable and cost efficient. Easy collaboration: Virtual prototypes enables easy information exchange with other teams, third parties and customers. Customer support team can have every customer configuration readily available at their end, to quickly reproduce errors and solve customer issues. Virtual prototypes can be used by the sales team for demonstration to the customers. CircuitSutra Modeling Methodology enables the development of SystemC models that can span multiple use cases: architectural exploration, pre-silicon & post-silicon embedded software development, RTL verification, co-simulation, co-emulation. These models can integrate with all the tools required in the entire ESL design & verification flow. Support for new tools can be added without having to update the model code.
Good to see the announcement from Accellera about UVM SystemC. The standard will enable the effective usage of the advanced verification techniques for the verification of ESL models developed using SystemC, TLM2.0, or to use these ESL models in the verification flows for the verification of RTL. Read more .. CircuitSutra Modeling Methodology enables the development of SystemC models that can span multiple use cases: architectural exploration, pre-silicon & post-silicon embedded software development, RTL verification, co-simulation, co-emulation. These models can integrate with all the tools required in the entire ESL design & verification flow. Support for new tools can be added without having to update the model code. The maiden edition of DVConIndia is happening over Sep 25-26, 2014 in Hotel Park Plaza, Marathalli, Bangalore. The India SystemC User Group (ISCUG) annual get-together, successfully conducted over the last couple of years, has transformed into ESL track at #DVConIndia. The two day conference in Bangalore provides an excellent platform to share knowledge, experience and best practices covering Electronic System Level Design & Verification for IP (Intellectual Property) and SoC (System on a Chip), VIP (VIrtual Platform) development and Virtual Prototyping for Embedded Software development and debug.
Getting ready for this event allowed me to reminiscence on how I came by SystemC and how it proves to be a useful tool in the modeling armory of a Simulation developer. Before SystemC I would like to touch upon my experience/observation of over a decade in Simulation Team in a leading Semiconductor MNC. In-house modeling methodology (based on C/C++) was used to model IPs/SoCs geared towards:
Typically there were two model variants – functional and cycle-accurate, depending on the use case. The majority of the models were functional (with no/limited timing information) and the remaining cycle-accurate. The functional/cycle-accurate models were not plug-n-play due to differing interfaces, especially on the memory-bus front. This arrangement seemingly worked well and was tailored towards the specific needs of the company. Advantage Modeling Modeling helped cut project risks by front loading concerns on system performance, specification ambiguity as well as provided an early software development platform - that allowed software to be ready even before the SoC was available in board form. It was also considerably cheaper and faster as compared to hardware emulators. Every software developer had their own simulation platform for development on their humble laptop; and the suite of tools available for tracing, profiling and debugging - aided quicker development and debugging cycles. Roadblocks for Scaling As the benefits of modeling started spreading, many business-units wanted to begin and/or leverage modeling for their projects. So what options were evaluated for modeling? Start their own modeling team
Delegate modeling to Specialized Modeling Team (our team) within the company
Service model with third party contractor
Outsource modeling development to tool vendors
Enter SystemC SystemC has been around since around 2000 but didn’t interest us as the internal simulation technology was considered to be superior to SystemC in terms of both speed and functionality. But things began to change at a rapid clip around 2007-2008 when SystemC v2.2 was released along with ground breaking TLM2.0 (Transaction Level Modeling) methodology for memory-mapped bus modeling. The feature set and flexibility offered by this combination in terms of modeling abstraction and communication proved to be a game changer. Developed as a C++ class library, all it required was humble C++ compiler to get started – No costly tools/licenses. What started as a trickle quickly gushed forth as a stream and quickly engulfed the modeling world. The best of companies from the EDA, Semiconductor and Services world joined hands to develop this standard further. Advantage SystemC
The warts
Future Trends For the first time it is now possible to use a single language (SystemC) to design all the way from Architecture Evaluation stage to Verification and Synthesis. This greatly enhances the productivity of the engineering teams involved in the semiconductor food chain. SystemC is taking early steps in synthesis of IP designs coded in SystemC rather than the more traditional Verilog/VHDL. SystemC with UVM is slowing emerging as a contender in the Verification/Validation space. The ability to reuse TLM test cases used for Virtual Platforms for Synthesis designs is a productivity booster. SystemC-AMS is filling the gap in terms of Analog modeling and Mixed-signal design space. A strong start has been made and we’ll have to see what direction it takes from here. IPXACT (IEEE-1685) XML standard for describing IPs (registers, memory maps, interfaces etc.) has been leveraged from System Integration IDEs to automated code and test case generators and has resulted in higher productivity and interoperability of IP models. Further standardization in the tool space is happening with the SystemC-CCI (Configuration, Control and Inspection) space by providing a standardized interface to configure SystemC IP models. The Configuration section has made considerable progress. Control and Inspection aspects are expected to follow suit. ISCUG to DVCon ISCUG 2012 (Bangalore) and ISCUG 2013 (Noida) provided a great meeting place for companies invested in modeling and to share notes and listen to leading voices in the ESL domain. Henceforth ISCUG has been integrated as one of the two tracks at DVCon India (Bangalore), the other being Design-Verification. As a member of the Technical Program Committee, it was heartening to see the high quality of papers submitted and the wide range of problems that are being tackled using SystemC. Apart from paper presentations, Panel Discussions on topics highly relevant to the participants are being planned. Invited talks from industry leaders, multiple tutorials on Accellera standards and Poster presentations are also in the cards. Bengaluru Banni As monsoon recedes and winter peeps its head, the cool Bangalore weather welcomes you to come and explore its many wonders including DVCon.in. Looking forward to seeing you there! /Swami |
Archives
July 2020
Categories
All
|
RSS Feed