Chapter : 1
INTRODUCTION
Improvements in
manufacturing
capabilities
allow placing of a complete
embedded system
on a single chip. With that it becomes possible to design a system
as a mix of
software running on a generic processor and specialized hardware, which
performs
otherwise expensive computation. This design freedom leads ultimately to highly
specialized chips and cost efficient production. However the newly gained freedom in
design places a burden on the SoC designer. The next paragraphs will introduce the challenges of system level
design, the specification of systems and the design space exploration.
Challenges of SoC Design:The design of a SoC has similar goals as an embedded design. The designed system will be used in a well-specified environment, and has to fulfill
strict requirements. Some
requirements are clearly defined by the application like the functional requirements of an algorithm, e.g. the decoding of an MPEG 1 Layer 3 data stream, which covers certain
quality
restrictions. The environment poses other requirements: e.g. minimizing the cost, footprint, or power consumption. However due to the flexibility of a SoC design,
achieving the set goals, involves
analyzing a multi dimensional design space. The degrees of freedom stem
from the process element types and characteristics, their allocation, the mapping of functional elements to the process elements, their interconnection with busses and their scheduling.
SoC Specification:
Hardware/Software
co-design is an integral aspect of the SoC design.
It requires a language with is capable of capturing the requirements of an hardware design from
wire allocations do complex timing requirements, as well as the complexities of
current
software design.
During the
lecture different
alternatives languages for system level design were presented: the C++ library extension SystemC [5], some extensions to
the
UML capturing. The main focus
was on the SpecC language, which is
an extension of the ANSI-C language. It uses the ANSI-C for description of software requirements and adds
features needed for system design. It allows
grouping of functionality to behaviors, which later can be freely mapped to processing elements. In order to allow this free mapping the
computation has to be separated from the communication.
Therefore communication between the behaviors is abstractly
defined as channels. The channel specific implementation (e.g. a PCI bus protocol) will be filled in during later refinement stages. The specification model is free of such implementation detail (and constrain).
The SpecC language further
introduces
many
concepts from
hardware descriptio languages like VHDL and Verilog. It introduces the concept of capturing scheduling information in the language, such as sequential, parallel and pipelined execution.
The SpecC language very much supports the goals of
specification capturing. It allows
describing a fully functional model that incorporates design constrains and is testable
against a set of test vectors.
The next section describes the exploration and refinement steps to transform the system
specification into a manufacturable descriptio.
Chapter :2
SYSTEM ON CHIP
Specification model is the starting point in the system design process and forms the sole input to the architecture exploration tool. Specification model is the result of capturing
the functionality of the design in System Level Description Language (SLDL).
The Specification model is pure functional, abstract model, which is free of
any
implementation details.
The model
runs
in zero simulation time and hence has no notion
of time. Since the specification model forms the basis for the synthesis and exploration it
is important
to write good specification model. A good specification model has the
following important features:
Separation of computation and communication units: Specification model should clearly separate the communication blocks from the computation blocks. This enables rapid exploration by facilitating easy
plug-n-play
of modules. Abstraction of
communication and synchronization functionality is a key for efficient synthesis and rapid design space exploration.
In SpecC
SLDL, computation
units can be modeled using ‘behaviors’
and
communication elements using ‘channels’.
Chapter : 3
CONCLUSION
In this project we implemented the specification model
of an MP3 decoder in SpecC
SLDL and followed the system level design procedure using System-On-Chip
environment to arrive at the final implementation model of the decoder.
We chose SpecC as a language to implement the
specification model as it best suits for describing systems involving both hardware and software components.
Being a true
superset of ANSI-C it has a natural suitability
to
describe software components. It has added features like signals, wait, notify etc. to support hardware description. It also includes constructs to support hierarchical description of system
components. With all these features, the designer has flexibility to choose and describe the system under design
at
any desired level of abstraction. SpecC is easy to learn and a clean language. Anyone
with background knowledge of C can learn SpecC. Besides
the SpecC language the System-on-Chip environment presented a major support for completing the project. Although, it is in its early development stage, it allows
an
easy design
space exploration. It enables the designer to estimate performance during the early stages of the design and additionally allows
the early pruning of the design space. We spent most of our time in converting an existing C code into the Specification model.
Unfortunately a noticeable effort had to be spent since the originating code was not
ANSI-C compliant
and
frequently used a small
feature of variable initialization not
available
in SpecC.
The most
challenging part was the conversion from the strictly sequential C code, which
heavily relied on
global variables. In
order to break up the code
into behaviors, these global variables have to be attached to behaviors and the
communication has to be mapped to channels. Clearly the originating C code did not
follow the separation of computation and communication. Unfortunately due to time
restrictions we only completed the first set of
behaviors. With the limited amount behaviors we could not fully explore the possibilities in concurrency, which also limited us in the design exploration.
Future work on this topic could start with our Specification Model and create more
behaviors. With
sufficiently breaking up the code into behaviors a clean
design
can
be achieved which will consist of concurrent modules of the code. This will enable efficient
mapping of behaviors to concurrent processing elements and exploitation of parallelism.
No comments:
Post a Comment