User Tools

Site Tools


methodology

Methodology

Today, highly integrated embedded systems have a wide range of usage in our daily life, such as telecommunications and automotive. These modern embedded systems consist of several IP blocks plus a few custom components and often use pre-defined technology platforms to implement them. Existing and upcoming technologies offer ever more possibilities to cope with the increasing application requirements. Nevertheless, efficiently designing such systems remains a major challenge since electronic design automation tools and methodologies cannot keep pace.

Embedded Systems

In our definition, embedded systems consist out of an arbitrary number of the following components:

  • Software components to be executed on software processors which mostly perform control and supervision tasks,
  • Hardware components, that may perform computationally intensive or time critical tasks,
  • IP (Intellectual Property) components, either 3rd party components or hardware and software components from previous projects,
  • Interface components that perform the communication between Hardware and Software.

It has been observed that the integration of these different pre-designed components into an efficiently working system is much more difficult than the design of a single component. This has massively influenced the principle of platform-based design.

Platforms

In practice, most embedded systems are implemented on so-called technology platforms. These platforms provide a basic configuration consisting out of processors, memories, special hardware resources (or accelerators), communication peripherals, and communication resources (like buses, special cross-bar switches or Network-on-Chips) to connect them all together. The application is implemented on top of this platform configuration. Some platforms provide advanced configuration and parameterization and offer flexibility for the implementation of different applications (e.g. platform FPGAs from Xilinx, Altera or other vendors).

Design Challenges

From a technical point of view the design of embedded HW/SW systems involves all steps from the initial specification of the application - what is the system supposed to do - to the efficient implementation on a technology platform - how is it implemented. The challenge consists in finding methods for the description and transformation/refinement of the initial specification to an efficient implementation.

From the industrial point of view the requirements for the design of embedded systems are very tight. Targeted development costs and time-to-market needs to be matched, but at the same time functional and non-functional product requirements need to be fulfilled. Consequences for the design process are: Modelling on the highest possible level of abstraction (mastering of complexity), most accurate analysis of system characteristics (prevention of costly re-design cycles), high degree of automation (raising efficiency and prevention of errors), and re-use of pre-existing components. These are just a few consequences, but all of these have been considered during the development of the OSSS methodology.

The OSSS Design Methodology

The following sections describe how the OSSS methodology can be used to develop embedded systems. For simplicity we only present a top-down design flow that starts with a C++ “Golden Model”.

In a first step, this entry model is decomposed into structural elements (called behaviours). This is done systematically by profiling trials that identify relevant and computationally intensive elements. After the identification and classification these structural elements are described by SystemC modules and OSSS Software Tasks. Communication and synchronisation between these parallel process elements is modelled by OSSS Shared Objects. They are special objects (instances of C++ classes) that provide a method interface for communication and guarantee a consistent access of an arbitrary number of concurrent processes.

This first structured system description in OSSS is called Application Layer Model (AL Model). The application is described in SystemC and C++ under consistent involvement of object-oriented features that are supported by the OSSS methodology and the FOSSY synthesis tool:

  • Encapsulation of data and operations (methods) in classes. This is a basic object-oriented design principle for raising re-use.
  • Method-based communication between structural blocks avoids effort of hand-crafted signal based communication and synchronisation. This kind of communication abstraction can be considered as high-level transaction level modelling (TLM), which is currently not covered by the OSCI TLM2 standard.
  • Class inheritance allows easy extendibility for re-use. Polymorphism, which is based on inheritance relations, can be used to express implementation alternatives.
  • Template classes offer easy parameterisation (e.g. buffer sizes) and make IP components more flexible.
  • SystemC modules with ports and processes allow the specification of hardware components.
  • OSSS Software Tasks specify parts of the application that are later executed on a processor.

On the AL we specify the function, logical structure, and an approximate time response of the system. Profiling results from analysis of the C++ “Golden Model” can be annotated to the AL to obtain an approximately timed behaviour. Also back-annotation approaches, where the execution of specific parts are profiled on their expected target technologies, are possible, but not further discussed here. Besides the functional correctness of the system, the AL offers an easy evaluation of design alternatives (e.g. HW/SW partitioning, scheduling, communication structures, and data locality). Profiling of different AL model alternatives with regard to their performance can be accomplished easily since the component’s allocations and scheduling can be changed quickly. Analysis of the executable AL model in early design phases can help to detect and resolve bottlenecks in the logical structure. This might result in the relocation of timely critical computations from SW to HW or in reorganising complex computations in pipeline structures to enhance the throughput.

OSSS Design Methodology

The next step towards the implementation is the refinement to a so-called Virtual Target Architecture Model (VTA Model). For this purpose more implementation details of the target architecture are added. Abstract communication relations from the AL model are mapped onto physical communication channels with different protocols and data bandwidths. By using different so-called OSSS-Channels the designer can examine the influence of different bus protocols, data widths and arbitration schemes on the timing behaviour of the design. For saving costly communication resources, different logical communication relations can be grouped to a single physical connection. The resulting VTA model shows a cycle accurate timing behaviour and contains all other platform dependent information, like the chosen software processors or communication peripherals.

FOSSY synthesis flow for Xilinx FPGAs

The VTA model is the input for the automatic FOSSY synthesis process. It generates the overall system architecture, synthesisable VHDL for each hardware component, and C/C++ code for each software task. For the software parts a driver API and for the hardware parts a bus interface is automatically generated. Depending on the chosen platform, different so-called architecture description files can be generated. Special properties of different target platforms require adoptions of the synthesis process, e.g. for embedding special IP blocks or the generation of 3rd party tool specific configuration files. The above figure shows the FOSSY synthesis process that has been tailored for Xilinx FPGA target technology.

methodology.txt · Last modified: 2014-12-11 15:14 (external edit)