Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Embedded Systems

Fit the Hardware to the Algorithm with SystemC Models


System-on-chip (SoC) designs commonly consist of one or multiple processors (e.g. DSP or reduced instruction set computing (RISC) processors), interconnects, memory sub-systems, DSP hardware accelerators, and peripherals such as direct memory access (DMA) controllers and memory management units (MMU). In order to cope with the complexity of such a design, engineers must perform several recurring design tasks. These include creation of an executable specification, architecture exploration, embedded software development, and hardware-software verification.

The traditional design flow is a sequential flow, where all design stages are separated. The algorithm designer finishes his or her work and delivers models of the DSP system and specifications to the hardware designer and the embedded software developer. Starting from these specifications, hardware and software development begins—almost from scratch—without the further benefit of the algorithm designer's experience. It is obvious that this traditional flow has many disadvantages including:

  • The software developer has to wait for a first hardware prototype to implement his tasks.
  • The software developer cannot take hardware features into account until late in the design process. This is unacceptable, because interconnects and memory architectures should be taken into account early in the design process. At minimum, they should be considered when partitioning the algorithm into hardware and software components. The algorithm designer might even need to take them into account when defining functional modules.
  • The entire platform can be tested sufficiently only the first prototype is ready. Consequently, problems or inefficiencies are identified late in the design process. This can lead to a need to rebuild the prototype, a compromise in system performance, or even a re-spin of the chip.

These problems can be avoided by involving the algorithm designer in the early stages of the architecture design. This is enabled through electronic system level (ESL) design approach. In order for designers to accept an ESL-based approach, there must be an efficient and intuitive methodology for modeling complex platforms. This article introduces such an approach using a SystemC-based virtual hardware platform methodology.

Platforms are conceived in SystemC
Originally, SystemC was conceived as a means for implementing register-transfer-level (RTL) concepts in a C++ class library. Today, SystemC is used mainly for building models of a SoC platform early in the design, or as part of the verification flow. In both cases, SystemC provides easier ways to build models at higher levels of abstraction than any of the traditional HDLs. Some of the main concepts of the SystemC language are:

  • Modules: Modules are functional components. They implement (concurrent) behavioral processes by describing certain functionality. Such a module can be, for example, the implementation of a DSP sub-system.
  • Interfaces: Interfaces contain declarations of functions for communication between modules. Interfaces do not implement any functionality; they only specify the communication model.
  • Channels: Channels are the functional complement to an interface: The declared communication functions are implemented inside a channel. Hence, it can be said that a channel "connects" modules. Channels may be of different complexity, and may implement different types of protocols. When porting an algorithm to a SystemC platform, a designer may start from simple point-to-point channels.
  • Ports: Ports are part of a module. They allow a channel to be connected to the module. Port declarations are provided with interfaces, which tell the module about the allowed communication functions associated with a port. By changing the interface for a port, the module may access another type of communication protocol.

Figure 1 shows a simple example of a SystemC model. The system uses a so-called SystemC FIFO (sc_fifo()) channel, which behaves like a FIFO and provides some simple read and write functions for communication. The rest of the system consists of two SystemC modules. On the left-hand side we have a module modeling a transmitter. A receiver module is shown on the right-hand side. Both of the modules own a sc_fifo() port, which connects the modules to the channel. To forward data from the transmitter to the receiver, the transmitter module writes them to the sc_fifo() if there is free space inside. If data are available, the receiver reads them from sc_fifo().


1. Simple Example of a SystemC Model

The sc_fifo() channel is a simple channel, which can be used to model unidirectional point-to-point connections. It is a good channel to use when porting an algorithm to SystemC and performing the initial functional verification. An algorithm designer implementing an algorithm within a SystemC module does not have to care about the communication in detail. He just has to check the FIFO's status and calls the ports' read or write functions. The CoWare flow supports this simple protocol as one of the protocols used to connect DSP subsystems with a platform model.

A main differentiator in SystemC compared to traditional hardware description languages is transaction-level modeling (TLM), which offers a high abstraction of inter-module communication. It has four use cases: functional view (FV), architects view (AV), programmers view (PV), and verification view (VV). (See the reference at the end of this article for details.) The FV is the use case that algorithm designers can be directly involved in. The software and hardware designers can use the other three views.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.