SystemC allows this by easing the development of transaction level models (TLMs), which are system hardware components represented at a higher abstraction level than register-transfer level (RTL) models. Where RTL models carry more detail, like individual clock cycles, TLMs exchange data or execute events among components at the architectural level. In short, TLMs are intended for developing and validating that part of the system software that depends on the hardware.

Among the advantages of TLMs over RTL models is that they are easier to develop than their RTL counterparts, thus requiring fewer man-hours, and can be simulated 10,000 to 100,000 times faster; taking minutes and seconds rather than hours and days. As a result, actual software can run on a TLM-level block of IP. In contrast, RTL IP is too slow to execute code, even within an instruction set simulator. TLM is also useful because SoC design methodology requires that previously designed intellectual property (IP) be represented at high abstraction levels.

The savings in verification time afforded by TLMs can be compounded if engineers could use existing RTL test benches to verify the TLMs. Indeed, SoC design verification takes 60 to 70 percent of the total product development time and a significant part of the nonrecurring engineering costs — costs that consist of both the man-hours to develop test benches and any additional verification tools needed.

In addition, designers are apt to have more confidence in a TLM-based IP block that is verified by the same test bench used to verify the block's RTL model. That confidence can fuel greater use of TLMs in the design flow, helping to bridge the gap between early SoC designs and their RTL representations. Future work in the area of reusing RTL test benches to verify TLM blocks will focus on fully automating the process, and including automatic fault checking.

A number of tools are available to cut the time needed for verifying HDL models. These include Specman Elite from Verisity Design, Inc.; TestBuilder, an open source program from Cadence Design Systems, Inc.; and VERA from Synopsys, Inc. Verification tools for SystemC designs, however, like the Open SystemC Initiative's verification library, are only starting to appear and will take time to mature, making the case for reusing RTL test benches even more compelling.

Conventional verification
Except in cases where specific HDL tools differ, the conventional approach to verifying a design relies on connecting that design to a stimulus generator and checker. The generator issues "threads" that write signals to the design, while the checker verifies the system's response. In addition, event constructs declared on top of the generator-implementation file serve to synchronize the different threads (Fig. 1).

Among the benefits of this method: the development and verification languages are the same, thus easing the learning curve; small, specific tests are easy to write; and no additional verification tools are needed, capping cost. Also, once developed, test benches can serve as examples, albeit simplified ones, of actual system software, which can give a head start to embedded software designers. The downside is that writing test benches that serve as the foundation for the final software usually takes the skills (and expense) of an engineer who understands how the entire the systems works.

More to the point, developing exhaustive test benches for significant blocks of IP takes a lot of effort, time, and money. Moreover, it is hard to know when a test bench is fully testing a block. Hardware verification tools like Specman, TestBuilder, and VERA can help by automating part of the process, but effort and cost remain high.

An additional verification method involves writing softwarecalled an integration testthat checks the IP in a complete system. This approach requires that all IP models be available, but has the advantage of verifying the IP in the context of the whole system, engendering confidence that the blocks indeed work as designed.

These techniques are a necessary step in developing IP modeled as a TLM. But time can be saved by verifying the TLM block with the same test bench as that used at the RTL level. Such "recycling" of test benches is common in RTL-to-layout portion of the design flow.

In general, test benches at one level of abstraction can be used to verify IP models at a lower abstraction level (so-called top-down compatibility) but not so for the reverse. Yet it is in fact the reverse — bottom-up compatibility — that is called for to reuse RTL test benches for verifying TLM-level IP.

Before any IP can be verified, a designer should know how that IP is used, and once knowing that, decide what constitutes a high-quality test; that is, a test that is sufficiently comprehensive. In that regard, the quality required for a TLM block is such that the software written to run on that block will also run on the RTL-level model and, therefore, the actual system. Only then can the designer be sure the TLM and RTL model match. One way to ensure this is to run the RTL test benches on the TLM IP.

The two main issues to address in using RTL test benches to verify TLM IP are, first, that TLM and RTL models use different languages, and second, that the models are at different abstraction levels. At least two techniques are available to resolve these issues. It is worth noting, as well, that the same techniques can be used to verify an RTL model using a TLM test bench.

Recycling RTL test benches
The first technique for using an RTL test bench to verify an TLM block is to use the RTL model as a "golden" (that is, known-good) reference (Fig. 2). In this case, applying the same stimuli to both the RTL model and the TLM should produce exactly the same response at the transaction level — if the models correspond functionally.

At the start of this approach, the simulated RTL model's response to a previously developed test bench is probed at the model's interface to record the sequence of events. Next, these sequences are converted to transactions and events for comparison with the TLM's output for the same input. For instance, for bus signals, a designer can develop a tool based on a finite state-machine that converts bus control signals into TLM read and write transactions in terms of the bus protocol. Interrupts and similar signals can also be translated into events at the transaction level.

From these transactions and events, a designer can — using a script — develop a SystemC generator or test bench that activates the signals of the SystemC API (application programming interface). He or she can then compare the output of the SystemC TLM against the output sequences derived from RTL model.

As an example, consider the case of a timer model connected to ARM Ltd.'s AMBA on-chip bus. The first step is to run HDL (hardware description language) test benches on the timer's RTL model, and use an analysis tool to probe the bus signals and interrupts that make up the timer interface. An analysis tool can be forged using TestBuilder, which extracts signals in HDL and converts them to C++. Once in C++, the signal values are converted, using finite-state machine code, to AMBA bus transactions and recorded. Interrupt signals that change value are also recorded. In particular, any interrupt that occurs during a read-write transaction is recorded after that transaction.

A sample file shows the sequence of stored transaction and events; that is, the read-write and interrupt operations (Listing 1). Using a script, the file is converted to a SystemC test bench (Listing 2). For example, for read and write transactions, the script respectively reads and writes data to the same address as the RTL test bench, and compares the results with the HDL values. If the values, as well as any interrupts, are the same, the TLM passes muster.

This sample file contains the results of using an analysis tool to probe an RTL model's response to its test bench. Once translated to C or C++, the response signals are converted to transactions using finite-state machine code. These transactions, as well as interrupt information, are also stored in the file.

The file in Listing 1 is the foundation for a script that produces the SystemC test bench shown here. The listing shown here represents a read-write operation executed using a TLM API. The SystemC test bench, in turn, is used to verify the TLM, which is done by comparing the interface signals with that of the 'golden' RTL model.

An imperfect world
It is possible, however, that — even if the TLM is correctthe sequential change of values following an interrupt might not match those at the TLM's interface. In this case, a manual check is needed. For example, in the case of the timer, the designer may find that in the HDL model, an interrupt happens after 10 read operations, but arrives earlier or later in the TLM version. The problem is that TLMs lack the highly accurate timing of an RTL model. Clearly, any checking software would consider this to be a failure, requiring a manual analysis to show that the TLM block is in fact behaving correctly.

In another example, it is possible that the data read during a TLM transaction fails to match that at the RTL level. Again, the cause would likely be the TLM's lack of timing accuracy rather than it being a flawed model. That would certainly be the case, given the TLM's inaccurate timing of interrupts, if the HDL model performs continuous reads until an interrupt happens.

Another case of the read or write sequence not matching would be in the case of nonassociated inputs. For example, suppose in the RTL model, the first of several write operations to registers products a particular output, X, after 10 cycles. In addition, suppose that during those 10 cycles, read and write operations to other registers occur before the output X is recorded. In the case of the TLM, however, the output X could occur and be recorded at once, flagging what is ostensibly a failed model.

Each of these cases would have to be investigated and resolved manually, adding to the verification effort and cost. In the case of the ARM timer block, verification using RTL test benches would take about five man-days. The effort needed to verify other ARM function blocks (called PrimeCells by ARM) using TLMs is given in Table 1.

Note: DMA: Direct Memory-Access Controller, VIC: Vectored Interrupt Controller, RTC: Real-Time Clock

In some cases, an RTL test bench may be unsuitable for use on a TLM block. Examples would include timing test benches, which focus on timing conditions rather functionality. That said, however, such test benches can serve to calibrate timed TLMs. Another class of unsuitable test benches are those that test communication protocols, including bus protocols and handshaking. Such operations occur at too low of a level for TLMs, which do not model protocols for read and write operations. Still another form of unsuitable test bench are those that produce "don't care" states.

In summary, this approach to reusing RTL test benches ensures that TLM blocks produce, for a given input, the same output as RTL models. If the inputs are exhaustive in verifying the RTL model, a SystemC TLM that produces the same outputs as the RTL model can be assumed to have the same functionality. Moreover, since most if not all the RTL test benches can be reused, development costs are minimized.

On the downside, as mentioned, timing mismatches can occur between the TLM and RTL model, calling for some manual effort. Also, the scripts and any other software for converting RTL signals into transactions may have to modified for IP models that have nonstandard interfaces. Fortunately, in practice, most interfaces in an SoC design are standard bus types.

An alternate approach
A second technique for reusing RTL test benches to validate TLM blocks is to cosimulate SystemC and HDL models using a tool that allows mixed language simulations. The main advantage of this approach is that it obviates the need to first run stimuli on the RTL models and then convert them to SystemC test benches using a script. Nevertheless, the conversion to the higher abstraction level using cosimulation is not a trivial effort.

Specifically, cosimulation uses an extra SystemC block, called a wrapper, that converts bus signals into TLM read and write transactions. Other system signals, like interrupts, can connect directly to the TLM block using SystemC signals. A problem arises, however, because most RTL test benches take timing into account. As a result, the RTL test bench will expect the TLM block to respond to an input signal within a given time or else declare a test failure. For this reason, either the RTL test benches must be modified to ignore timing or the TLM and RTL interfaces must be adjusted to have the same timing.

Still, RTL and TLM cosimulation is well suited to meet several tasks beyond the verification of TLM blocks. For example, SystemC TLMs can serve as a test bench for verifying RTL models. In this case, because a SystemC test bench lacks the timing accuracy of RTL models, it must be designed to check the functional occurrence of events rather than their timing.

Also, RTL and TLM cosimulation can test the entire SoC platform's embedded software, even if not all the TLM blocks are ready. In this way, a designer can write that part of the embedded software that needs hardware timing information. One limitation of this technique is the time it takes to simulate RTL. Because code size tends to be small, however, this is a workable approach.

Rohit Jindal and Kshitiz Jain are design engineers at STMicroelectronics' Central Research and Development laboratory in New Delhi, India, specializing in system level design methodologies.