Next activities integrate the definition of the HW/SW co-design approach:
- ASSERT/TASTE Process Assessment focusing on the achievement of maximum compatibility with the
ASSERT/TASTE methods and tools.
- HW/SW Co-design Survey laying special emphasis on the methodologies and associated tools for system
specification, performance estimation, HW/SW partitioning and HW synthesis.
- Preliminary Design of the HW/SW Co-design Process supported by intense assessment on the findings of
the previous tasks.
- Evaluation of Compliance with ASSERT/TASTE Process analysing the advantages and drawbacks of the
proposed solution to identify the compatibility with ASSERT/TASTE approach.
ASSERT/TASTE Process Assessment
The process assessment goals are the investigation of the technical solutions implemented in ASSERT/TASTE,
the analysis of ASSERT/TASTE tool-chain constraints, and the exploration of model transformations and implementation
tracks.
ASSERT/TASTE views have been analysed to extract information about their semantics and syntaxes. This
information will be used in Task 2 to deduce transformation
rules and derive these views from the system model.
These are the ASSERT/TASTE views:
- The Data View, which defines the types of data exchange among the different components.
- The Interface View, which characterizes the provided and required services of components and declares their
intended concurrent behaviour.
- The Functional View, which specifies the functional services provided by system components and expresses their
sequential behaviour in terms of state machines, classes and interfaces.
- The Deployment View, which specifies the physical architecture of the system and the way in which software
application(s) are to be deployed on it.
Once these views are generated, the Concurrency View and the source code can be directly derived applying
the ASSERT/TASTE tools, and subsequently synthesized in the target platform.
Finally, a simplified but realistic example has been implemented simulating the performance of a Health
Management System (HMS) using the AADL track. Apart from analysing ASSERT/TASTE views and tools through this
example, it serves to infer constraints to the HW/SW co-design flow and make suggestions about how to enforce the
process compliance with ASSERT/TASTE.
HW/SW Co-design Survey
This survey includes an analysis of the state of the art in Electronic
System-Level (ESL) design methodologies and tools for each HW/SW co-design phase:
- During the co-specification, two approaches can be followed:
- Homogeneous modelling. It uses one specification language for specifying both hardware and software
components of a heterogeneous system. The key challenge in this approach
is the mapping of high-level concepts used in the initial specification onto low level languages
(e.g., C and VHDL) to represent hardware and software parts.
- Heterogeneous modelling. It uses specific languages for hardware (e.g., VHDL), and software (e.g., C).
Heterogeneous modelling allows simple mapping to hardware and software, but this approach makes validation
and interfacing much more difficult.
- Co-design involves the following tasks (among others): tasks assignment, cost estimation, allocation,
HW/SW partitioning, scheduling analysis of the software system.
- Co-synthesis involves the following tasks (among others): communication synthesis, specification
refinement, hardware and software synthesis.
- Co-validation methods: formal validation, on target validation, simulations.
The most relevant and widely used languages and tools have been evaluated:
- Description of UML, AADL and SDL modelling notations. AADL is highlighted as it is compatible with ASSERT
process. In addition, AADL presents many benefits for HW/SW co-design. It contains constructs for modelling
both hardware and software components (with the hardware components named "execution platform" components within the standard).
This language supports early and repeated analyses of a system's architecture with respect to performance-critical
properties through an extendable notation, a tool framework and precisely defined semantics.
- In order to represent the hardware model several programming languages are proposed (e.g., SystemC, ImpulseC, SpecC),
as well as Hardware Description Languages (HDL) (e.g., Verilog, VHDL). Their specifications must be considered to
implement the hardware synthesis.
- Eventually, both commercial and academic tools have been compiled. These tools are used at different levels:
system specification, performance analysis, modelling and analysis of software components, HW/SW partitioning
and hardware synthesis.
From all of them, AADS (AADL Simulator) and SCoPE academic tools are stressed. AADS extracts from the AADL
models the necessary information for SCoPE tool to perform a simulation at system level.
The simulation results will guide the system designer through the selection of the most adequate
partition solution. Next figure illustrates the relationship among OSATE, AADS and SCoPE tools:
Overview of Potential Solutions to Support HWSWCO
This activity provides an assessment of solutions and recommendations as well as the
identification of the efforts needed to perform the required adaptations.
Firstly, an initial solution is proposed to implement HWSWCO methodology that covers co-specification, co-design and
co-synthesis phases. Subsequently, based on the maturity of tools, open points that require to be
further analyzed and the scope of the study, a final solution is presented where co-specification and co-design
phases are simplified; so that the case-study [Task 3] can cover all the HWSWCO phases.
The methodology introduces the concept of System Model which is composed of a System Logic View
and a System Platform View. It provides an integrated view of the system.
Then, the Partition Model allocates AADL processes to processing resources from the system platform. This is
the way to assign functionality to either hardware or software items.
From the partition model already tagged, hardware and software components are obtained, and then implemented
and synthesized.
Apart from describing how each HWSWCO phase is developed, this activity includes the notations and tools
selected to implement them. This list specifies the ones suggested to be used in the HWSWCO framework:
- Co-specification includes the development of the System Model in AADL using OSATE editor and LabASSERT. In order to
represent data format, ASN.1 is selected. Both notations are also used in ASSERT/TASTE process.
- Co-design covers the partitioning process and the analysis through simulations of the solution
proposed. Two UNICAN's tools are chosen to obtain the performance analysis: AADS-T and SCoPE.
Once partitions are decided, different notations and tools are used in hardware and software tracks:
- HW design: the transformation from System Model (HW part) to ImpulseC is done manually and supported by
Impulse Co-Developer.
- SW design: it is based on ASSERT/TASTE models and tools (AADL track and C code). An AMT (ASSERT Model Transformer)
needs to be designed to transform the System Model (SW part) to valid ASSERT/TASTE inputs.
- Co-synthesis includes:
- HW synthesis: HDL files are transformed into bitstreams that are directly downloaded
in the target platform. The tool support is Xilinx WebPack and Digilent Adept Suite.
- SW synthesis: C-code is directly extracted from ASSERT/TASTE tools. Then, schedulability is checked
using Cheddar and finally debugged through GRMON.
Evaluation of Compliance with ASSERT Process
Assessment of the compliance of the proposed HWSWCO solution with the
ASSERT/TASTE development process.
This activity also provides a description of ASSERT process (see figure below) and tools, together with a
description of how to add
HWSWCO to ASSERT.
On the one hand, the evaluation results highlights two points at system level that need to be refined or
further investigated:
- Abstraction inversion.
- Verification of the consistence between properties of AADL and ASSERT concurrency view.
On the other hand, the system platform, the partition model and the implementation of hardware and software components
are in compliance with ASSERT.
Finally, regarding notations and tools, it is stressed that AADS-T and SCoPE are based on a full
POSIX threads computational mode which should be restricted to be in line with Ravenscar Computational Model (RCM).
All these conclusions have been considered to improve the proposed HW/SW co-design process.
