Products Using OCP
Advancing Transaction Level Modeling
The growing need for Transaction Level Modeling (TLM) standards that can
link together SoC architecture and software development at levels of
abstractions higher than RTL has stimulated CoWare (an OCP-IP Sponsor member
and founder of OSCI) and Sonics (co-founder of OCP-IP and contributor to the
OCP-IP System Level Design Working Group) to collaborate on a cohesive
methodology that addresses both SoC designer and software developer
needs.
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 has focused on the software development
concerns and OCP has focused on SoC integration concerns, the concept of
Transaction Level Modeling 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.
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: 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 be
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.
TLM in
SystemC – The OCP-IP Proposal
The OCP-IP TLM proposal provides a 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 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, etc.
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 the 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, which are OCP specific but are 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. The below table provides a simple chart showing some
functional equivalents when moving from an RTL Layer model to a Transfer
Layer model.
RTL
Layer (L-0)
For a point of reference, RTL, or L-0 Layer, models are both pin and bit
accurate. They also register transfer accurate and are written in VHDL,
Verilog or synthesizable SystemC. Finally, estimated propagation timing can
be back annotated.
Back to Adoption
Stories
