ODETTE page at OFFIS
Presentation of the design flow proposed in the ODETTE project
Actual Design Flows
The design of a hardware/software system starts with the specification of its functionality and constraints. The description may be written in a natural language or in a specification language, which can be processed by a computer. A model of the system is in most cases developed from C/C++ specifications, that often accompany the description of standards.
After system modelling and model testing is successfully finished, the
designer must decide which parts to implement in hardware and software,
respectively. This partitioning decision may strongly depend on the constraints
to be met. Automatically partitioning is not applicable in most cases, due
to the inherent complexity of this task, especially for larger systems so
it is common practice to perform partitioning manually.
Sometimes, after partitioning, it is essential to perform some architectural
exploration. But in actual design flow it could be very error-prone and
time consuming task.
If the specified system turns out not to meet the specification, a re-design of some components, or even a re-partitioning of the complete system becomes necessary, with significant impact on the design cost and time-to-market. Also, debugging using co-simulation and prototyping can consume a significant amount of time.
Fig.1: Actual embedded system design process
One of the major disadvantages of actual design flows is the time-consuming and error-prone step from specification to the first hardware models. Even if the whole specification or at least parts of it are written in a programming language, often C/C++, a translation into a HDL like VHDL or Verilog is not a simple task due to the conceptual differences between software and hardware. Re-partitioning and architectural exploration may be a problem, too, because parts of the system model have to be translated from one kind of description style into a complete different kind of description style. Especially while using object-oriented modelling languages for the software-development in contrast to the procedural languages used in hardware development the repartitioning task could become very complex.
The SystemC(TM) design approach avoids some of the major disadvantages
of actual design flows.
With the SystemC(TM) design flow, design is not converted from a specification
level desciption to a synthesisable level in one large effort. Design is
incrementally refined in small sections to add the necessary hardware constructs.
Using such methodology, designer can more easily implement design changes
and verify model.
SystemC(TM) allows modelling whole system, including hardware and software
parts, at various abstraction levels and using one description language.
Fig.2: SystemC(TM) design flow
An abstract C++ specification is the beginning of the SystemC(TM) design flow for embedded systems. Simulation of this executable functional specification allows a validation of the system functionality. Such high-level system specification is refined by replacing native C++ data types to bit accurate SystemC(TM) data types, introducing concurrency, timing mechanisms and processing delay figures, and partitioning design into functional blocks.
After refinement of of higher abstraction level description to lower abstraction level description (untimed functional to timed functional SystemC(TM)) hardware/software partitioning and architectural exploration take place. The unified and common C++ based system description capabilities ease the architectural exploration, i.e. analysis and partitioning hardware or software components to allow a performance optimization of the system.
Afterwards, by means of further incremental refinement, bus-accurate
description and then pin-accurate description, which is synthesizable by
commercial synthesis tools, can be achieved. Pin accurate description model
can be either at behavioural level or at RT level.
The co-simulation of the entire system or system-parts at various phases
of the design-process helps to avoid errors and saves some time-consuming
and expensive iterations in the design-cycle.
The design flow that was developed within the ODETTE project deals with the hardware design with the focus on the synthesis. The ODETTE design flow provides several advantages over the pure SystemC(TM) design flow.
While using the tools and design methodologies provided by ODETTE, the
designers have the possibility to use object-oriented techniques and C++/SystemC(TM)
as modelling language for designing hardware, avoiding the paradigm break
between hardware and software development.
The possibility of describing hardware by means of object-oriented C++ constructs
makes the step from a C/C++-based system specification to a first hardware
model for simulation and even for synthesis a much easier task and enables
a simple transformation of system parts from hardware into software and
vice versa.
The ODETTE design flow is based on SystemC(TM) Plus Methodology and OSSS
description language. It integrates:
In general, the design flow is based on a commercially available one. Therefore, it includes simulation, synthesis and VHDL/SystemC(TM) co-simulation.
Fig.3: ODETTE design flow (SystemC(TM) Plus Methodology)
In contrast to the pure SystemC(TM),the SystemC(TM) Plus Methodology
and the OSSS allows for object-oriented design and synthesis, which greatly
reduces refinement process and facilitates the entire specification-modelling-synthesis
path.
The refinement process using the OSSS is much less time-consuming and error-prone
task. It is mainly a refinement of the functionality of classes.
The OSSS has been defined in the Language Reference Manual. By following
this reference designer can achieve object-oriented hardware specification
which can be directly transformed by the ODETTE synthesis tool into non-object-oriented
description synthesisable by common synthesis tools.
As a result of ODETTE synthesis we can obtain either synthesizable SystemC(TM)
description or behavioural VHDL description. Next, designer has two possibilities:
high-level synthesis or further refinement with subsequent logic synthesis.
As the tools performing back-end synthesis,
can be used:
- The Synopsys Design Compiler® (logic synthesis) and the Synopsys Behavioral
Compiler® (high-level synthesis). In this case VHDL description can
be used.
- The CoCentric® SystemC(TM) Compiler as the new, innovative back-end
synthesis tool. In this case generated SystemC(TM) description can be used.
Fig.4: ODETTE synthesis design subflow
Behavioral Compiler® (Synopsys)
The Behavioral Compiler® (BC) is a high-level synthesis tool for
the IC design.
Behavioral Compiler® automatically translates an algorithmic behaviour
description in VHDL in a Register-Transfer-Level description.
Design Compiler® (Synopsys)
The Design Compiler® (DC) is a logic synthesis tool. It automatically creates an optimized gate-level design based on a hardware specification (primarily at RT level) and constraints.
CoCentric® SystemC(TM) Compiler (Synopsys)
The CoCentric® SystemC(TM) Compiler synthesizes a SystemC(TM) behavioural description into a RTL description or a gate-level netlist.
The CoCentric® SystemC(TM) Compiler comprises functions of the Synopsys Behavioral Compiler® (high-level synthesis) and of the Design Compiler®. Since the functionality of the high-level synthesis capability of the Synopsys CoCentric® SystemC(TM) corresponds to the functionality of the Behavioral Compiler® at higher level the modelling level and the synthesis subset of the input languages are similar.
Simulation and cosimulation
Simumation and cosimulation will support the designer at all levels of specifications, controlling the functional correctness of the different levels of abstractions, after the automatic or semi-automatic refinements and transformations needed to reach the gate level.
Supporting libraries
Two types of libraries will support this approach: a general purpose design library, and an application specific design library, namely Telecom Class Library.