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  ian  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.  Durinthe  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 separatefrom 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
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 goospecificatiomodel.  A good specificatiomodel 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  Spec SLDL computation  units   can  b modele 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 addefeatures like signals, wait, notify etc. to supporhardware description. Ialso 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  initializationot available  iSpecC.
 The  most  challenging  part  was the conversiofrom 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.

GET Full Project Report Mail us at

No comments:

Post a Comment