Advancing Transaction Level Modeling: Linking the OSCI and OCP-IP Worlds at the Transaction Level
Contributor: Sonics, Inc.
April 29, 2005 -- The convergence of communications and multimedia data processing onto a single chip continues to push SoC complexity in two areas, SoC integration and software development. To address SoC integration issues, the industry has been moving towards standardizing the IP core interfaces to achieve high reuse. To address software development, the industry has been adopting higher abstraction simulation models which can deliver near enough performance and accuracy to enable software development to begin in parallel with chip development. While OSCI (Open SystemC Initiative) has focused on the software development concerns, and OCP-IP (Open Core Protocol – International Partnership) has focused on SoC integration concerns, the concept of Transaction Level Modeling (TLM) would most benefit from a methodology such that both standards can be utilized in a straight forward manner.
Using CoWare's ConvergenSC and Sonics' SMART interconnects, the two companies have designed such a common methodology which achieves the unified TLM goal. In this article, each TLM standard is discussed, followed by the interoperability work conducted between CoWare and Sonics.
In this article, we introduce both the OSCI and OCP-IP variants of TLM, outline CoWare's contributions to help interoperability between them, and introduce the CoWare/Sonics development to provide SoC integration and software development solutions based on Sonics SMART Interconnects, with OCP interfaces, and CoWare's ConvergenSC™ SystemC-based design environment.
TLM in SystemC - The OSCI Proposal
The primary goal of TLM is to dramatically increase simulation speeds, while offering enough accuracy for the design task at hand. The increase in speed is achieved by the TLM abstracting away the number of events and amount of information that have to be processed during simulation to the minimum required. For example, instead of driving the individual signals of a bus protocol, the goal is to exchange only what is really necessary, i.e., the data payload. TLM also reduces the amount of detail the designer must handle, therefore making modeling easier. The necessary information is presented to the designer as a TLM API (Application Program Interface).
The OSCI TLM API is built as a set of interfaces that define how models communicate. These interfaces can be used in their primitive form, or augmented with a "protocol-layer," which will target the basic interfaces to a specific on-chip communication protocol or design task. This protocol layer provides a set of convenience functions that make the TLM modeling abstraction much easier to use (see Figure 1).
TLM in SystemC - The OCP-IP Proposal
The OCP-IP TLM proposal provides an SoC communication modeling framework and is an output of the System Level Design Working Group within OCP-IP. The proposal comprises a set of well described layers of abstraction that together create a structured link between up-front architecture exploration and SoC implementation.
An additional objective is to create a hierarchy of models (L-0 to L-3) that are re-usable from one layer of abstraction to the next and across uses (e.g., performance analysis and testbench creation). Finally, the proposal is intended to provide clearly articulated entry points into the hierarchy from which EDA vendors, chip designers and architects can create and easily distribute tools, testbenches, executable specifications, and the like, within their organization or the industry as a whole.
Message Layer (L-3): Message, or Layer 3, models are at the highest level of abstraction defined and are intended to be used by SoC architects as proof of concept tools, to rationalize first order functional partitioning and to provide data needed to make system level architectural trade-offs. SoC models created at Layer 3 are also intended to be re-used as executable specifications.
L-3 models are event driven and untimed. Each transfer across their interface contains several datum that are often abstracted to a higher order. For example, a message could contain the equivalent data from several bursts of data at a lower level of abstraction that form a complete MPEG4 macro-block. Another key characteristic of this models created at this level of abstraction is that they are not address mapped, but process mapped.
Transaction Layer (L-2): Transaction, or Layer 2, models are designed to be used by SoC architects to carry out detailed hardware performance analysis and hardware/software partitioning and co-development. They also contain a high degree of versatility in their application. They can be used to interface low level drivers with hardware simulation models, and integrate Operating System simulators with hardware emulators. Continuing the re-use objective, Transaction Layer models can also be used as the source for "Golden" test patterns and can form the test bench for Transfer Layer (L-1, below) models.
L-2 models have structural accuracy sufficient to model a complete system (address information and communication constraints), an event-driven computational model with approximate timing, and are highly parameterizable. Each transaction contains a transfer of several datum, such as a burst to memory, is OCP specific but is independent of any bus fabric protocols.
Transfer Layer (L-1): Transfer, or Layer-1, models are designed to be used by designers to perform detailed modeling tasks that do not require accuracy down to the per interface signal level. They can be used for modeling the interfaces of embedded processors, creating cycle accurate test benches and carrying out cycle accurate performance simulations. They can also be used to perform equivalent performance comparisons with RTL objects.
L-1 models are clocked cycle-accurate. While interface pins are abstracted away, they follow interface protocols which are mapped onto the chosen hardware interface and bus structures. Each Transfer Layer transaction contains a single data item which is byte-accurate.
RTL Layer (L-0): For a point of reference, RTL, or L-0 Layer, models are both pin and bit accurate. They are also register transfer accurate and are written in VHDL, Verilog or synthesizable SystemC. Finally, estimated propagation timing can be back annotated.
The below table provides a simple chart showing some functional equivalents when moving from an RTL Layer model to a Transfer Layer model.
The OCP-IP System Level Design Working Group white paper entitled SystemC based SoC Communication Modeling for the OCP™ Protocol should be referred to for more detail. Figure 2 below illustrates the successive levels of detail that is removed at each level of abstraction.
All models are instrumented for ConvergenSC's analysis capabilities, allowing the platform architecture to be optimized, and the interconnect to be reconfigured with SonicsStudio. The L-2 models run fast enough to validate the system with large quantities of embedded software, while the tight links to SonicsStudio ensure decisions made in the SystemC domain are carried directly to the RTL domain within the configuration of the SMART Interconnect. The close links to the physical implementation of the interconnect then facilitate a first-time-right implementation that meets all necessary system requirements such as guaranteed Quality of Service (QoS). This tight integration of the two development environments ensures that decisions made in the SystemC domain are carried through to the RTL domain faithfully, removing any chance for translational error.
Due to the exponential rise in the complexity of SoC's and the amount of software to be executed on them, the need for higher levels of abstraction through SystemC modeling is clear. In order to reduce industry wide costs in developing the necessary infrastructure, and the need for reliable interoperability of models and environments, open industry standards are not only needed, but required. Both OCP-IP and OSCI have carried out important work to move the ball forward significantly in these regards.
CoWare and Sonics are at the forefront of this work, which we believe to be fundamental for successful Electronic System Level design. One unified standard supported by all would be the ideal case, but we fear that there is already too much legacy investment for that to realistically occur. However, leveraging off this body of work, we believe that the joint CoWare/Sonics SystemC modeling offerings, driven by leading semiconductor and system OEM customers, will provide the optimal solution for SoC and system level success. Ensuring chip level and Electronic System Level design requirements are met, IP has maximum re-usability and ever shortening market windows are consistently hit.
By James A. Colgan, Strategic Alliances Director, Sonics, Inc., and
Pete Hardee, Director of Services and Strategic Marketing, CoWare, Inc.
CoWare is an OCP-IP Sponsor member and founder of OSCI. Sonics is a co-founder of OCP-IP and contributor to the OCP-IP System Level Design Working Group.
Reprinted from SOCcentral.com, your first stop for ASIC, FPGA, EDA, and IP news and design information.