Transactional level as the new design and verification abstraction above RTL


by Bart Vanthournout, CoWare Inc.
Leuven, Belgium

Abstract:

In the context of todays increasingly complex SoC's there is a need for design methodologies that start at higher levels of abstraction. Transactional modeling can become this new abstraction level. In order to achieve this transactional modeling needs to provide a full solution above RTL and therefore it needs to bring enough value through high simulation speeds for system analysis and configuration, and to provide a solution for verification and synthesis while keeping the modeling style easy. In order to do this the TLM definition needs to support modeling styles that allow to deal efficiently with all the protocol intricacies as well as to provide with sufficient accuracy to allow verification with an RTL environment and on top of that there is a need for a synthesizable TLM subset. In this paper we propose such a transactional modeling style and discuss tools to automate model creation.

INTRODUCTION
In the context of todays increasingly complex SoC's, designs consist of embedded software running on multiple processor cores, connected to memory and peripherals [2]. As complexity grows, an increasing proportion of the software and the hardware peripherals consists  of re-used Intellectual Property (IP) blocks. To cope with these ever increasing requirements the design abstraction level needs to be raised. Recently transaction level modeling has been heavily promoted as the next modeling abstraction [3][4][5]. This trend, enabled and supported by SystemC [12], has initially been driven by the need to quickly craft models of SoC platforms that provide simulation speeds suitable for software testing. However, over time, the technique of transaction level modeling has been found valuable in various other areas of design and verification, leading to different approaches each with their own pros and cons. This has lead us to conclude that transactional modeling has great potential to become the new design and verification abstraction above RTL. In this paper we look at the different design methodologies that are being used and derive from that the requirements for a transactional modeling style, we then describe a TLM approach that complies with the requirements and discuss tools and models that enable TLM design methodologies.

DESIGN METHODOLOGIES
A prevalent design style, known as Platform-based Design(PBD) [6][8] or also refered to as component based design [1] is to configure IP blocks into platforms; to reconfigure the platform architecture quickly to create a succession of derivative designs; and to add some custom blocks aimed at differentiating each derivative design for a particular application. In order to validate the architecture of these platforms and to verify the derivative designs, the designer must focus on whether, in the new configuration of IP blocks, the communication between the blocks is optimal and correct and analyse whether the platform reaches the required performance. This is often a much larger part of the architectural validation and system verification problem, than creating and verifying the small amount of new custom functionality.
Next to PBD there is also a need for a design approach where a mix of application SW and algorithms can be mapped to an architecture of  reusable IP blocks. In this case there is a need for a HWSW design approach that allows quick HW SW partitioning trade-offs, where the IP architetecture can be extended with accelerator blocks for certain algorithmic parts [7][9][10][11]. Verification and implementation work both become very important and an efficient methodology is required with a minimum number of models that need to be created.
In order to achieve this on complex designs with adequate simulation performance, high level transactional models are not just needed to simulate the software on a model of the hardware, but also to accelerate modeling hardware IP in a bus  independent, re-use friendly modeling style. Models also need to allow easy and quick configuration of the on chip bus architecture or communication network.


Figure 1 : HW-SW Co-Design methodology

Because transactional modeling can be applied for so many domains, different approaches have emerged, each suitable to solve a subset of the above problem set and required use models. Unfortuntely, the need for multiple transactional models is a pain for the designer and needs to be avoided. The goal is to define a TLM modeling style that sufficiently serves all use models while keeping interoperability possible.

REQUIREMENTS FOR TLM

In order for TLM to become a complete design and verification abstraction level for the design methodologies discussed before it needs to support the following design steps:

  1. Embedded software development. Due to the large amount of software components in a complex SoC there is a need for executable models of the target design that can be used by the SW developers to create and validate the application SW.  To be able to run SW effciently on such an executable model there is a need for very high simulation speeds because of the difference in execution speed between SW tasks and HW accelerators.
  2. System Analysis. When combining various performance demanding multimedia applications on a single SoC, the design trend is to distribute applications on different CPU and DSP cores[2][4]. As a result there is an increasing amount of data exchanged on the system. To avoid communication to become a bottleneck there is a need for architecture exploration. For an effective analysis sufficient accuracy is required in a model to measure the effects of an architectural change on the real time requirements of the SoC.
  3. IP re-use. In order to support a platform based design methodology there is a need for IP models that can be reused in different architectures, possibly even architectures based on entirely different protocols. In order to achieve this a TLM style needs to be synthesizable and there is a need for a protocol independent subset.  Alternatively a TLM modeling style needs to support reuse of already exsisting RTL blocks in a design flow since no design is really starting from scratch.
  4. Block implementation. For the new HW blocks that are modeled with TLM there is an efficient path to implementation required. Preferably a TLM model can be refined and synthesized into an RTL description. This requires sufficient separation of communication and behavior in the description so that the communication can be synthesized independently.
  5. Block verification. Blocks that have been refined to the RTL level need a verification flow. There is a need for block by block verification but also a requirement to be able to validate a block within the system context. In order to do the latter there is a need for an efficient and accurate cosimulation between TLM and RTL.
  6. Bus/Network configuration and synthesis. In order to enable architecture exploration there is a need to be able to quickly create different architectural models that can be simulated quickly. On the other hand once a architecture is chosen it should be simple to create an implementation model for the architecture. To achieve this there is a need for optimized TLM architecture models and a design environment that allows to synthesize an implementation model for the selected architecture that has the same configuration as the TLM model.
  7. Ease of modeling. The more abstraction layers a methodology contains the more models that need to be created, even if there is an automated path from TLM down to RTL, still there is a need for an efficient modeling style that is easy to read and debug in order for designers to adopt this new abstraction. There is also a need for different flavors of TLM modeling to allow to tune the refinement level of the models used while experimenting with an SoC architecture. To achieve this a TLM modeling style could be based on a layered API that allows to choose the level of detail of the communication.

From these use models we derive the following highlevel requirements for a TLM modeling style

  1. high speed simulation
  2. appropriate accuracy for analysis and RTL cosimulation
  3. enable protocol agnostic descriptions for IP reuse
  4. provide access to all protocol details for tuning and to handle complex bus topologies
  5. reduce detail and simplify modeling
TLM DEFINITION

Transactional modeling applies to a class of design problems where protocol based communication is dominant (i.e. designs with bus or network structures) The primary goal of transaction level modeling is to achieve dramatically increased simulation speeds, while still offering enough accuracy for a given task. Transactional modeling is proposed as a way to minimize the amount of events and information processed during simulation. Instead of driving the individual signals of a bus protocol the goal is to exchange only what is really necessary (payload). TLM is also intended to reduce the amount of detail the designer must handle, therefore making modeling relatively easier.  In order to achieve the challenges described before there are a number of key concepts associated with Transactional modeling:



Figure 2: Minimizing simulation events through transactional modeling

  1. Separation of communication and behavior. Which allows each to be modeled independently without impacting the other, and also allows alternate descriptions to be tried easily
  2. Abstraction levels. Supporting different levels of abstraction within TLM allows detail to be added or suppressed as needed for a given state of development


Figure 3: Transactions and Transfers

  1. Transactions and transfers. In order to achieve both the goal of increased simulations speed as well as enabling enough accuracy in the models we introduce transactions and transfers. 
  • Coding API. TLM is built as an API that defines how models communicate. This API is driven and implemented in a bus model. Bus models need to be created only once and allow abstracting communication details providing ease of use and enabling higher simulation speeds.
    • TLM API DISCUSSION

    The TLM API as has been implemented as a result of this investigation is built up generically and protocol independent manner. In the tables below a list of the API calls is given for Transactions as well as Transfers.

    Transactions

    port.getTransaction()

    port.canSendTransaction()

    port.sendTransaction()

     

    Transfers

    port.getTrfName()

    port.canSendTrfName()

    port.canReceiveTrfName()

    port.sendTrfName()

    port.sendDelayedTrfName(delay)

    For every Transfer defined for a certain protocol these API calls are available. With each transfer a set of attributes is associated A typical list of Transfer definitions is given in the table below

    Transfer Name

    Attribute

    ReqTrf

    ReqMode

    GrantTrf

    --

    AddrTrf

    		 Address
    Type
    AccessSize
    Kind
    Group
    BurstWrap
    …etc…

    WriteDateTrf

    WriteData

    ReadDataTrf

    ReadData

    EotTrf

    Status


    In order to be able to reuse descriptions for multiple protocols it is important to use a standard Transfer and Attribute definition. In this way models that need, or use, minimal protocol information can be created in a protocol independent fashion. At the other hand models that require a detailed model for the bus interaction can be modeled by using all the available details in the TLM API.
    This API is extended with calls to lookup events for the different transfers, so that threads and methods can be made sensitive to the availability of transfers.
    As an example we can look at the different modeling styles for a device.

    SC_METHOD(receiveWriteData);
    sensitive << P1.getReceiveWriteDataTrfEvenFinder();
    dont_inititalize();

    SC_METHOD(sendEot);
    sensitive << P1.getSendEotTrfEventHandler();
    dont_initialize();

    void receiveWriteData() {
      P1.getWriteDataTrf();
      myvar = P1.WriteDataTrf->getWriteData();
    }

    void sendEotT() {
      P1.sendEotTrf();
    }

    To initiate a transaction it is possible to only use the transaction API as in the example below. First there is a check whether the initiator can send a new transaction then the different attributes of the transaction are set and finally the transaction is sent. In case the initiator is modeled cycle accurately and we’re dealing with a pipelined bus, the data value is not available at the time the transaction needs to be initiated on the bus, in such a case the data values can be updated in a later cycle.
    Sensitivity to transactions is not available since the availability of a transaction is not uniquely defined, in some cases you would like threads to be triggered when a transaction for this peripheral is started, in other cases it is preferred to have the thread triggered when all information on the transaction is available. Since one of the goals is to enable full cycle accuracy this feature has not been implemented.


    TRANSACTIONAL BUS SIMULATORS

    With the proposed TLM modeling style presented in the previous sections, all of the API implementation and the achievable accuracy is determined by the model of the channel. In case of multipoint communication this channel is referred to as a bus simulator. We refer to such a channel as a simulator due to the impact of the channel implementation on simulation speed. Next to API implementation also all transactions are allocated and managed by the bus simulator. There is no bookkeeping necessary in the peripheral bus interface (it is always possible to query any information related to the transaction from the API).
    Basically the bus simulator controls all activities on the channel. It handles requests for bus access, allows transfers and transactions to take place, and controls the timing of all events. The bus simulator implements the communication interface for both target and initiator, providing with a symmetrical model.



    Figure 4: Bus simulator port API’s

    As with other TLM approaches, it becomes increasingly difficult to create models that achieve a certain level of accuracy. Also, although TLM inherently enables faster simulation models, an efficient implementation requires a lot of tuning when done manually. Furthermore integration with platform creation tools and analysis and debug environments only adds to the complexity to create accurate channel models. Therefore we have taken an approach that allows to automatically create bus simulators from a formal protocol specification.

    PROTOCOL SPECIFICATION

    In order to automate the creation of bus simulators a full specification of the protocol is required. Protocol specification has been studied extensively already, many approaches have been suggested ranging from production based descriptions for logical synthesis [14] to formal specifications based on regular expressions in temporal logic descriptions [15] similarly to the approach described in [17] we use a combination of both to describe bus protocols. Many more approaches and definitions can be found in literature. Most of these approaches are aimed at formal verification of HW descriptions, hence their evolution into the PSL standard [16]. Our goal is slightly different, but very similar. A Transactional bus simulator should be able (as for verification) to accept all possible legal protocol timings and flag any incorrect usage of a protocol. On the other hand the intention is also to be able to drive both initiators and targets and apply the correct protocol timing to both in the case where transfer sensitive threads are used.
    Next to the protocol timing specification the goal of a TLM protocol specification is to indicate all attributes and their type as well as to define the different transfers available in a bus protocol.
    When the transfers and the attributes of a protocol are defined the timing of the protocol can be defined by defining the send and receive conditions for each transfer. Since a transaction is described by multiple transfers and since it is possible that multiple transactions need to be processed at the same time by a bus simulator, e.g. to model pipelined busses, transfers need to identify to what transaction they belong, whether that is the last transaction started or an earlier transaction. It is also required to be able to model subtransactions in case e.g. address and data transfers have a different pipelined behavior (so called split busses). It should also be possible to model transfers that are used multiple times in a single transaction, e.g. a burst access will have multiple date transfers for a single address transfer.
    From such a specification a transactional bus simulator can be synthesized. The synthesis will result in the core engine for a bus model, which will provide with all TLM API implementations as well as the protocol engine to run and verify a bus protocol. By using an open environment as SystemC a bus simulator can be made open enough so that an arbitration model or the special handling of protocol ID’s can be added into a bus simulator. Finally the synthesized model should be constructed such that it is possible to configure it for whatever platform architecture needs to be created for a SoC. Therefore the necessary interface to platform creation tools such as e.g. ConvergenSCTM needs to be available.

    EXPERIMENTAL RESULTS

    As a driver for this research bus simulators have been developed for the AMBAv2.0 specification [13]. A protocol specification for the AMBAv2.0 has been build and synthesized for use with SystemC. These bus simulators have been verified by cosimulating them with existing HDL testbenches to that they have been proven to be fully cycle accurate. With these bus simulators an example system is built. The system is a platform built to run a JPEG decompression algorithm in SW. It consist of an ARM926EJS processor a DMA controller, several memories and interrupt and display controllers and an input device. The complete AMBA bus architecture as depicted in the figure is modeled with bus simulators. Each peripheral can be simply coded using the transfer sensitive coding style; the overall system runs cycle accurately so that an accurate performance analysis of the architecture is possible. The complete model of this system runs at 98000 cycles per second, many times faster than an equivalent RTL model, while maintaining full cycle accuracy.

    CONCLUSIONS

    This paper presented an overview of the requirements for transactional modeling as an abstraction level for the creation of complex SoC where IP reuse and architecture definition are key design problems. A SystemC based TLM modeling paradigm has been presented that is fully cycle accurate but still has a very simple coding style for peripheral development. In order to achieve this goal the concept of bus simulators has been introduced as well as the necessary tool requirements to build an environment that eases the creation of TLM bus simulators. Finally we demonstrated the capabilities of this modeling style in an example system.

    REFERENCES

    [1]    W. Cesario, et. al. “Component-Based Design Approach for Multicore Soc’s”, in Proc. of DAC, 2002
    [2]    Phillipe Magarshack, Pierre Paulin, “System-on-Chip Beyond the Nanometer Wall”, in  Proc. of DAC, 2003
    [3]    Osamu Ogawa, et. al., “A Practical Approach for Bus Architecture Optimization at Transaction Level”, in Proc. of DATE,  2003
    [4]    Tim Kogel, et. al., “A Modular Simulation Framework for Architectural Exploration of On-Chip Interconnection Networks”, in Proc. of CODES+ISSS, 2003



    Figure 5: example JPEG decoder system

    [5]    Lukai Cai, Danial Gajski, “Transaction Level Modeling in System Level Design”, CECS Technical Report, 2003
    [6]    K. Keutzer et. al., “System Level Design: Orthogonalization of Concerns and Platform-Based Design”, IEEE TCAD Dec. 2000
    [7]    D. Gajski et. al., “SpecC Specification language and Design methodology”, Kluwer Academic publishers, 2000
    [8]    H. Chang, et. al., “Surviving the SOC Revolution, A guide to Platform Based Design”, Kluwer Academic Publishers, 1999
    [9]    J.A. Rowson et. al., “Interface-Based Design”, in Proc. of DAC, 1997
    [10]    F. Balarin, et. al.,  “Hardware-Software Co-design of embedded systems, The POLIS Approach”, Kluwer Academic Publishers, 1997
    [11]    K. Van Rompaey et. al., “CoWare – A design environment for heterogeneous hardware/software systems”, in Proc. of EuroDAC 1996
    [12]    OSCI: http://www.systemc.org/
    [13]    ARM: http://www.arm.com/ 
    [14]    A. Seawright, et. al., “A System for Compiling and Debugging Structured Data Processing Controllers”, in Proc of EuroDAC 1996
    [15]    I. Beer, et. al., “The Temporal Logic Sugar”, in Proc. 13th International Conference on Computer Aided Verification (CAV), 2001
    [16]    PSL/Sugar: http://www.verificationlib.org/pslsugar.html
    [17]    M. Oliveira, et. al., “High-level Specification and Automatic Generation of IP interface monitors”, in Proc. of DAC 2002

    Related Semiconductor IP

    Related White Papers

    Latest White Papers

    ×
    Semiconductor IP