While staying at my parents’ house in Ghent, Belgium, over the weekend, my mother reminded me to take some of my scale car models back to California. The parallel between these car models and transaction-level models is quite interesting. Only for the well know, typically expensive, cars, scale models are being sold. This is not unlike transaction-level models. There are models for the well know, and more expensive, processor and interconnect IP. But it is harder to find models for the many variants of peripheral IP, like I2C, I2S or sensors. So how to get models for these other IP blocks in your design? What if you really need a model of the Toyota Camry of IP? The good thing is that the building blocks for a lot of peripheral models are pretty common: a set of registers, a bus interface and some functionality. The other parallel is that the outside of the scale car models is typically very solid and detailed while the inside is typically made of plastic and a lot less detailed. The same is true for functional transaction-level models where, to ensure high simulation speeds, only whatever is required for the software to correctly interface with the models is modeled plus some well defined bus interface.

This brings us to some coding guideline tips. Based on which use case is the target (e.g., software development, software performance analysis, architectural analysis or hardware verification), a model needs the right coding style and abstraction. For software development TLM-2.0 Loosely Timed (LT) coding style is the preferred coding style to create models for virtual prototypes. SCML2 further refines the LT coding style by providing a coding style that is based on the separation of communication, behavior, and timing. SCML2 adds modeling objects that provide an implementation of the key TLM-2.0 semantics but also takes care of handling the speed and visibility requirements of the use case. When developing a model of an IP block, it is important to create the model so that each of these aspects is an independent element, or in other words, so that the model is decomposed into orthogonal properties. The following figure illustrates this coding style. Each element in the figure represents a modeling object or a piece of user code for a target component model.

Figure 1 – Target model coding style

The following explains the separation of communication, behavior, and timing in detail:

1. The interface to the interconnect model is separated from the actual behavior of the component. For the behavior of the component, a generic TLM2.0 memory-mapped bus interface can be used. The standard defines a generic protocol which is independent of any actual interconnect implementation. The standard provides an extension mechanism to define proprietary protocols based on TLM2.0. The interface between the extended protocol and the generic TLM2.0 protocol used by the SCML2 storage objects is implemented by a protocol adaptation layer.
2. The actual behavior of the component can be separated into a storage and synchronization layer (the internal registers or buffers) and the pure functional behavior of the model (the algorithm or state machine of the component). The storage and synchronization layer communicates through the generic TLM2.0 interface to the protocol adaptation layer and provides an entry point to the component model.
3. Finally, the different needs in timing accuracy can be addressed by separating the code that models the timing of the component from the pure functional behavior. SCML2 supports this separation by providing modeling objects for each of these layers.

For more information on transaction-level modeling using SCML see the forum topic with that name at http://www.tlmcentral.com/forum/Room/Topic/?topicId=17

So while you might not always find the right model your are looking for off the shelf, the building blocks do exist. And if everyone builds models for the IP blocks in their design we will get one step closer to proliferating virtual prototyping and benefit from its advantages for early and more productive software development.