DVCon Europe: Getting TLM to cope with proliferating ECUs and serial protocols

A high-powered group has taken the wraps off work aimed at extending the transaction-level modeling standard, TLM2.0, to cope better with proliferating serial protocols and electronic control units (ECUs) in designs for the automotive and Internet of Things (IoT) markets.

The initial research has been undertaken by vendors STMicroelectronics and Infineon Technologies, systems giant Robert Bosch and EDA vendor Synopsys, among others. It was unveiled this week at DVCon Europe in Munich.

As these players’ names suggest, the original inspiration has come from challenges already facing automotive designers – however, they see the same problem extending into other areas.

TLM2.0 today contains no standards covering serial interfaces, rather focusing on memory-mapped bus protocols. This has meant that designers have to put “a lot of effort” into developing virtual prototypes where they want to conduct early verification in systems that contain multiple ECUs. These ECUs connect using a wide range of protocols, including Controller Area Network (CAN), Serial Peripheral Interface (SPI), I2C, Ethernet and FlexRay.

The new BMW 7-Series is a good example of how significant the problem is becoming. It contains 110 ECUs. That number is expected to increase rapidly as OEMs look to offer even smarter, more autonomous vehicles.

Bosch’s Martin Schnieringer said that a further complication is the varying ways in which protocols are used. “CAN [use] is well stabilized, but SPI is not. The topologies also differ: CAN’s is set, SPI’s is not.”

The group is taking a five-step approach to its work.

1. It has initially kept the R&D effort within a small group of suppliers but it is now reaching out to other partners.
2. It has identified a number of “real-world scenarios” for three of the standards (CAN, I2C and SPI).
3. The group’s members have independently developed code for the scenarios and compared these internally.
4. They have converged on single standard modeling code examples for each scenario/protocol.
5. They plan to donate the work to standards body Accellera, which administers TLM, and are now looking for other companies to join the project.

A CAN reset scenario developed by the team looking to extend TLM (Accellera Systems Initiative/DVCon Europe)

The task is tricky. The greatest efficiencies will be achieved, Schnieringer said, if the standard can be kept as simple as possible. It needs to be neither too generic nor too protocol-specific, but at the same time leverage as much re-use across different protocol models as possible.

Schnieringer gave a number of reasons why the work is also well-suited to IoT designs. These platforms can also involve connections between many different types of MCU and sensor, the validation of global systems with large numbers of use-case, and need standardization and interoperability across the tool flow.

The group has already drawn up some guidelines and internally developed prototypes based around agreed code. The guidelines are that the standard should:

• be SystemC-based (use ‘sc_port’);
• have a thin-interface layer with non-blocking calls (interfaces between models); and
• have a convenience layer to ease modeling and guarantees many rules by construction (interfaces with model developers)

Along with its outreach for other members, the group now also plans to begin similar processes addressing Ethernet and Flexray, among other protocols.