Model Report Card

By Ann Steffora Mutschler
From its perspective as a leader implementing system level design methodology, STMicroelectronics is uniquely positioned to discuss issues and challenges related to the use of models in a variety of use cases. System-Level Design had the opportunity recently to discuss challenges in the modeling space with Jean-Marc Chateau, director of ST’s SPT (System Platforms and Tools) group; Alain Clouard, manager of the System Platforms Group (SPG) part of SPT; Laurent Maillet-Contoz, team manager of system modeling technology and infrastructure, part of SPG; and Antoine Perrin, team manager for verification, validation and software platforms, part of SPG. What follows are excerpts from that discussion.

SLD: What is ST’s overall model approach?
Chateau: We have several types of things we need—not only one type of model to do system-level design with a full methodology and a full environment. There are transaction-level models that we need and that we purchase and develop internally, as well. Together we also need verification components, VIP we purchase, which are also models in a way, and we need also to have the IP-XACT view together with the models and the IP in order to assemble a full platform. In this platform we also need transactors between RTL and TLM, and therefore we have to purchase those transactors as well.
Clouard: We use models that are typically TLM models as reference models to generate expected data when verifying hardware—VHDL or Verilog RTL. We use these models as well as a virtual platform to develop either systems that can be run from the RTL verification or a virtual platform to develop the prediction software that could be shipped to the customer.

SLD: What are the issues today with transactors?
Perrin: Today for verification of the software or even for the architecture we need transactors and we need performance with this product. Today I run the RTL on the emulator or on the simulator. We need both types. We need a transactor that can run in pure simulation mode or coordination mode. Depending on the kind of protocol that we use, we develop this transactor internally or we can have it from a third party if they have it.
Chateau: Typically each emulator vendor is proposing a separate transactor—sometimes fully, sometimes partially. The problem I see today is I have to partition the same type of transactor from each vendor because it is proprietary to their emulator, while what Alain is developing with his team is generic and can be used on all, but we cannot do all transactors as well. Of course we would prefer to have to partition only one transactor per protocol for any type of machine, but today that is not the case. To be more precise, Mentor, Cadence and EVE have their own transactors that cannot be used with the other machines.

SLD: In terms of obtaining TLM models from outside vendors, are they providing what you need?
Clouard: For processor models, it’s not a secret that ST is using quite a lot of ARM processors and we have now for several years a good offering in processor models for the virtual platforms from ARM. We integrate their models into our virtual platforms. This is for fast simulation but we have very low need for performance estimation and no need for estimating the time the application will take on the chip. This is the most usage we have inside the company that is with models that are functionally representative. Performance estimates are another type of usage. We have concerns about having processor models that provide performance estimates—comple SoC performance estimates well ahead in the project that are not provided by ARM. This is not provided by other suppliers except Carbon, which is providing cycle-accurate processor models that we can embed in our TLM virtual platform. Carbon now has an offering to switch from flat transaction-level models to cycle-accurate models, which is a good step. But we still are looking for a supplier with an ARM-certified processor model that is fast and cycle-accurate or time-accurate enough and affordable. What we need for wide deployment is the combination of software platforms, the combination of some timing accuracy—not necessarily cycle accurate—but some timing accuracy. We also need fast speed for executing large portions of software, not only small benchmark code, and it has to be affordable for deployments by the software teams and system architects.

SLD: What kind of power information is available with models today?
Maillet-Contoz: There is at the moment no real representation of power information at the transactional level because TLM models include very loose timing information. You cannot associate cycle accurate power information into your very loose timing models. There are some ongoing R&D activities to cover that and to find a way to associate TLM functional models and other kinds of models that would deal with non-functional properties and particular power information, but that’s R&D activity now.

SLD: What about IP models?
Clouard: We develop our own library of our own IP. For the IP we purchase, the biggest IP vendor is Synopsys, which now has a large offering of TLM models that we have started to use, as well. But it’s not the case for many other vendors. ARM has TLM models for processors, but not for graphics. And Imagination, which is very popular in the mobile/smartphone/tablet world, also has no TLM models. In that case, we need to find a way to have a full platform either using emulation or Carbonizes the RTL. There is really a lack of TLM models.

SLD: Why are there no TLM models for graphics processors?
Clouard: Some suppliers are moving into the direction of having a C/C++ reference model first in their design team, which makes it possible for them in the future to provide System C/TLM wrapping of those reference models. So I think that will come. In the past, GPUs have been designed in a custom flow at each IP supplier.
Chateau: In general it will come when the IP is complex enough that they need to design it with a top-down flow starting with a model in TLM as a reference like we do for SoCs today with IP from ST. It is very important for us to have the TLM model and IP before the RTL because if it is a new IP that is not developed, and we are waiting for it from the vendor, the architect will need the TLM before the RTL. We need to synchronize both teams: the IP vendor team and the user in the system house team—synchronize on the same flow in order to get what we need, when we need it.

SLD: What are other issues with processor models or IP models that the vendors need to address?
Clouard: For sure, the interoperability of TLM models is not complete enough today.