In today’s competitive consumer electronics, missing a market window by even a few weeks can result in drastically limited sales. These cost and schedule-sensitive applications, however, are among the most challenging to create. Composed of many complex hardware blocks they typically include sophisticated digital circuitry coupled with large memories to provide advanced computational and multimedia capabilities. And being battery powered, they have stringent power restrictions despite the fact that each generation supports 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 often is the key differentiator for these consumer products, allowing the system company to reap substantial profit margins. Software is also key in the power and performance behavior of the hardware platform.

INTRODUCTION

In today’s competitive consumer electronics, missing a market window by even a few weeks can result in drastically limited sales. These cost and schedule-sensitive applications, however, are among the most challenging to create. Composed of many complex hardware blocks they typically include sophisticated digital circuitry coupled with large memories to provide advanced computational and multimedia capabilities. And being battery powered, they have stringent power restrictions despite the fact that each generation supports 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 often is the key differentiator for these consumer products, allowing the system company to reap substantial profit margins. Software is also key in the power and performance behavior of the hardware platform.

With 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 percent 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 so difficult and time consuming.

Moving hardware/software validation earlier in the design flow enables both hardware designers and software developers to quickly model their designs, assess the functionality and design attributes of the entire system, and easily make changes that can pay huge performance, power consumption and system size dividends without endangering time-to-market 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 IN THE DESIGN CYCLE

A new system design methodology is emerging in response to this pressing need for earlier hardware/software validation. The approach is based on the creation of high-level hardware models that describe functionality in sufficient detail for the software team to use as a development platform at the earliest stages of hardware design. As a result, software developers can start their application and firmware validation from the initial stages of the design cycle, where changes are easiest and have the most impact on final design characteristics, and there is little risk of missing a market deadline.

The methodology is based on a scalable transactional level modeling (TLM) concept that describes the hardware in SystemC. A Scalable TLM approach provides benefits to both the hardware and software development. Not only can the software team begin coding much earlier in the design cycle, but TLM hardware descriptions provide much faster verification times – 100x or more – making it a viable solution for software development and validation.

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 also allows separating functionality from implementation. Hence, instead of forcing them 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 enabling 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.

At the same time, software development can align with the hardware development from the very earliest stages of the design cycle, allowing system interaction issues to be identified and resolved from the outset, dramatically minimizing the impact on the design schedule.

As a result, this methodology moves software/hardware integration into the electronic system level (ESL).

USING PROGRAMMER’S VIEW FOR SOFTWARE APPLICATION VALIDATION

TLM allow several abstraction levels, all of which support virtual prototyping and hardware/software. However, there are tradeoffs between TLM’s multiple abstraction levels. The very highest level of TLM, known as “Programmer’s View” (PV) level, is a good stage 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 1,000 times faster than at the RTLlevel. 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 hardware/software interface is achieved either by incorporating an ISS (Instruction Set Simulator) or using a host-mode technology which 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 simplifying the software programming since 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 vs. using the traditional ISS.

FIRMWARE DEVELOPMENT ENVIRONMENT

Traditionally software teams were forced to wait for a hardware prototype to develop the firmware because of the level of detail required for validation. However, using the TLM models this level of hardware/software interaction can now be moved up much earlier in the design cycle. At this point, the hardware team should “add” detailed timing information, since the behavior of the firmware can be influenced by the timing of the system.

Firmware development requires more accurate and detailed description of the hardware including timing information (in addition to the functionality description). Therefore the abstraction level is now bus-cycle-accurate. At that level software engineers can decide if they want to work on the target OS (in this case they will use ISS models accompanied with the SWdevelopment 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 a host operating system environment of choice (as described above) 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: 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 THE RIGHT HW VERIFICATION METHODS LINKED WITH SW

When it comes to HWverification and debug, there are two usual approaches to this phase: The first approach involves the usage of ISS models and software development environments at the highest TLM level (fast ISS models) or at the cycle-accurate level as described in the previous sections. The second approach is emulation of software threads within the SystemC hardware design. As opposed to the previous methods where SWis linked through an ISS or host mode, with this method SWis embedded within the HWCPU model as additional SystemC threads that execute directly with the HWin one simulation process. This is used specifically for system performance exploration since it offers very high simulation speed while being less accurate with no support of RTOS. In that approach, which is used mainly by system architects, it is also possible to use “token-based” modeling which allow high simulation performance.

In the first approach The PVand the cycle-accurate model can also interact with SystemC verification solutions. They can be connected to existing ISS SystemC models—either at the PVlevel or cycle- accurate ISS solutions at the “Verification view” level. Software developers can work on the real target operating system if the host-mode is not accurate enough for them. If the ISS model(s) 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 cycles.

In the second approach, we define a sub-level of abstraction which is called “Architects view” – which includes some timing information, simulates faster than cycle-accurate models, but is not as accurate as cycle-accurate models. This level is mainly used by system architects for performance analysis. Here, the methodology includes set of configurable hardware models at that abstraction level: 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, memory hierarchies. Equally important, the system architect can add in timing and power metrics. It also supports token-based modeling, an abstract high-level modeling method that uses “tokens” (pointers) to represent the data structure resulting in 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 testbench for their system performance analysis task. Think of it as a software emulation that runs as SystemC threads and therefore as 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 to meet the design requirements. The tokens or pointers result in very high accuracy modeling for measuring the performance of the system. The system engineer can manipulate the parameters of the different blocks and test various configurations and use cases until reaching the required performance.

INTEGRATING SOFTWARE AND HARDWARE DEVELOPMENT

In markets extremely sensitive to cost and schedule slips, such as consumer electronics, hardware and software teams need to work together from the very outset to meet market windows. The emerging scalable TLM methodology described above moves software and firmware validation to the earliest stages in the design cycle, benefiting both teams. Software designers can now validate their applications and firmware long before hardware prototype. At the same time, the hardware team can concentrate on hardware development 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 significantly reduced chance of schedule slips even as the design team maximizes their product’s differentiation. The use of scalable TLM models is a crucial step in bridging software and hardware design methodologies, bringing them closer together towards the ultimate goal of true concurrent design.

Authors:

Alon Wintergreen
Corporate Applications Engineer
alon_wintergreen@mentor.com

Rami Rachamim
Product Marketing Manager
rami_rachamim@mentor.com

Tags: ESL, Interface, IP, Memory, Methods, RF, Software, Tools, Verification

This entry was posted on Thursday, October 23rd, 2008 at 12:01 am and is filed under Resource Center, White Papers. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.