Defining the TLM-to-RTL Design Flow

Drivers for change
The advancement of the chip manufacturing technology with process nodes moving from 130nm to 90nm to 65nm and even smaller geometries have an impact on chips on the drawing boards today, and render as ineffective an RTL-only flow as ineffective. This is due to:

• SoC size: RTL simulation is too slow to fully analyze and verify the chip. This can be addressed through:

  1. Hardware-based simulation: that is, emulation such as ZeBu (Zero Bugs) from EVE or acceleration
  2. Raising the abstraction level: moving the design description to a higher level abstraction to perform design analysis and verification tasks
• SoC complexity: This requires an RTL-only flow to deal with many details to perform architectural analysis. It also requires the ability to manage massive amounts of data. Moreover, decisions can only be validated late in the process after all of the RTL code is available. The way to address this is:
  1. Raise the abstraction level of the design description, and create more abstract models of the target chip early in the project
  2. Ensure availability of matching RTL blocks for these models
• SOC software: Software content is increasing rapidly. Design teams need to ensure the availability of an accurate software execution engine early in the project to ensure that software is not the schedule bottleneck for product release. Typically, software developers need less than five millions instruction-per-second (ips) simulation speed and a complete model. These needs can be addressed in two ways:
  1. Through the use of an abstract, yet accurate software model of the target chip or virtual prototype and the stimulus environment
  2. Through the use of the actual RTL model mapped into a hardware box. Design teams use a transaction-level software model of the stimulus environment or use hardware interfaces

The semiconductor industry has responded to these challenges is by applying the concept of platform-based design "" an approach to rapidly create chips comprised of a set of configurable application/domain specific IP, on-chip-buses and software. An example is the OMAP family of platforms from Texas Instruments.
While platform-based design addresses SoC complexity, verification and software remain bottlenecks or worse. It may be that a new derivative product could be conceived in a relative short time, while the completed chip including embedded software will have to be validated before signoff.
In wireless applications, where software has become the dominant factor impacting the product schedule, companies have spend millions to create software models or virtual prototypes of their application platforms, enabling them to distribute these models to hundreds of developers before actual hardware prototypes are available.

TLM is the "Right" Level of Abstraction
Different teams in a design project -- architects, verification engineers and software developers -- have a need for high-speed, abstract models of the target platform/chip. Each has a different requirement. Referred to as the abstraction-level (above RTL), they use it as Transaction-Level Modeling (TLM) for:

• Verification: cycle-accurate modeling (~ 100k cps)
  Since the TLM result compares to RTL code and RTL code needs to be included in simulation, models need to have cycle-accurate interfaces.
• Architects: cycle approximate (~ 1M ips)
  Since they need an accurate hardware model and require a decent amount of software to be executed, architects often use cycle-approximate models because they run faster than a cycle accurate model and are quicker to develop.
• Software developers: function accurate (10-100M ips)
  Software developers are not interested in the hardware model. They want an execution engine or virtual prototype that corresponds to the final hardware or prototype.

Since these three groups have little interaction, it is typical that multiple and not necessarily mutually consistent models are developed. The architect develops or buys a cycle-approximate model, where the software developer subcontracts for a functionally accurate virtual prototype.

The cost of TLM models
Developing and maintaining TLM models is often perceived as an added cost. Typically, cycle-accurate models are the most expensive to develop, followed by cycle approximate and then functionally accurate. In Figure 1, the approximate "useful life" of a model is shown as part of the product development cycle. It highlights the window of opportunity for these models, as well as the importance of availability of these models.
Since both cycle-approximate and cycle-accurate models are based on a structural modeling style "" buses, processors and peripherals are modeled as individual components and connected in SystemC "" they are reusable and typically are developed by IP vendors. Specifically, cycle accurate-models require detailed information of the architecture. They may take up to 30% of the cost of developing RTL code.
Conversely, SoC functional models/virtual prototypes are built from separate software modules and are delivered as a monolithic software model "" a single executable where software can be developed and debugged.
Complete functional platforms are faster and cheaper to develop than cycle accurate/approximate models. Companies that develop these virtual prototypes have developed their own proprietary modeling style to ensure high simulation speed and provide automation for building comprehensive platforms for timely availability.
Reuse of models across multiple projects is a must and major semiconductor and systems companies are building comprehensive TLM-centric modeling infrastructures to garner TLM's benefits.

The semiconductor industry is at a point where many realize that standardization of TLM modeling across multiple accuracy levels is important. While OSCI and SPIRIT are focused on establishing industry-wide TLM related standards, many proprietary incarnations of TLM exist because it offers a competitive advantage.