Chapter : 1
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 , 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.
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
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.