AbstractionLevels

Classical Levels of Abstaction

An important approach for designing (hardware) systems is the notion of abstraction.

The most common and classical abstraction levels are given in the table:

Layer Tasks Structural Elements
colspan=3 |
System Creation of an (executable) specification of the system. Exploration of the system architecture Processes, state charts, data-flow charts
Algorithm Modeling untimed modules with algorithmic behavior, describing the system functionality CPUs, DSPs, memories
RTL Modeling the timing and control of the system, rather parts of the system Finite state machines, ALUs, registers
Logic Describing and optimizing single (small-sized) components using boolean formulas Gates, flip-flops
Technology Creation of the floor plan Transistors

There are different approaches in designing hardware, e.g. top-down. Starting with a system specification, the design and implementation will be iteratively refined down to (say) RT level for synthesis. This approach may be proper for small or medium-sized circuits.

Today, intellectual property (IP) gets more important, also platform based design that depends on a hierarchical layout consisting of several IPs. IP means that components are pre-verified and interfaces are well-defined.

SystemC modeling: Levels of Abstraction

Now when talking about SystemC there are different views of abstraction (see [1]), but similar to that one stated above. Assuming that there is an exact idea what to implement, one could start with a functional model. In this phase there is a functional exploration, e.g. starting with the evaluation of different algorithms, heading for a timed behavior of those algorithms.

When it comes further down, there is a partitioning into hardware and software parts. Multiple components like CPUs, busses, memories and additional acceleration hardware will be used to model an entire system. In this phase there will be a communication exploration, e.g. starting with abstract protocols and bus models, heading for use of cycle-accurate hardware signals.

This view can also be given in a table:

Layer Description Tasks
colspan=3 |
UTF With Untimed Functional, there is no notion of time. The process behavior and data transport are executed in zero time. Performing functional verification and validation of algorithms.
TF With Timed Functional, there is a notion of time from now on. Processes and data transport do have execution times. Performing a first, coarse performance analysis. With HW/SW partitioning the development of software applications is being started.
BCA The Bus Cycle Accurate layer uses entire bus cycles for synchronisation. There is no pin-level detail as the system uses read and write transactions. Performing detailed performance analysis and architecture analysis as well as SW development.
CA The Cycle Accurate layer is refined down to cycle accurate synchronisation and may of course have pin-level detail. Performing detailed performace analysis (maybe on the signal level) and development of low-level software (e.g. drivers)

Compared to the first table (mentioned above), the levels are still present. However, this view tends to overcome the task of modeling: starting with a simple data-flow model and heading for a communicating system with parallel processes (both hardware and software).

The levels can be seen in a top-down fashion, at a first glance. With this layered approach, there is a distinction between functional modeling and communication modeling.

On the other hand, all those levels can be mixed together in a whole system. That way, Transaction Level Modeling spans over all those levels, when modeling an entire system. The emphasis is rather placed on the functionality of the communication, than on an detailed modeling of the communication architecture.

This representation covers the scope of SystemC, see also a comparison of HDLs.

Transaction Level Modeling: Levels of Abstraction

TLM again can be assigned to different levels of abstracion. This view tends to be the software developers view on the SystemC levels of abstraction, and is proposed by the OSCI TLM working-group. When using this approach IP exchange should be encouraged.

The table shows the proposed levels of abstraction, compared to the conventional SystemC levels of abstraction (mentioned above).

Note: An exact mapping of those levels may not be possible with assurance but will be shown anyway, however.

TLM Layer SystemC Layer Description
colspan=3 |
CP: Communicating Processes UTF Parallel working processes, that are data-flow oriented.
PV: Programmers View TF 2(> These layers focus the development of the system software, i.e. application software and drivers.
PVT: Programmers View Timed BCA
CC: Cycle Callable CA This layer can be seen as a subset of the RT level, but not so much focused on hardware synthesis.

It should be mentioned that this view is still in development, and other views are also possible!

References

[1] Thorsten Groetker, Stan Liao, Grant Martin, and Stuart Swan, System Design with SystemC, Kluwer Academic Publishers, 2002

PageComment2(commentfirst=1,nosmiley=1,articleview=1)

NewPage(PublicTemplate,New Page Here,SystemC/AbstractionLevels)

Posted January 8th, 2008 by MarkBurton