Team ESL Blog

Creating SystemC TLM-2.0 Peripheral Models

TeamESL — Thu, 14 Jul 2011 18:00:00 GMT

Over two years ago, I made some experiments and raised some requirements for an effective Virtual Platform IP authoring tool. Even with the passage of time, some people seem to find it useful as I regularly get questions about it. It is more than time to give you an update, and the good news is that such a tool is now available as part of the new Cadence Virtual System Platform (VSP) product. One of the capabilities provided by the Virtual System Platform is a tool to enable easy authoring of Virtual Platform IP models.

Virtual Platform IP Authoring Requirements

One of the major challenges with peripheral IP authoring is to model and manage registers. Some IP may include tens of thousands of registers and hundreds of thousands of register fields, which can represent 80% to 90% of the model code. In addition, the IP developer may have to create multiple implementations of the model, each at different abstraction levels such as a TLM-2.0 model (LT and AT), a TLM synthesizable model or an RTL model.

All of these representations are likely to share the same set of registers, hence the need to have a unique, golden reference of the model registers from which the implementation models can be derived. For tool and IP interoperability reasons, this golden reference should be compliant to an existing standard. Hence the idea to use the IP-XACT (IEEE 1685) as the golden model to represent registers. For more details on IP-XACT for TLM refer to a recent Industry Insights article by Richard Goering.

IP-XACT supports all the major requirements for modelling IP register and memory banks. Its XML structure eases the processing of the metadata and the automation of the implementation code at various abstraction levels. SystemC Virtual Platform IP models are just one specific use case of IP-XACT, but it's interesting to look into the details of the specific requirements for SystemC IP model creation.

TLM-2.0 defines the main infrastructure for IP interoperability, but one thing it lacks is a standard representation of registers. Until a standard register representation becomes available the Virtual System Platform provides a class called sc_register.

Overview of tlmgen

The Virtual System Platform includes a TLM Generator, called tlmgen, that saves time and coding effort by automating the generation of SystemC TLM code, mainly for defining and accessing the registers, both from the bus and from the internal behavior of the model. In addition tlmgen provides the following:

Automatic generation of a SystemC testbench (implementing all the appropriate read and write sanity checks for each register) and a simple system connecting the testbench to the SystemC model
Automatic generation of a C testbench (implementing all the appropriate read and write sanity checks for each register) to be executed on a processor running as part of a virtual platform
Automatic generation of a build script to generate a shared library for this IP (to be linked by the platform integrator instantiating this IP)

The tlmgen solution is fully open. Not only you can get all of the above from an IP-XACT standard description, but the SystemC code that's generated relies on a SystemC register class delivered as source code to all Virtual System Platform users. It can therefore simulate on the OSCI simulator, but if you use Virtual System Platform to simulate and debug your code, you will be able to visualize the register descriptions and content at runtime.

Hands On

Let's put our hands on the keyboard, and check how much code can be automatically generated and check how useful and how easy to update and maintain the code is. For this article, I propose to create a SystemC TLM-2.0 un-timed model for the PL011 UART, starting from the same ARM specification I used in my previous experiment.

Modelling the Registers

The first step is to capture the registers. Virtual System Platform offers two options:

A simple Cadence proprietary format named Register Description Format (RDF)
An IP-XACT component XML description

The Cadence RDF format is a simple ASCII file, with a very simple grammar to describe each register and its fields and to describe a bank of registers with the base address for each.

Below is an example of a register bank for for the UART.

Each register in the register bank also has a description. Below shows the description of the UART data register.

One of the inputs for tlmgen is the specification of callback hooks in the register input format. These hooks are called PREAMBLE and POSTAMBLE. They indicate to the code generator that the user may want to add a specific functionality before and/or after a register access. For example, when writing to the DR register, the model should also write to TX field of the RIS register. In IP-XACT format the PREAMBLE and POSTAMBLE hooks are defined as register vendor extensions.You can see the example of postamble = RW in the picture above for the UART Data Register.

Below is an IP-XACT representation showing the vspExtensions and the equivalent POSTAMBLE for the UART Data Register.

Another nice feature of tlmgen is the ability to generate IP-XACT output from an RDF input file, thus letting the user start with a simple text register description format and automate the translation to the verbose IP-XACT XML format. This IP-XACT output can then be used later for platform assembly.

Generating the SystemC TLM model

This step can be mostly automated by the execution of tlmgen to take an IP-XACT (or RDF) input and generate the SystemC TLM output. The SystemC code generated includes a SystemC module skeleton that you can modify to add the specific functionality. This skeleton already includes the definition and implementation of registers, target socket, tlm transport methods and registers access functions.

Creating the HW IP is a two-step process:

1) Run the command:

% tlmgen -name uartPL011 -rdf uart_registers.rdl -simple

Or for IP-XACT input:

% tlmgen -name uartPL011 -ipxact uart_registers.xml -simple

This generates about 80% of the code for the UART. It includes the SystemC TLM-2.0 module skeleton for the model of the UART which derives from an automatically generated base class with all the registers defined, the target socket to access them and the implementation of the transport methods to access these registers.

2) Update the generated HW template code to match the UART behavior.

Once the base model is generated it's up to the model creator to add processes, add extra ports, and add the functionality inside the pre- and post-register access virtual methods. This completes the model functionality.

The advantage of using tlmgen is not only that you save writing code (and writing errors), but also that all the registers can be visualized at runtime.

Below is the register viewer which provides the values at runtime by automatically recognizing the sc_register class. This is very helpful for software engineers who spend much of their time reading, writing, shifting, ANDing, and ORing register bits to make the hardware do what it is supposed to do.

ECO Support

One of the issues with code generation from a golden source is the ability to manage (not lose) user modifications when the golden source needs to be modified. Let's assume one of the bit fields of the register of our UART IP needs to be modified. How should we propagate this change to the generated code? tlmgen solves this problem by generating a hierarchy of classes and virtual methods where the user functional code is localized in the top-most inherited class.

Whenever a change occurs in the golden register representation (RDF or IP-XACT), all of the base classes can be re-generated without loosing the user code. Moreover, most if the time, the user code does not need to change or needs very little and localized modification to include the new register change. Such an inheritance hierarchy of classes and virtual methods allow the user functional code to be localized, hence allowing reuse if the user code when the base classes have to be re-generated.

The flexibility of tlmgen also allows the user to choose the type of target interface generated depending on its usage. It could be a TLM-2.0 simple socket or multi passthrough socket or it could be a TLM-1.0 sc_export. In the tlmgen usage example above, the -simple option specifies a TLM-2.0 simple target socket.

Packaging the Virtual Platform IP Model

Like any other IP, a virtual platform IP needs to be packaged to be delivered to other internal or external groups. Such a package should be self-contained, versioned, and easy to plug into a system and easy to verify. The IP should therefore be delivered as a kit including hardware verification, software verification, APIs, documentation, and scripts.

Next Steps

You have now an effective, standard, and reusable solution to ease the modeling and validation of TLM-2.0 peripheral IP using tlmgen from VSP.

Many models created using tlmgen have been integrated in various Virtual Platforms. It has proven to not only save a lot if development time but it also significantly helps the platform creator and the embedded software developer to debug and fine tune their hardware and software models. It overcomes the blank page syndrome when it's time to create a new model and provides much of the needed structure and checking to help users learn TLM-2.0 very quickly. The good news is that it doesn't try to hide the details of TLM-2.0 from the user, but instead generates clean code that users can learn from.

So what else is needed to help the Virtual Platform Model creator's life?

More complex register specification should be supported. Some are already supported by IP-XACT, others need extensions to the standard, such as preamble and postamble, conditional registers, dependant registers. These are all being considered as IP-XACT enhancements within Accellera Working Groups. As with any automation there is always more code that can be automatically generated such as multiple target sockets (and multiple memory maps), initiator sockets, and reset or interrupt behaviour by further using the information recorded in IP-XACT.

Jean-Michel

This Team ESL article is provided by Jean-Michel Fernandez, Archtect for System Solutions. Jean-Michel has actively contributed to the definition of the TLM and IP-XACT standards.

Understanding Latency versus Throughput

TeamESL — Mon, 13 Sep 2010 17:00:00 GMT

One of the effects of adopting a High Level Synthesis design methodology is that the barrier between "Systems designers" and "Hardware designers" is substantially reduced if not totally eliminated. Suddenly, both "Systems designers" and "Hardware designers" are using not only the same input language to specify their models (C++ / System C) but they are also exposed to the same terminology. For this reason, "Hardware designers" are suddenly exposed to two terms to which they have had little or no exposure in the past.

The purpose of this post is to clarify two "systems" terms that are usually confused and sometimes used interchangeably: latency and throughput.

Definition of terms

Let us attempt to define those two terms:

Latency is the time required to perform some action or to produce some result. Latency is measured in units of time -- hours, minutes, seconds, nanoseconds or clock periods.

Throughput is the number of such actions executed or results produced per unit of time. This is measured in units of whatever is being produced (cars, motorcycles, I/O samples, memory words, iterations) per unit of time. The term "memory bandwidth" is sometimes used to specify the throughput of memory systems.

A simple example

The following manufacturing example should clarify these two concepts:

An assembly line is manufacturing cars. It takes eight hours to manufacture a car and that the factory produces one hundred and twenty cars per day.

The latency is: 8 hours.

The throughput is: 120 cars / day or 5 cars / hour.

A design example

Now that these two concepts are clear, let us apply these concepts to a problem "closer to home."

A designer is given the task to create hardware for a communications device that has the following characteristics:

Clock frequency:                                          100MHz
Time available to perform the computation:     1000ns
Throughput of the device:                            640 Mbits / second
Word width of each output:                            64 bits

Let us translate these requirements into latency and throughput measurements that are more meaningful from the point of view of the hardware designer.

Latency: 1000 ns = 1000 ns * (1 s / 10^9 ns ) * ( 100 * 10^6 clock periods/ 1s) = 10^11/10^9 = 100 clock periods.

Throughput = 640 Mbits / s = (640 * 10^6 bits/s) * (1 word / 64 bits) * ( 1 s / 100 * 10^6 clock periods) = 640 * 10^6 / 64 * 100 * 10^6 = 10 * 10 / 100 = 1 / 10 = 0.1 words / clock period.

The throughput could be read more conveniently as follows: "one word every 10 clock periods"

Latency expressed in clock periods, and throughput expressed in number of available clock cycles between words, are parameters that a designer can use to create the desired hardware according to the performance specifications.

A final clarification

Some tools do not express the throughput in units per unit of time but in clock periods. This is incorrect but commonly used because of convenience. Therefore some tools would report the throughput of our communication algorithm as 10.

This Team ESL posting is provided by Dr. Sergio Ramirez, Sr Staff Product Engineer for the C-to-Silicon Compiler high level synthesis product.

Webinar by XtremeEDA on system realization on September 8th

TeamESL — Mon, 06 Sep 2010 05:20:16 GMT

The first webinar in the series of webinars organized by Cadence with the System Realization Alliance partners is by XtremeEDA on September 8th at 10AM Pacific time. To register click here.

About the Webinar

Designing integrated circuits from RTL brought about a revolution in semiconductor design about 15 years ago. It was much simpler than assembling transistors by hand. The new methodology made it possible to hire people with less transistor/logic experience and qualifications to do the job of designing semiconductors. It also made it possible to use off-the-shelf IPs to reduce development overall effort. EDA companies provided tools that could read and write standardized languages and formats. All this gave a boost to the number of semiconductors available to system integrators and opened up a portal for creative devices.

However, design sizes have become so large now, that RTL based design approach has become cumbersome and time consuming. The need for increasing processing power and reducing form factor is forcing semiconductor design houses to integrate a lot of IPs in a single device. RTL based approach doesn't yield itself very well to early architectural analysis for such designs. How do you know you are not over-designing or under-designing your chip? Over-designing would mean more than necessary time and resources required to verify and implement the design. Under-designing would mean lost customer! How do you know that an algorithm should be in software or hardware and what would be the impact of such decisions?

Cadence's EDA360 Vision paper discusses the fact that semiconductor design is increasingly a software application driven process. Instead of designing the best possible product that works for everyone, we are increasingly moving to an era where SoCs are being designed to handle particular applications exceptionally well. This will increasingly require a System Realization or Electronic System Level (ESL) platform that allows you to create virtual prototypes of your systems and lets you do hw/sw trade-offs before you commit yourself to the hardware creation writing process, whether using an RTL approach, or more recently emerging high level synthesis.

XtremeEDA is our System Realization Alliance partner with extensive experience in providing ESL model development and verification services. XtremeEDA will be presenting their experiences with ESL in the first of the series of webinars on System Realization. You will get to hear why ESL has only recently begun to take off and how a good ESL methodology can make adoption of ESL techniques easier. By attending the webinar you will be qualified to win a copy of a book on SystemC and TLM Design and Verification that XtremeEDA is giving out.

A Classification of ESL - High Level Synthesis Tools

TeamESL — Thu, 06 Aug 2009 17:47:00 GMT

These days, there is a lot of talk of what the next design methodology for Digital Systems will be and how this methodology will be the replacement of RTL Synthesis. The term ESL (Electronic System Level) is used as a general term for the new wave of modeling and synthesis for digital systems.

We have noticed that the term ESL is a very different concept for different people. It might mean a modeling approach, a design approach or a combination of both. In this blog we are not attempting to define what ESL is, but we are trying to provide a brief classification of the different types of ESL / High Level Synthesis tools.

Before, we attempt to classify the different types of ESL / High Level Synthesis tools, let us, for the purpose of this blog, define an ESL / High Level Synthesis tool as follows:

“An ESL / High Level Synthesis Tool is a software tool that takes a high level description of a digital system and transforms this description into an RTL (Register Transfer Language) description in a language such as VHDL or Verilog.”

Additionally

“The RTL description synthesized by the ESL / High Level Synthesis tool must be synthesizable into a gate level netlist by an RTL Synthesis tool such as Cadence’s RC”.

Currently, there are three kinds of ESL Synthesis tools being marketed as follows:

The first kind are tools which take a graphical / data-flow description of the system and usually translate this description into “structural RTL” (a netlist of synthesizable block instances) which have been originally written in a parameterizable way.

The second kind are tools which take a single threaded computer programming language (usually C or C++ without support for threads) and translate this description into either a single synthesizable RTL block or into a structural pipeline of RTL blocks.

The thrid kind are tools which take a multi-threaded computer programming language (usually SystemC) and translate this description into a “structural RTL” description which can be an arbitrary netlist of synchronous state machines.

Cadence’s C-to-Silicon Compiler is an example of the third kind of ESL / High Level Synthesis tools. As said before, the basic characteristic of this kind of tools is support of multiple threads in a similar fashion that support for multiple processes (threads) is an inherent characteristic of RTL based synthesis tools and Hardware Description Languages.

Supporting multiple threads brings the following advantages:

Support of multiple clock environment in a similar way that RTL synthesis tools support multiple clocks.
Support of multiple concurrently executing blocks in a similar way that RTL synthesis tools support multiple processes (always blocks in Verilog or Process block in VHDL).
Support of multiple instances in a similar way that RTL synthesis tools support “structural” code.
Support of reactive blocks. This is usually not possible single threaded approaches.
Support of feedback loops. This is usually not possible, or difficult to implement in single threaded approaches.
Support of control structures. This is not usually possible in single threaded approaches or in graphics based approaches.
Support of non-sample based interfaces. Burst transfers and other type of interfaces usually require the implementation of reactive blocks such as DMAs. This is not possible in single threaded environments.
Support of Mealy style state machines. Mealy type state machines usually require two threads (one for the combinational logic and one for the registers), therefore they cannot be implemented in a single threaded environment.
Support of non-blocking constructs. All statements in a single threaded environment are blocking.

These advantages are what makes the third kind of ESL / High Level Synthesis tools the only viable alternative to RTL synthesis. Single threaded environments or graphics based data flow entry tools cannot, and probably never will, be able to describe a complete digital system as it is currently done with RTL based tools

This Team ESL posting is provided by Dr. Sergio Ramirez, Core Comp Architect for the C-to-Silicon Compiler high level synthesis product.

Full System vs Sub-system Virtual Prototyping

TeamESL — Thu, 06 Aug 2009 17:45:00 GMT

There is a strong movement in the industry to move to create Virtual Prototypes of systems, prior to RTL coding. These Virtual Prototypes are being used for early software development and architectural analysis. Since there are typically many blocks in a design, the development of a Virtual Prototype can be unwieldy. While you might have a goal of creating one, you may be dazed at the number of components that need to be created or acquired (multiple CPU's, DSP's, MPEG engines, multiple memory sub-systems, DMA's, etc.). Companies are realizing that they can successfully achieve productivity gains y working with sub-systems instead of full systems. After all, this is how many high-level design and verification tasks are done today (ie sub-system simulation on emulators, sub-system c models created for reference models, etc.). But what is the difference between a sub-system and a full system?

A sub-system generally is a well defined entity in your design. There are CPU sub-systems, memory sub-systems, disk sub-systems, etc. This systems are very complex in their own right and usually contain some form of processing unit (CPU, DSP, micro-controller, etc.). Below is a table that suggests some characteristics of a a sub-system vs a full-system:

The first advantage to creating a sub-system is that there are a smaller number of blocks to create or acquire. Looking at the table, you can see there are other advantages. Typically minimum performance requirements are lower then a full system. That is because lower level software is being executed, meaning less instructions, allowing reasonable simulation speeds will lower performance. Secondly, you will probably model sub-systems that you are most concerned about, which are the ones that you are creating. Therefore most of the models will be created rather then acquired. If you are using a TLM Driven flow (in which TLM models are the golden source for synthesis), then the TLM models for the platform need to be created anyway. If you aren't, then you should look at the productivity that such a flow provides.

Full system Virtual Platforms provide the ability to exercise complete functionality of a system. Creating one can take time in acquiring models, porting operating systems, developing applications, and making sure simulations speeds are fast enough to be productive. Sub-systems Virtual Platforms require less effort to create (less blocks, reuse TLM Design models), address a smaller problem (sub-system programming or analysis), and are less demanding on performance.

Leonard Drucker

Intel vs ARM - Did the Embedded Systems Conference India Shed Light on the Battle?

TeamESL — Wed, 05 Aug 2009 16:34:00 GMT

Being a Brit, Cricket is never very far from my thoughts especially when travelling to India, the biggest cricket mad nation in the world. There is a saying in cricket that you should always think of doing what the opposition would least like, a statement that applies in business too. I was on my way to present a session on Verifying Embedded SW Power Management” at the Embedded System Conference in Bangalore.

With the recent activity by Intel firstly joining forces with TSMC to deliver licensed Atom IP and also acquiring WindRiver, I was interested to see if there was further evidence of Intels mooted ambition to go head to head with ARM on deeply embedded systems at the conference. The Atom was well represented on the Microsoft Stand with local firm iWave displaying for the first time in public a fully integrated battery powered in-car Windows system running on Atom at 1.1/1.6GHz. Whilst this is an exciting step forward in terms of the physical profile of Atom systems the power consumption still pitches it someway above the top-end ARM Cortex A9.

I then headed into the Intel presentation itself and while mention was made of Atom there was a definite emphasis on the higher-end processors and especially the Virtualization technologies being incorporated to the server line. So is the predicted war between Intel and ARM a journalists wish to whip up a media storm or are the battlelines being drawn behind closed doors as Intel prepares an orchestrated attack?

As an outsider it would appear there are at least two barriers for Intel, the first is power consumption, no doubt technology shrinks will progressively improve this, however the Atom is unlikely to challenge for very low power designs. Secondly, there is a lack of a lower-end family to bootstrap embedded customers. Whilst ARM is winning customers on it’s Application Processor offerings, most SoCs have multiple processors of varying degrees of complexity; this is ARMs stronghold. Most deeply embedded products are evolutions of previous designs and integrations of sub-systems. For most customers their previous product offerings used a lower end ARM7 or ARM9 processor they can easily migrate or even incorporate an entire system as a sub-system inside a much bigger SoC.

I was pondering Intel’s lack of low power, lower-end licenseable processor IP last week when I returned from India only to hear the news that ARC is in discussions with a takeover candidate.

Could this be Intel bowling ARM a googly (curve-ball for all those who’d rather a baseball metaphor) ?

This TeamESL blog was provided by Nick Heaton, a Senior Solution Architect within the Cadence Front-End R&D organization, with specific responsibility for the Incisive Verification Kit. Nick is an industry veteran based in the UK with more than 25 years of SoC design and verification experience.

Customer Questions About TLM-driven Design and Verification

TeamESL — Mon, 27 Jul 2009 14:00:00 GMT

In the latest blog published by Ron Wilson there were two questions about our TLM-driven design and verification solution introduction. We would like to respond to these comments here:

1. "one line of SystemC generates three lines of RTL"

During our interview with Ron, we showed an example of one of our customers who wrote in parallel SystemC and RTL code. In this case the number of RTL code lines was 3X of the number of SystemC code lines and was based on control-centric design. Many customers report a much higher ratio. The SystemC source will mostly be untimed and not detail many of the low-level RTL requirements such as resource sharing and specific state machine. As such, it could be as small as 1/10th the size of the equivalent hand-written RTL (in the extreme cases, even smaller) for datapath-centric designs and 1/4th the size for control-centric designs. Abstracting away signals to use a TLM interface will also increase these ratios.

2. "Is the RTL OVM SystemVerilog or Verilog. Do we get to choose?"

It's not 100% clear whether you are asking "What language is the DUT that's output by C-to-Silicon?"; or based on your mention of OVM, whether you are asking about how testbenches relate to the code output by C-to-Silicon. Thus, allow us to provide answers from both a DUT and testbench angle -- let us know if we address your original question. First, from a DUT angle, The primary output of C-to-Silicon is IEEE-compliant synthesizable RTL Verilog. [Note the question is asking if this RTL is Verilog-95 or SystemVerilog --the answer is that it is v2k Verilog since it has to work on all downstream tools]. C-to-Silicon also can automatically wrap that RTL so it can be easily plugged-and-played into the higher-level design and/or testbench. W.r.t. to the testbench aspect of C-to-Silicon output: the architecture of OVM verification components is replicated across e, SV, and SystemC. Additionally, Cadence's IES-XL simulator supports e, SV, and SystemC -- and hence OVM -- so the choice of testbench for your C-to-Silicon created DUT is really up to you.

Team ESL

OVM Metric Driven Verification With an FPGA-based Design

TeamESL — Wed, 17 Jun 2009 19:30:00 GMT

During the last 2 years I have enjoyed the opportunity to work with the Incisive Software Extensions (ISX) with many customers. I learned a lot about software/hardware co-verification and we reached the point were we started to see beyond one’s own nose.

One of the substantial concepts of ISX is the generic software adapter. The accentuation here is the attribute 'generic'. The generic approach guaranties the freedom to connect almost everything that somehow drives embedded software. From this point of view it's very easy to build up a library of supported devices and reuse proven and customized adapters out of the box for convenience.

Is the generic concept a really proven one, mature enough to document a step by step approach? What are potential areas of using the ISX technology with the metric driven verification methodology apart from the simulation based mainstream?

The ISX installation explains, with the help of examples, the connection to the OpenRisc processor ork1 (http://www.opencores.org/openrisc) driven in a simulation environment, and the integration of Palladium and Xtreme boxes. There is an open question remaining: what is the effort and benefit to connect it to an arbitrary FPGA prototype board? This question comes up during our engagements with customers, and we looked for a chance to find a practical answer to it instead of the theoretical explanations we used so far.

In 2008 we embarked upon an ISX activity together with ElCamino (http://www.elcamino.de), a consulting company and partner of Cadence for many years. During our discussions we selected a ElCaminos FPGA training board and integrated it into a metric driven verification environment using ISX. The hardware was a low-cost, low-power Cyclone III FPGA from Altera combined with a LCD color touch panel for visualization driven by Specman testbench. The result was a small eyecatcher we introduced first time on CDNlive! in Munich this year.

Figure 1 - Altera FPGA Board

The demo vehicle proves that the generic adapter concept provides significant flexibility, and is a solid base to extend ISX into embedded software verification strategy.The integration effort for the selected board was not higher than the standard ISX simulation based project and no additional functionality needed to be added to the ISX tool itself to make this happen. The benefit of such an integration is the post silicon verification with existing fundamental verification methodology and the expected high reuse factor of any existing metric driven verification environment (MDV).

And finally the generic FPGA board support of ISX enables the introduction of MDV to the software verification world, which is revolutionary thinking from the software testing perspective.

More background information about this engagement will be provided in an upcoming blog interview with the ElCamino engineers, Ernst Zwingenberge and Malte Henzelmann, who supervised both the project at ElCamino.

This TeamESL posting was provided by Joerg Simon who is a CoreComp Verification Engineer at Cadence Design Systems where he is responsible for ESL product deployment, including hardware/software co-verifciation products and TLM methodology.

Way Worse Than The Real Thing

TeamESL — Tue, 19 May 2009 04:05:00 GMT

This week Cadence and Virtutech announced a collaborative effort to bring together the Virtutech Simics virtual platform with the Cadence ISX software testing system. This is a very interesting combination of technologies, clearly demonstrating how virtual platforms make it possible to test software in ways that are plain impossible on physical hardware. With a virtual platform, it is possible to systematically subject a system software stack to extreme (and normal) working conditions, trying to provoke errors and find conditions where the software breaks.

We are not just doing regular automated software testing as you would do any host, but also changing parameters for the hardware on which the software runs. In this particular example we are showing at CDNLive! EMEA, we have a time-to-result latency parameter that determines the time it takes for the hardware to issue an interrupt to the software. The software behaviors demonstrated with latencies at 1 ns and 1 s are quite different... in the fast case, the driver software needs to ensure it can handle an interrupt immediately after starting an operation. In the slow case, the driver has to put the calling process to sleep and wake it up later so that the rest of the system can go on working while we wait for the hardware unit to complete. Try doing that on hardware...

Some other obvious examples of how hardware can be controlled to stress software is to vary the number of processors, the speed of the processors, or the size of memory in a system. Isn't it interesting to find out what REALLY happens if you have 2^64 bytes of physical RAM? Will the OS suffer an integer overflow and report -2^63 bytes? Or if all processors run at different clock frequencies? It tends to reveal all kinds of bad assumptions in code. If you add in the ability to inject known bad results from hardware, or turning off units to simulate local hardware failures, you have a very powerful tool to exercise software correctness and robustness. Putting a space-bound computer board in a radiation chamber to check robustness for transient errors is not quite as easy as injecting a sprinkle of memory errors in a simulation.

Thinking about it... this is how hardware testing has always been done: create controlled experiments, often looking for corner cases. For software, that has not really been possible since the execution hardware was always fundamentally uncontrollable. But with a virtual platform, suddently the hardware becomes controllable. And the possibilities become boundless. The Cadence ISX integration with Virtutech Simics is just a first step, and we have only scratched the surface of a very exiting topic. The software that was used to have a nice and cushy environment to run needs to wake up and realize that it will be subject to something worse, way worse, than the real thing.

This Team ESL posting is provided by Dr. Jakob Engblom, Technical Marketing Manager for Virtutech. He holds an MSc in Computer Science and a PhD in Computer Systems from Uppsala University. He has been with Virtutech since 2002, and has worked with embedded software, real-time programming, and computer systems simulation for the past decade.