Latest from DAC: Open SystemC Initiative launches transaction-level modeling standard v2.0

With some fanfare, the Open SystemC Initiative (OSCI) this week released its TLM 2.0 standard. The culmination of about three years of fact finding, feedback collection, proposing and testing, the version-2 standard represents what one system-level modeling engineer described as "the birth of ESL." With perhaps more reserved enthusiasm, a panel of SystemC users discussed the practical value of the new standard, the uses they intend for it in their organizations, and the issues they still have with this version.

The panelists represented a cross-section of the user community–rather than the vendor community–and included a couple of rather surprising organizations. Not surprisingly, Qualcomm was there, represented by principal engineer Tauseef Kazi. Perhaps more surprising were Rambus, in the person of director of engineering Prakash Rashinkar, and Xilinx, represented by senior manager of the performance analysis and verification team Adam Donlin. And to the surprise of many who don’t think of Intel as an SoC company, there was Ken Tallo, director of virtual platforms for the SoC Enabling Group at the CPU giant.

By way of introduction, TLM 2.0 is a standard set of SystemC APIs for modeling the interconnect and transactions between SystemC modules. Of course SystemC is perfectly capable of modeling transactions without a set of APIs. But the purpose of TLM 2.0 is to create a standard transaction-level interface between models. This should make it possible for models written at different times and places to interoperate. And, the OSCI people emphasized, it should lead as well to tool interoperability, by providing a standard by which different kinds of simulation or emulation tools could pass transactions among themselves.

Asked about their plans, if any, to actually use TLM 2.0, all the panelists said they had firm plans to employ it. Rambus’s Rashinkar, for example, said that Rambus has been providing several levels of functional models of their high-speed I/O IP to customers for some time. "Initially, we tried to do everything in Verilog, but there were serious problems," Rashinkar said. So the company moved to providing ESL models, despite the lack of a standard common to themselves and their customers. Now, Rashinkar said, most Rambus customers are saying they will adopt TLM 2.0 for the functional models and for performance estimation, and Rambus will provide their models in the TLM 2.0 format.

The other panelists made similar statements. "We hope TLM 2.0 will be the basis for model exchange between our in-house developers and our vendor-supplied tools," Kazi said. Intel’s Tallo pointed out that one important aspect of the standard is that it can allow rapid assembly of models into virtual platforms so that software development teams can start work long before the existence of detailed systems models in System Verilog or RTL. And Xilinx’s Donlin added that TLM 2.0 provided a sufficiently flexible framework in which to perform architectural analysis, reusing models when possible.

The panelists did have some concerns, however, and many related to the tension between the needs of software developers, who can be happy with a simple, memory-mapped-system-bus view of the world, and architects, who need to explore a variety of architectural concepts—not necessary bus-centric—and to observe and control their models at a more structural level.

Panelists pointed out that in the introductory material to TLM 2.0 it says that the standard is not intended to produce cycle-accurate or timing-accurate models. There are provisions for what the standard calls loosely-timed and approximately-timed models. "But these are really coding styles, not mechanisms," Donlin warned. There is no clear plan for using TLM 2.0 to move from untimed transaction models to cycle-accurate models. Kazi said that this lack will not be a problem for the software developers, but could be a challenge for architects. "We are using our own proprietary APIs for performance analysis. This is missing from 2.0, and we will have to add it," he said. "Also, for our purposes, it is important to be able to calibrate timing estimates from TLMs against timing from RTL. That is a facility we will add as well." In contrast, Rashinkar said that Rambus was doing performance estimates of customer I/O subsystems using the 2.0 standard as it is, and seeing about 90 percent accuracy.

Donlin gave a good reason why the TLM 2.0 group shouldn’t rush down the path to full cycle-accuracy. "We started working with cycle-accurate SystemC models," he related. "It turned out that we simply didn’t have the computing horsepower in the company to answer system-level performance questions by simulating at that level."

An audience member raised the question of compliance testing, leading to considerable discussion but no ready answers. "It’s really the responsibility of the model writers and users to determine correctness today," Tallo admitted. In response to a question from the panel, an unidentified member of ARM in the audience stated that ARM is already in the process of upgrading its AXI and AHB models and compliance tests to TLM 2.0, so in at least that case a model developer is stepping up to the validation question. But this clearly leaves room for an organization or a company to assume the mantle of TLM 2.0 model compliance certification.

Asked what was sufficient accuracy for a transaction-level model to be useful, the panel produced a nuanced range of answers. Intel’s Tallo said "Most of our software developers are ecstatic to get anything that lets them start earlier. We have demonstrated the ability to find software bugs a full quarter earlier by using ESL models." But Kazi added that this enthusiasm waned as you moved from operating-system or application developers down toward device-driver developers. "At the lower levels the software people want accuracy, even over speed," he said. "They even want their models to capture the RTL bugs accurately. The goal is to have no surprises when you plug the software into the chip for the first time."

One skeptical listener pointed out that in the three years that OSCI had been working on TLM 2.0, his company had implemented a full, cycle-accurate modeling system on its own. "What should I do now?" he asked. "Retrofit my software to comply with 2.0, with all the issues you have discussed, or wait for some 3.0 in the future?" The panel was unanimous in recommending that the user should move to 2.0 now—to gain access to the community of system-level models that will grow around the TLM 2.0 standard, to gain experience with the concepts, and—more than likely—to accomplish most of the work that would be necessary to move on to a future version of the standard.

Far from being an exercise in product promotion or end-of-project self-congratulation, the panel presented a candid look at the value of the TLM 2.0 specification, how it can be applied today, and what users may need to overly onto it in order to get the most out of this level of modeling. If TLM 2.0 is seen as robust enough to ignite an open market in reusable SystemC IP models, inducing the IP industry to finally add transaction-level functional views of their wares, then the most optimistic voice may be right: this could be the start of a real trend in ESL design. Even if it falls short of that goal, the panelists were unanimous in their beliefs, based on their experience, that 2.0 was very much worth adopting.

The specification, by the way, is now available for download from the OSCI site under the organization’s open license.