Using TLM virtual system prototype for hardware and software validation

By Alon Wintergreen |  No Comments  |  Posted: June 1, 2009
Topics/Categories: EDA - ESL  |  Tags: , , ,

The article describes how a methodology based around scalable transaction level modeling (TLM) techniques can be used to enable software design to begin far earlier in a design fl ow and thus allow companies to bring designs to market faster, particularly in time-sensitive sectors.

It is based on the creation of high-level hardware models that describe functionality in sufficient detail so that the software team can use them as a development platform, even if hardware design is in its earliest stages. Thus, software developers can even start application and fi rmware validation during the initial stages of the design, when changes are easiest, have the most impact on the characteristics of the fi nal design, and there is little risk of missing a market deadline.

In consumer electronics, missing a market window by even a few weeks can result in drastically limited sales. These cost- and schedule-sensitive applications are at the same time among the most challenging to create. Composed of complex hardware blocks, they typically include sophisticated digital circuitry coupled with large memories to provide advanced computational and multimedia capabilities. Frequently battery-powered, they have stringent power restrictions despite the demand for each generation to support ever more features and capabilities.

With all the complexity associated with the hardware, the software is also crucial to the competitive success of these products. The application software is often the key differentiator, allowing the system company to reap substantial profit margins. Software is also increasingly important with regard to the power and performance behavior of the hardware platform.

In traditional product development flows, the software team waits to validate their code on prototype hardware. While this approach worked well in the past, it fails under current technical and time-to-market pressures. According to industry research firm Venture Development Corporation, nearly 40% of project delays can be traced back to flaws in the system architecture design and specification. This problem exists because finding and fixing hardware/software design errors at the late, physical prototype stage is both very difficult and very time-consuming.

Moving hardware/software validation to an earlier point in the design flow enables both groups to quickly model their designs, assess the functionality and attributes of the entire system, and make changes that deliver huge returns in performance, power consumption and system size without endangering deadlines. The conclusion is clear: starting application software and firmware development against a high-level hardware model can save significant development time, and yield products that meet or exceed consumer expectations.

Conducting software validation earlier

A new system design methodology is emerging in response to this pressing need for hardware/software validation early in the design cycle. It is based on the creation of high-level hardware models that describe functionality in sufficient detail for the software team to use them as a development platform, even when hardware design is in its nascent stages. Thus, software developers can start application and firmware validation during the initial stages of the design cycle, where changes are easiest, have the most impact on the characteristics of the final design, and raise little risk of jeopardizing the product launch date.

The methodology is based on a scalable transactional level modeling (TLM) concept that describes the hardware in SystemC. It provides benefits during both hardware and software development. Not only can the software team begin coding much earlier, but TLM hardware descriptions also provide much faster verification times—100x or more. On the hardware side, TLM allows for compact descriptions because the hardware system blocks are captured at a higher level and communicate by function calls, not by detailed signals, significantly reducing simulation time.

The TLM model does not limit the design creativity of the hardware team. TLM allows the separation of functionality from implementation. Hence, instead of forcing engineers to commit to hardware specifics early in the design cycle, the model simply describes the functionality of the hardware, not the details of how the hardware achieves that functionality. It also enables incremental model fidelity for timing and power. In essence, the TLM model is independent of the hardware mechanics, allowing the hardware team to continually refine the design without having to constantly update the high-level virtual prototype. A scalable TLM approach separates function from interface, timing and power from function for incremental refinement, and aligns with hardware and software requirements for speed and fidelity (Figure 1).

At the same time, software development can align with hardware development from the very earliest stages, allowing system interaction issues to be identified and resolved from the outset, dramatically minimizing their potential impact on the schedule. As a result, this methodology moves software/hardware integration into the electronic system level (ESL).

Using the Programmer’s View for software application validation

TLM has several levels of abstraction, all of which support virtual prototyping and hardware/software co-design. However, there are some trade-offs involved.

The very highest level, known as the Programmer’s View (PV) level, is a good point at which to begin software validation. At this stage, the SystemC hardware description does not include any timing information and therefore the simulation performance is extremely efficient—at least 1000 times faster than at the RTL level. The TLM model contains sufficient information to describe the hardware functionality to support software application development. Interface declarations are included so the software can connect with the hardware side. Specifically, there are two kinds of interfaces.

The first is a high-level methods interface with which the software engineer can call in his program. The method will ‘run’ the hardware design and ‘returns’ with the result value.

The second is a bus-cycle-accurate interface based on memory-mapped registers on the hardware side, allowing the hardware and software sides to interact through read and write transactions along with interrupts. Such a hardware/software interface is achieved either by incorporating an instruction set simulator (ISS) or by using a host-mode technology that uses read/write implicit access. An implicit access captures all the accesses to hardware by identifying the memory space calls. It allows software to run on any host processor (rather than the target processor) and simplifies software programming because the software engineer does not need to instrument the code with any external API calls. Host-mode execution often offers much faster simulation with slightly less accuracy than using the traditional ISS.

The firmware development environment

Software teams have traditionally been forced to wait for a hardware prototype to develop the firmware because of the level of detail required for validation. However, this aspect of the hardware/software interaction can now be moved to much earlier in the design cycle by using TLM models. At this point, the hardware team should nevertheless introduce detailed timing information because of its potential influence over the behavior of the firmware.

The abstraction level is now bus-cycle-accurate, and here software engineers can decide if they want to work on the target OS (in this case they will use ISS models accompanied by the SW development tools) or on any host OS of their choice (in which case they will use bus-functional models and implicit-access functionality).

This enables the firmware code to interact through bus-functional models with the hardware design. Working in the host OS environment of choice using the cycle-accurate model, any read/write operation will be mapped to the hardware and interact with an actual address in the hardware. An example of this type of implicit access is:

*addr1 = value1; // write access to mapped address – addr1

value2 = *addr2; // read access from mapped address – addr2

There are several specific debugging functionalities for firmware-related verification tasks. For instance, the design team can manage both hardware and software environments in one IDE tool. They also can perform debugging operations such as assigning breakpoints on both sides, and perform hardware/software transaction debugging. And they can view all the transactions (read/write/interrupts) and associated information in between hardware and software and break on any specific types of transaction or its parameters.

Selecting hardware verification methods

When it comes to hardware verification and debug, one of two approaches is usually taken.

The first involves the use of ISS models and software development environments at the highest TLM level (fast ISS models) or at the cycle-accurate level as described earlier.

The second approach adopts the emulation of software threads within the SystemC hardware design. As opposed to the previous methods where software is linked through an ISS or host mode, here it is embedded within the hardware CPU model as additional SystemC threads that execute directly with the hardware in one simulation process.

This second option is used specifically for system performance exploration since it offers very high simulation speed while being less accurate with no support for an RTOS. In that approach, which is used mainly by system architects, it is also possible to use ‘token-based’ modeling, which allows high simulation performance.

In the first approach, the PV and the cycle-accurate model can also interact with SystemC verification solutions. They can be connected to existing ISS SystemC models, either at the PV level or cycle-accurate ISS solutions at TLM’s Verification View level. Software developers can work on the real target OS if the host-mode is not accurate enough for them. If the ISS model (or models) and associated software development tools can be fully synchronized with the SystemC hardware description of the system, the target software development can also start earlier in the design cycle.

In the second approach, we define a sub-level of abstraction, which is called the Architect’s View. It includes some timing information, simulates faster than cycle-accurate models, but is not as accurate. This level is mainly used by system architects for performance analysis. Here, the methodology includes a set of configurable hardware models at that abstraction level (e.g., generic buses, generic processor, generic DMA, data generators, etc.). Using this methodology, the system architect can define hardware and software partitioning as well as target processors, bus architectures and memory hierarchies. Equally important, he or she can add timing and power metrics.

This level also supports token-based modeling, an abstract high-level modeling method that uses tokens (or pointers) to represent the data structure, resulting in an exceptionally fast simulation performance, an important requirement for system performance analysis.

In addition, performance analysis functionalities can be used with custom models, so that system architects can run software emulation as a testbench for the system performance analysis task. Think of this as a software emulation that runs as SystemC threads and therefore it is part of the hardware simulation, but runs extremely fast. This capability can be used by the system architect at the highest level to find the best architecture. The tokens or pointers result in very accurate modeling for use in measuring system performance. The system engineer can manipulate the parameters of the different blocks and test various configurations and use cases until reaching the required performance.

Integrating development

In markets that are extremely sensitive to cost and schedule slips, hardware and software teams need to work together from the very outset to meet product launch windows. The emerging and scalable TLM methodology described above moves software and firmware validation to the earliest stages of the design cycle, benefiting both teams. Software designers can now validate their applications and firmware long before hardware prototypes are available. At the same time, the hardware team can concentrate on hardware refinement without having to continually update models for the software validation.

By aligning the software and hardware flows at the earliest point possible, this approach minimizes integration risks downstream in the design flow. The result is a significantly reduced threat of schedule slips even as the design team maximizes product differentiation. The use of scalable TLM models is a crucial step in bridging software and hardware design methodologies, bringing us closer to the ultimate goal: true concurrent design.

Mentor Graphics
Corporate Office
8005 SW Boeckman Rd
OR 97070

T: +1 800 547 3000

Comments are closed.


Synopsys Cadence Design Systems Siemens EDA
View All Sponsors