OSCI aims for June with TLM 2.0 release
The Open SystemC Initiative (OSCI) is working to have the final version of the second major release of the transaction-level modelling (TLM) standard ready in time for the Design Automation Conference (DAC) in June.
Mike Meredith, president of OSCI, said at last week’s Design Automation and Test in Europe (DATE) conference that a meeting at the event indicated that the work on TLM 2.0 was reaching the point where a final release is possible. “The new chair of the working group seemed hell-bent on making sure that it was released in the DAC time frame,” he said.
“A bunch of folks spent a third of the day in a conference room here [at DATE],” continued Meredith. “It was a sign of the level of the commitment of the members of the working group.”
Since work started a couple of years ago on a standard intended to improve interoperability for system-level models of hardware blocks, TLM 2.0 has run into delays. “On the whole, the goals of the TLM 2.0 effort were pretty ambitious,” Meredith argued. “This TLM-simulation world is no different from the world of board-level simulation 12 years ago.”
The TLM 2.0 process has been through a series of changes after initial drafts of the standard were provided to the public.
“Last year, in January, we released the first TLM 2.0 draft and got a great load of feedback,” Meredith explained. “We realised that the scope of the thing needed to change. Accommodating that growth took the best part of a year.”
Late last year, OSCI provided a draft for the industry to look at: “We ran a public review until February . And got a pretty broad set of feedback from a dozen or fifteen different companies. Out of that, the TLM working group has been looking at that feedback.
“A lot of it was stuff that the group had looked at and made a decision on already. So we are not changing those aspects. Some of the feedback came in the form of suggestions that were good ideas but out of the scope of this round of standardisation. The result is that we are pretty close to agreement of what is going to be fixed,” said Meredith.
Since the release of TLM 1.0, users have been concerned about the lack of interoperability for the models they use. The initial standard provided a great deal of freedom that engineers could use to express the way that interconnects such as buses could have models. The result was that, in many cases, models from different companies intended to work with the same bus could not be used together without creating wrappers to map transactions from one modelling style to another. TLM 2.0 introduces a class called generic_payload aimed at modelling memory-mapped buses to reduce the confusion.
“The standard has been constructed in such a way that there are a number of ways to extend it. You can use it as-is or extend. You can get a certain level of interoperability or you can throw out the payload and throw away the interoperability. But that might be the right thing for you perhaps,” Meredith explained. “There are guidelines in the collateral material that outline what interoperability entails,” said Meredith.
A number of companies are working towards updating their models to TLM 2.0 compatibility, although some users expect to use custom wrappers to connect their internally developed models to those created by vendors.
Ian Mackintosh, president of interconnect standards group OCP-IP, said the members are backing TLM 2.0: “From the outset, a number of key members have been collaborating with OSCI. We were very much involved in the definition of TLM 2.0.
“We have shipped thousands of TLM kits overall. And we still have the best TLM kits in the world. Now, we have embarked on a programme to move to the next generation of TLM kits.
TLM 2.0 will be used in future generations of chip-design projects.