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.
In our definition, embedded systems consist out of an arbitrary number of the following components:
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.
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).
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 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:
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.
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.
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.