The 'what and why' of TLM

Advances in the physical properties of chips and in design tools make it possible to build huge systems into just a few square millimeters. The problem is that modeling these systems at the register-transfer level (RTL) is labor-intensive, and simulation run-times are so long they have become impractical. If this is a problem today, just imagine trying to design, integrate and verify the even more massive systems we will build 10 years from now.

Transaction-level models (TLMs) can help with design, integration and verification associated with large, complex systems. TLMs LET designers model hardware at a higher level of abstraction, helping to smooth integration by providing fast simulation and simplifying debugging during integration.

Designers start with parts at different levels of abstraction, often including algorithmic models written in pure ANSI C++. These models combine with a detailed specification of how they should be brought together into a system. Then the models are divided among several design teams for implementation into RTL. Other pieces--often most of the system--consist of existing blocks reused in the new design.

Algorithmic synthesis tools help RTL designers quickly implement new, original content for blocks. This creates a fast path from a collection of algorithms to a set of verified RTL blocks that need to be integrated. But any errors or misunderstanding in the specifications for the systems or for the intellectual-property (IP) blocks will still lead to a system that doesn't work.

Transaction-level models could simplify the integration and testing, but where to get the models? Attempts to manually create TLMs in SystemC by adding hardware details to the pure ANSI C++ source are often as error-prone and time-consuming as manually writing RTL.

While this effort is certainly justified for reusable blocks, someone still has to maintain these models. For the original signal-processing content, however, the best approach is for the algorithmic synthesis tool to simply generate the TLM models as part of the design and verification flow.

An added benefit of this approach is that system modeling and integration can now be used to refine each block in your system. Information gathered during integration is fed back into the algorithmic synthesis flow, allowing blocks to be reoptimized based on the system.

In RTL, simulation is usually synchronized based on a clock. Every event on the clock results in a point in time where all of the blocks in the system can synchronize. In a TLM, the synchronizations occur when data is communicated between two blocks, which means the clock is no longer needed for simulation. This communication is called a transaction.

A transaction is an aggregate of activity that occurs in a system in a bounded time period. The activity of interest begins at a particular time and ends some time later. All the operations, state changes, data movements and computations that occur in a particular design unit or between two units are transactions.

Transaction-level models represent components as a set of concurrent, communicating processes that calculate and represent their behavior. The models describe complex systems at a high level of abstraction. Models exchange communication as "transactions" through an abstract channel, separating communication from computation. Working at this higher level of abstraction speeds simulation--up to 1,000 times faster than RTL or cycle-accurate modeling. By modeling at the transaction level early in the design cycle, designers can find an optimal architecture before committing to low-level details of a complete implementation. During functional verification, engineers can reuse the TLMs to ensure that the detailed design is equivalent to the RTL implementation.