HWSWCodesign
Home Contact

gmv

Extending ASSERT to HW/SW Co-design
  [home]-[task1]

Task 1 - Definition of the proposed HW/SW co-design approach


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:

Relation 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.

AssertProcess

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.

 

GMV