Progettazione Grafica di Sistemi: un approccio top-down di Selex Communications

8/6/2019 Progettazione Grafica di Sistemi: un approccio top-down di Selex Communications

1/96

22/06/2011 Pi di pagina - Arial 12 pt.

Graphical System Design

A Top-Down approach at Selex ElsagIntroduction


2/96

22/06/2011 Copyright SELEX ELSAG. All rights reserved.

GSD :: Problems

Statistics derived from audits held at Electronic Industries especially focused

on embedded technologies inform that:- 15% of the projects fail, that is these projects never end- 85% of the projects don't fail, that is these projects end, but

- 50% of these projects are late (in average 4 months as delay)- 70% of these projects are missing the requirements by more than 30%- 30% of these projects are missing the requirements by more than 50%

Failures are coming from limited visibility- of the complete System- between each Design Domain and the following one

Missing of requirements is coming from:

- limited ability to trace the execution- limited ability to control the execution

Then, lack of observability and controllability.


3/96


GSD :: Problems

Following the Customer Needs Selex Elsag transformed itself from anEquipments Provider to a Solutions Provider.

Following the Technology Trends Selex Elsag is focused on embeddedsystems (SW/FW is becoming more relevant than the HW only).

Following the Time-to-Market constraints, Selex Elsag is adopting COTS

- both HW and SW/FW COTS

- not only for Prototyping, but also for Production

- at any level (equipments, assemblies, components)


4/96


GSD :: Problems

Solutions provided by Selex Elsag are:- really complex, everything is a system- a solution is a system of equipments

- an equipment is a system of assemblies

- an assembly is a system of components

- a component could be a system of inner components

- designed, engineered, manufactured, integrated, and tested by distributedTeams, distributed as site, but also as Technology Phase & Domain

- Solution Architects

- Equipment Architect

- Design Experts (on different Domains)

- Development Experts

-

These distributed Teams are usually

- responding to different Directorates

- speaking different languages

-


5/96


GSD :: Problems

Many problems to face:

- Larger and larger Projects to be fully managed

- Projects to be On Time

- Projects fully covering the Requirements

Then Processes, Methodologies and Tools to be adopted.


6/96


GSD :: High Level Solution

PROCESSES, METHODOLOGIES, TOOLS

HIGH LEVELARCHITECTURE

MEDIUM LEVELARCHITECTURE

HIGH LEVELVIRTUAL

PROTOTYPING

MEDIUM LEVELVIRTUAL

PROTOTYPING

LOW LEVELDESIGN

ALGORITHMICEXPLORATION

LOW LEVELSYNTHESIS

LOW LEVELVIRTUAL

PROTOTYPING

LOW LEVELHW in the LOOPPROTOTYPING

LOW LEVELSIMULATION

PROJECT PLANNING, CONFIGURATION MANAGEMENT, REQUIREMENTS & TESTS


7/9622/06/2011 Copyright SELEX ELSAG. All rights reserved.

GSD :: HL Solution :: Requirements

The Requirement has not to be divorced from the remainder of the process,but has to strictly follow the entire process, otherwise problems at the endsuch as the final product not fully addressing all the requirements, then:

- Requirement must be captured from the start to the end of the project- Requirements must be edited from the results on the intermediate design

phase- Requirements must be strictly linked to the design data package items

STAKEHOLDER REQUIREMENTS LAYER

SYSTEM REQUIREMENTS LAYER

SUBSYSTEM REQUIREMENTS LAYER

COMPONENT REQUIREMENTS LAYER

MODELING

MODELING

MODELING



GSD :: HL Solution :: Configuration Mngt

As written previously, the creation of complex systems may involve multiplesystem architects, system designers, hw / fw / sw developers, andverification engineers usually splitted into multiple teams.

A key consideration is that the entire design and verification environmentshould be architected so as to facilitate distributed/paralleldesign/verification, all while allowing requirements and modifications to be

tracked and traced.

Then the requirements must have continuous:- Traceability analysis- Impact analysis so that, if a change there is, then the change can be

managed

Then a very sophisticated Configuration Management, so to have:- continuous snapshot of all the portions of the design (hw, fw, and sw)- support for revision, versions- continuous and progressive archiving



GSD :: HL Solution :: Testing

The goal is to address the design/development/manufacturing flaws that are

introduced at every stage to ensure these are detected well before the finalproduct validation for on-time product delivery.

All the methodologies, techniques, and tools regarding White Box Test, BlackBox Test, System Test must be implemented, used and strictly interfaced toRequirements Management.

STAKEHOLDER

REQUIREMENTS

SYSTEM

REQUIREMENTS

SUBSYSTEM

REQUIREMENTS

COMPONENT

REQUIREMENTS

SYSTEM

TEST

INTEGRATION

TEST

COMPONENT

TEST

ACCEPTANCE

TEST


10/96


GSD :: Introduction

Perfect Project Planning, Requirements Management, Tests Managementand Configuration Management are necessary, but not sufficient to solve theproblems.

A new Design & Development paradigm has to be used.

Selex Elsag is using Graphical System Design methodology:

following a Top Down approach

in all the Technological Domains

Architecture

Design Hardware Analog & Digital Engineering

Firmware Engineering

Software Engineering


11/96


GSD :: Introduction

Graphical System Design (GSD) is a modern approach to designing,prototyping, and deploying embedded systems that combines open graphicalprogramming with COTS hardware to simplify development.

This is basically a way for domain experts, or non-embedded experts, that isexperts managing high level abstraction Languages and IntegratedDevelopment Environments to access embedded design without learninglow level development languages and/or design outsourcing.

DEPLOYProduction phase

Target the application to

the same EVB or to the

Custom Board and scale

with the production test

DESIGNConcept phase

Iterate on algorithm or

model development also

using real world stimulus

PROTOTYPEValidation phase

Implement the design on

EVB to validate the

functionality

Basically GSD is implemented in the following three steps:- Design (algorithms at high level abstraction using also real-world stimulus)- Prototype (design implementation & validation on COTS HWdevices/boards)

- Deployment (on the final HW device/board)


12/96


GSD :: Introduction

GSD is part, or better, is a super-set of Electronic System Level (ESL).

ESL allows the utilization of appropriate abstractions in order to increasecomprehension about a system, and to enhance the probability of asuccessful implementation of functionality in a cost-effective manner.

Rapid and correct-by-construction implementation of the system can beautomated using high-level languages towards low-level languagesautomatic translators and putting all that on Evaluation Boards withProgrammable Devices.


13/96



A Top-Down Approach at Selex ElsagSolutions Level


14/96


GSD :: HLA




HIGH LEVELVIRTUAL

PROTOTYPING

MEDIUM LEVELVIRTUAL

PROTOTYPING

LOW LEVELDESIGN


LOW LEVELSYNTHESIS

LOW LEVELVIRTUAL

PROTOTYPING


LOW LEVELSIMULATION



15/96


GSD :: HLA

As said at the beginning of this presentation, Selex Elsag is a Solution Provider.

A communication solution is a complex system composed by connected equipments;connections are both wireline and wireless.

The solution has to meet the stakeholder requirements.

The Selex Elsag design methodology starts with the Solution Architecture design done usingNetworking Simulators.

Advantages:- Project Start

- Immediate definition about equipments and links supported by a direct analysischeaper and faster than System Test using real equipments

- Possibility to receive immediate feedback coming from the Customer

- Make/Buy decision at equipment level

- Update/Upgrade

- Impact analysis given by changes introduced at both equipments and links level- Research:

- Performances evaluation regarding a new protocol to be implemented

Obviously:

- The Equipment/Link models must be carefully validated

- Time/Money effort to Realize/Buy models regarding Company/COTS equipments


16/96


GSD :: HLA :: DES

Network Architecture and Simulation is based on Discrete Events Simulation (DES)

paradigm.

DES

- is not driven by time flow

- is driven by Events, like: a received packet, timer expiration, a process output,

- dynamically models and analyzes a system like a set of entities that interacts to each other.

It may present the disadvantage of high simulation run times for really detailed analysis andstatistics.


17/96


GSD :: HLA :: DES

Usually- A Project Editor graphically represents the

topology of a communications network on a realscenario; the user can create node and linkobjects to represent network topology elementsand configure those quickly using dialog boxes;projects can contain multiple what -if scenariosto facilitate design comparisons.

- A Node Editor captures the architecture of anetwork device or system by depicting the flow

of data (stream) between functional elements,called "modules (and the node input/outputinterfaces); modules typically represent networkprotocols or algorithms and are assignedprocess models (developed in the ProcessEditor) to achieve any required behavior.

- A Process Editor uses a finite state machine(FSM) approach to support detailed specification

of protocols, resources, applications, algorithms,and queuing policies; FSMs are dynamic and canbe spawned during simulation in response tospecific events; the high level code, like C/C++,that governs each state of a process model canbe rapidly customized also using APIs thatfacilitate development and support commoncommunications mechanisms, such as packets,queues, and traffic; a procedure is called

entering or exiting a state; a state transition isdriven by events

A Network Simulator is architected on a series ofhierarchical editors that parallel the structure ofreal networks, equipment, and protocols.


18/96


GSD :: HLA :: DES

All wireless characteristics are seamlessly integrated with higher layer protocol models,providing the ability to model the many aspects of wireless transmission, including:

- RF propagation (path loss with terrain diffraction, fading, and atmospheric attenuation)

- Signal modulation and de-modulation

- Interference and jamming

- Transmitter/receiver characteristics

- Node mobility including handover

- Interconnection with wired transport networks

The wireless links are emulated using customizable Transceiver Pipeline models designed toefficiently calculate wireless effects such as link closure, directional antenna gain, pathloss, noise and interference, modulation effects, and bit errors.


19/96


GSD :: HLA :: DES :: WL (TX)

TransmissionDelay

ChannelMatch

LinkClosure

PropagationDelay

Tx AntennaGain

Start of transmission

2

4

1 3

5

ReceiverGroup0

Start of reception

Executed once at the start of simulation

for each pair of transmitter-receiverchannels

Stage 1: Executed once per transmission

Stages 25: Executed separately for each receiver channel

Packet FailEvaluating nextreceiver channel

Packet IgnoredEvaluating next receiver channel.

Kernel Action: Destroying Packet

Packet Valid / Packet Noise

Copy Packet

Transmitter


20/96


GSD :: HLA :: DES :: WL (RX)

Receiver

Rx AntennaGain

InterferenceNoise

ReceivedPower

Error Allocation

Signal to NoiseRatio

ErrorCorrection

Bit ErrorRate

6 7

8

BackgroundNoise

910

11 1312

End of reception

Noise Packet

Valid Packet

For every receiver channel which passed the transmission stages

Start of reception

1+ Executed one or more times

0+ Executed zero or more times

0+

1+

1+ 1+

Valid Packet

Packet Accept

Packet Reject

(Delete Packet)


21/96


GSD :: HLA :: DES :: SysML/UML

Component_1

Component_1.3Component_1.2

Component_1.1

Component Diagram

-Decomposes the application

-Defines the Interfaces

Class_1

{ attributes_1 }

{ methods_1 }

Class_3{ attributes_3 }

{ methods_3 }

Class_4

{ attributes_4 }

{ methods_4 }

Class_5

{ attributes_5 }

{ methods_5 }

Class_2

{ attributes_2 }

{ methods_2 }

1. State_3

entry / action_3.1

exit / action_3.2

1. State_1

entry / action_1.1

exit / action_1.2

1. State_2

entry / action_2.1

exit / action_2.2

1. State_4

entry / action_4.1

exit / action_4.2

Event_a

Event_b

Event_dEvent_c

Event_e Event_f

Statement_1;

Statement_2;

Statement_n;

Class Diagram

-Abstractions

-Associations

-Operations

State Diagram

(system, component, class)-Functional Lifecycle

-Event Handling

Action Specification

-Processing


22/96


GSD :: HLA :: DES :: SysML/UML

SysML/UML is chosen as system specification language and implementation environment.

New features where added to describe more complete system models made of HW and SW, then aprofile for Network Architecture that allows describing structural and behavioral features usingcomponents, composite components, class, composite classes, objects, and extended statemachine diagrams.

The behavioral model is conceived for code generation.

The Network Architecture UML profile was added in the Profile Section of the UML tool and savedas XML file, then:

- creation of the package

- definition of stereotypes and meta classes they apply to

- tagged values

- stereotypes images

Code Generation is one of the key characteristics of UML:- a PIM (platform independent model) is created in UML (only design)

- PIM can be mapped to a PSM (Platform Specific Model) (which contain design and implementationdetails)

- the PSM is then implemented in C++

The code extraction can be skeleton, partial, or full type.


23/96


GSD :: HLVP




HIGH LEVELVIRTUAL

PROTOTYPING

MEDIUM LEVELVIRTUAL

PROTOTYPING

LOW LEVELDESIGN


LOW LEVELSYNTHESIS

LOW LEVELVIRTUAL

PROTOTYPING


LOW LEVELSIMULATION



24/96


GSD :: HLVP :: SITL

Network Simulators usually have System-in-the-Loop modules providing an interface forconnecting live network hardware or software applications to a discrete event simulation.

The prototype hardware/software application (or COTS) can interact with numerous virtualdevices within the model, potentially avoiding the need for an expensive test lab.

Using SITL users can:> Perform developmental, interoperability, scalability, and conformance testing of prototype

hardware and software applications.> Create a virtual training facility for devices or applications interfacing directly with

simulated network infrastructure containing numerous simulated devices.> Study the behavior of prototype applications by deploying them on a simulated network

topology.> Analyze the performance of a new protocol deployed in a simulated network environment

by injecting real network traffic.


25/96


GSD :: HLVP :: SITL

The computer running DES simulation can be connected simultaneously to multiple live

devices through different network interfaces. The simulation contains one "Gateway" nodefor each live device, which transforms real packets into simulated packets and back, as theytraverse between the real and simulated domains.

When the simulation is started, packets flow in real-time between the live device and thesimulation. Packets are captured, filtered, and converted into simulated packets in the DESsimulation. The simulation must operate in real-time in order to guarantee thesynchronization of the packet conversion and the inward flow of traffic.

In some cases, conversion models are required to decode conversation between live andsimulated devices or vice versa.


26/96


GSD :: HLVP :: SITL

Models only simulation

Interfacing Models and HWs

Complete Simulation


27/96


GSD :: HLVP :: 3D

It is possible also to have a three-dimensional displays of network simulations thatincorporate topology, node relationships, and performance statistics overlaid onrealistically rendered terrain.

This display tool creates a three-dimensional synthetic environment that provides a backdropfor overlaid node mobility and communications system performance.


28/96



A Top-Down Approach at Selex ElsagSW Defined Equipments


29/96


SDR :: Introduction

In this presentation a brief description of a Software Defined Radio (SDR) following theSoftware Communications Architecture (SCA), then:

- Platform (HW/SW)

- Platform (HW)

- Abstraction Layer (SW)

- Waveforms (SW + FW)

and the strong influence of a GSD Top-Down approach in the project.

The main objectives of USA DoD through the JTRS JPO delivering SCA Specs were:

- to enhance the global communication connectivity (Network Centric Warfare)

- to enhance the communication capacity

- to reduce the costs for development, manufacturing and integration all that in the Defense &Aerospace market.


30/96


SDR :: Introduction

WF_1 WF_1

HAL

HW

WF

HAL_1

HW_1

HAL_2

HW_2

WF_1.0

WF_1.1

HAL

HW

(a) (b) (c)

The main objectives of SCA specs are:

- Re configurability (a)

- Portability (b)

- Upgrade ability (c)

The Platform is the HW infrastructure + the HW Abstraction Layer (w/o SW).The Waveform is all the SW processing the voice/data from/to the Antenna/User.


31/96


SDR :: Introduction

Analog

Front End

WF Processing

Unit

User

I/O

MNGT

Unit

WF Flow

MNGT SW

RTOS API

RTOS

BSP

HW

SW/FW

HW

Traditional Radios are:

- difficult to be re-configured- not allowed for portability

- difficult to update/upgrade (HW + SW)

in fact the SW/FW layer

- is strictly linked to the RTOS and HW (GPP)

- is strictly linked to the HW (DSP and FPGA)


32/96


SDR :: Introduction

DEVICE

COMPONENT

WaveForm

COMPONENT

SERVICE

COMPONENT

Application

Abstraction Layer

RTOS

BSP

HW

I/F

Kernel API

Device Driver

Driver

Executing Thread

As said previously the main objective is to abstract the waveform from the platform, then:

- the waveform(s) must be composed by a set of connected SW Waveform components

- the control/management services offered by the radio must be composed of a set ofconnected SW Platform components

- the HW platform must have an abstract representation, that is, the abstract platform iscomposed of a set of connected "logical devices", that is of a set of connected SW PlatformComponents

All the Waveform, Service, and Logical Device SW Components must be connected in anabstract way.


33/96


SDR :: Introduction

The Abstraction Layer is realized using the following technologies:- CORBA MW (middleware)- POSIX (RTOS calls set)

The abstraction Layer is composed of:- AEP (Application Environment Profile) for RTOS POSIX calls- CORBA MW- Core Framework (CF)

The Operating Environment (OE) is composed of:- the Abstraction Layer- RTOS (+BSP)

The Domain Profile, as seen later, contains the configuration information for SDR.

The Application Program Interface (APIs) standard manages the interfaces among waveforms,services, and device components.


34/96


SDR :: Introduction

WAVEFORMS, SERVICES, DEVICES

SOFTWARE COMPONENTS

OE

HW

HW

BSP

OS

AEP

CFCORBA

WAVEFORMS, SERVICES, DEVICES

SOFTWARE COMPONENTS

SW Components have a limited access to the RTOSpassing through the AEP

Core Framework is a set of OO Interfaces (OO I/F)realizing the abstract platform structure where tocompose the waveform to be deployed, and thenexecuted

Every element inside the Core Framework is followingthe SCA specs and it is a CORBA object, that is aninstance of a Class registered onto an ORB (ObjectRequest Broker) by a POA (Portable ObjectAdapter)

Later both ORB and POA explained

CORBA MW has an unlimited access to the OS

Core Framework may have some Adapter towardsnon CORBA devices


35/96


SDR :: Introduction

PLATFORM

COMPONENT

(Device)

PLATFORM

COMPONENT

(Device)

PLATFORM

COMPONENT(Service)

WAVEFORM

COMPONENTWAVEFORM

COMPONENT

WAVEFORM

COMPONENT

WaveForm

PlatForm

API Logic Connection Physical Connection

As seen previously- the limited access to the RTOS (AEP)

- the CF OO interfaces abstracting different implementations of the HW/SW Platform

- the presence of CORBA as "abstract" MW

are strongly increasing the Waveform portability, re-configurability and upgradability.

Obviously if present one or more non-CORBA devices, then there is some limitation.


36/96


SDR :: Introduction

WAVEFORM

COMPONENT

WAVEFORM

COMPONENT

PLATFORM

COMPONENT

(Device)

Abstraction Layer

SCA is introducing new concepts as:

- architecture

- design

- development

- testing

The abstraction layer is allowing the developers to work on components individuallydeveloping and testing independently also using different developmentdesign/programming environments and languages.

(VHDL) (C++) (C++)


37/96


SDR :: Introduction :: CORBA

Client

API Call

RTOS

Bus Driver

Bus I/F

uP1

Board1

Servant

API Call

RTOS

Bus Driver

Bus I/F

uP2

Board2

MAC + PHY (Transport)

We can describe SCA in more details.

Abstraction is given by CORBA and POSIX technologies: POSIX so to restrict/abstract theRTOS calls, CORBA so to abstract communication.

The usual situation regarding the communication on Conventional Radios is:

The Client Process knows if the

- Server Process is local (ApplicationFunction Call)

- Server Process is remote (RTOS APIcall)

The Client Process must know:

- MAC (remote board address)

- Process (memory area address)

Data written in the memory area are:

- object/method to be called

- payload

After the data are written in the memoryarea the Server can elaborate


38/96



Client

API Call

OE

Bus Driver

Bus I/F

uP

Board

Abstraction is represented in the following figure:

Client hasnt to know if the Server is remote or local

Client must call a standard API call asking only for the desired method to be called

API call must reside in a Common Framework

Client must not interact with the RTOS/BSP


39/96



attribute : type

Method(input : type) : output : type

Something from UML Class Diagram:

MAN

TEACHER

is derived

MAN Address

uses

n:mORDER Email

calls

INVOICE InvoiceElement

strongly aggregates

CAR CarElement

Tyre Engine

aggregates

DataFilter

AbstractDataFiler

implements

Computer

calls


40/96



Client

ServerI/FServer

method( )

Address Space 1 Address Space 2

calls implements

CORBA Object Model is based on Interface.

Interface is an Intermediate Class between a Client Class and a Service Class.

Interface defines what the Client can know about the Server and how the Client can interact with theServer, then a Service Operation Oriented (SOA) methodology.

Client and Server must obviously share the Interface Specification, that is an ASCII file written in theIDL (Interface Definition Language) format simply containing: method name and I/O data types.

IDL is a declarative language to define method() and attribute independently from the programminglanguage.

Using the specific IDL Compiler (translator) the IDL is translated into the programming languageused by the Client (or Server) and by the attached ORB.

Then all the assembly is finally compiled to have the executable.


41/96



CORBA

Obj A

CORBA

Obj BORB

CORBA

Obj A

ORB1

GIOP1

IIOP

TCP

IP

LINK

PHY

CORBA

Obj B

ORB2

GIOP2

IIOP

TCP

IP

LINK

PHY

HW

If the CORBA Objects are on the same ORB, then the ORBTransport Protocol is not activated, otherwise yes.

GIOP (General Inter ORB Protocol) is the Protocol used byORBs to exchange messages.

IIOP (Internet Inter ORB Protocol) is the gateway betweenGIOP and the commonly used TCP.

The Flow is:

- the Client asks for a connection/request- the Server accepts the connection/request and waits for it

- the Client sends the request

- the Server elaborates and sends (if any) the answer

- the Client starts the connection using the addressing infoscontained inside the IOR (Interoperable Object Reference)that is contained in the GIOP message

The main nucleus of the CORBA MW is the ORB (Object Request Broker), that:

- identifies where is the Server and its service

- prepares the Server to receive the request

- communicates the request to the Server

- transfers the answer (if any) to the Client

We know that Server/Method and Client/Method at low-level (OS level) are Ports.


42/96



The IOR frame is composed of:

- Transport Name (PCI for embedded, TCP for PC, ...)- MAC Address (identifier of a uP/Embedded or Card/PC or ...)

- Port Number (process executing and waiting for requests)

The MAC Address:

- is obtained at the platform bootstrap by a RTOS call

- is registered on the initialized ORB (ORB knows what MAC Address is managing).- will be used together with the Port to generate the IOR when the Application Corba Object

will be registered on the same ORB

All the IORs are contained in the Name Service that is CORBA DNS (Domain Name Service).


43/96



ORB1 ORB2

Stub

ServerI/F

Method( )

Client

ThreadPool

POA

Skeleton

ServerI/F

Method( )

Server

method()

The Stub is a Client side function that allows the

method() invocation as a local one also if the Serveris remote; the Stub is generated during thecompilation of the IDL file.

The Skeleton is a Server side function that enables theServer to receive the invocation of its method; theSkeleton is generated during the compilation of theIDL file.

POA (Portable Object Adapter) is a group of interfacesthat the Server uses to access the ORB functions; itis the link between the Server and the ORB; it isserving 'n' Servers as the ORB obviously; itmaintains an association between the Object_Id(contained in the IOR) and the Server and so it canroute the request toward the right Server.

The Services offered by the ORB through the POA

include:

- generation and interpretation of the IORs

- method() invocation

- activation / de-activation of the Objects

- mapping of the IORs to the registeredimplementation (DNS)


44/96


SDR :: Introduction :: SCA

Port

PortSupplier

LifeCycle

TestableObject

PropertySet

Resource

ResourceFactory

ApplicationFactory

Application

Device

LoadableDevice

ExecutableDevice

DeviceManager

AggregateDevice

File

FileSystem

FileManager

DomainManager

0..*0..*

0..1

1

0..*

1..*

Core Framework

Device Developer

CF Developer


45/96



Port

PortSupplier

LifeCycle

TestableObject

PropertySet

Resource

ResourceFactory

Port is managing the communication channel for transferring data/control between SCAcompliant software components.

PortSupplier is obtaining a selected Consumer or Producer Port.

LifeCycle is initializing and releasing component specific data for instantiated SCA compliantsoftware component.

TestableObject is testing component implementation.

PropertySet is configuring/retrieving component properties/attributes.

Resource is the Common APIs for control and configuration of a SCA compliant softwarecomponent.

ResourceFactory is creating/destroying Resources.

.... The Waveform is a set of Connected Resources


46/96



PhysicalLayer

ModemDevice

modem_tx_packet_port:

ModemTxPacket

modem_packet_in_port:

ModemTxPacket

modem_tx_flow_ctrl_port:

ModemFlowCtrlTx

modem_packet_sig_out_port:

ModemFlowCtrlTx

Component Name

Component Type

Provides port name:

Interface name

Uses port name:

Interface name

We focus on the communication between components.

We know that the application components (waveform, device, service) are connected each other byports (that are an extension of the Port Interface).

The Uses Port is the Client Port using the service offered by the Server through the Provides Port(the Server Port).

So to realize the connection, the Uses Port has to know the IOR of the Provides Port as in thecommon usage; when connecting to a server offering a service, we need to know the IP Address+ Port, that is Transport + MAC + Port.


47/96



Port

PortSupplier

SW Component A

Resource

SW Component B

0..*0..*

The sequence of operations to have the connection is managed by the Application Factory:

- both the SW Component A and B obtain their Port IOR using the following Function Call

SW Component X :: Resource :: PortSupplier -> getPort()

Input: the name of the Port (that is the method on the Server)

Output: Port IOR

This retrieval is done using the Naming Service (SCA DNS) and then there is the registration at ORB level

- SW Component A obtains / retrieves the IOR for the interested Server method() using the following Function CallSW Component A :: Port -> ConnectPort()

Input: the name of the Server Port (that is the method() on the Server)

Output: IOR of the interested Server method()

- SW Component A and B communicate each other

- SW Component A closes the communication using the Call

SW Component A :: Port -> disconnetPort()

Input: the name of the Server Port (that is the method() on the Server)


48/96



Device

LoadableDevice

ExecutableDevice

DeviceManager

AggregateDevice

0..*

Device: Framework for a devices software profile attribute, state management and status attributes, and capacity

allocation/deallocation operations

LoadableDevice: Framework of operations for loading/unloading software modules onto a device processors memory

ExecutableDevice: Framework of operations foe executing/terminating processes/threads on a device

AggregateDevice: Framework of operations for adding/removing devices to/from a device capable of an aggregaterelationship

DeviceManager: Responsible for creation of logical Devices, and launching service applications on these logicalDevices during a CF Node startup, and deploying and removing these logical Devices and services to/fromthe CF Domain, during CF startup, shutdown, or dynamically at runtime

Logical Device is a SW Componentabstracting the operations allowing theconfiguration and control of a physicalrelated device.

Logical Devices are organized in ahierarchy; the ones, inheriting directlyfrom the Resource, are very high levelcharacterization; the following ones inthe hierarchy are specialized interfaces

for the various types of real devices:ModemDevice, AudioPortDevice,DataDevice, FrontEndDevice, ...


49/96



File: provides the ability to read and write files within a SCA compliant distributed file system

FileSystem: defines CORBA operations that enable remote access to a physical file system

FileManager: appearing as a single FileSystem, provides access to multiple distributed file systems, whose filestorage may span multiple physical file systems (AKA a federated file system).

File

FileSystem

FileManager


50/96



Application Factory: Based on the Domain Profile, creates instances of software applications (waveforms) of aspecific type by:

- Allocating software (Resources) to hardware (Devices)

- Allocating capacities against Devices

- Connecting Resources that make up an Application

- Performing initial configuration on these Resources

Port

ResourceFactory

ApplicationFactory

Resource

Application

Device

LoadableDevice

ExecutableDevice

0...n

1...n

1...n

1...n

1

0...n

1

0..n

0..n


51/96


52/96



The Domain Profile contains all the infos needed for the Domain Manager to work.

The files are in XML format whose syntax is contained in the related Document Type Definition (DTD).

The Domain Manager reads this file using a parser and instantiates its image in memory using the DOM (DocumentObject Model) standard.

This image is accessed by the Domain Manager and then:- DeviceManager- FileSystemManager- ApplicationFactory

Software Package Descriptor (SPD)> Describes a components (CORBA and non-CORBA) implementation(s).Property File (PRF)> Describes properties for a component.Software Component Descriptor (SCD)> Describes a CORBA components characteristics.

Software Assembly Descriptor (SAD)> Describes an applications deployment characteristics.

Device Configuration Descriptor (DCD)> Describes configuration characteristics for DeviceManager.Domain Manager Configuration Descriptor (DMD)> Describes configuration characteristics for DomainManager.Device Package Descriptor (DPD)> Identifies a class of hardware device and its characteristics.Profile Descriptor> Describes a type of file (SAD, SPD, DCD, DMD) along with the file name.


53/96



There are two possible types of SCA connections:

Persistent connections

Typically these are asynchronous messages among devices (events, interrupts, ...); these arerelated to the DeviceManager Domain; the Event Service is also used by the DomainManager to:

- register / un-register devices by DeviceManager

- install / un-install waveform by ApplicationFactory

Direct connections

These are synchronous messages among SW Waveform Components (the connections usingPorts seen some slides before).

The modalities of these two connections are different.


54/96



Every connection has an User and a Provider.In every connection there must be an IOR sending.

In the direct / sync communication:- there is a 1:1 communication

- the Port User knows the Port Provider IOR

In the persistent / async communication:- there is a 1:n communication- the Supplier doesn't know the Consumer IOR(s)- the Supplier knows the Event Channel IOR

CORBA

Transport

Protocol

CORBA

Transport

Protocol

CORBA

Transport

Protocol

CORBA

Transport

Protocol

ORB A ORB BORB A ORB B

API

(Uses Port)

API

(Provides Port)

Supplier

(Uses Port)

Consumer

(Provides Port)

connection

Event Channel

connection


55/96



Supplier 1

Supplier 2

Supplier

Supplier N

Consumer 1

Consumer 2

Consumer

Consumer N

Event Channel

CONSU

MER SU

PPLIER

The Event Channel is:

- Provider of the Supplier

- User of the Consumer

The Consumer is

connected to the Event

Channel that is the

Supplier Proxy

The Supplier is

connected to the Event

Channel that is the

Consumer Proxy

connection connectionThe Supplier

publishes the infos

without knowing the

Consumers (IORs).

The Consumer

subscribes for the

infos withoutknowing the

Suppliers (IORs).


56/96



A Top-Down Approach at Selex ElsagD-HW/FW/SW Flow


57/96


GSD :: MLA/MLVP :: D-HW/FW/SW




HIGH LEVELVIRTUAL

PROTOTYPING

MEDIUM LEVELVIRTUAL

PROTOTYPING

LOW LEVELDESIGN


LOW LEVELSYNTHESIS

LOW LEVELVIRTUAL

PROTOTYPING


LOW LEVEL

SIMULATION



58/96




59/96



Component_1


Component_1.1

Component Diagram



Class_1

{ attributes_1 }

{ methods_1 }

Class_3

{ attributes_3 }

{ methods_3 }

Class_4

{ attributes_4 }

{ methods_4 }

Class_5

{ attributes_5 }

{ methods_5 }

Class_2

{ attributes_2 }

{ methods_2 }

1. State_3

entry / action_3.1

exit / action_3.2

1. State_1entry / action_1.1

exit / action_1.2

1. State_2

entry / action_2.1

exit / action_2.2

1. State_4

entry / action_4.1

exit / action_4.2

Event_a

Event_b

Event_dEvent_c

Event_e Event_f

Statement_1;

Statement_2;

Statement_n;

Class Diagram

-Abstractions

-Associations

-Operations

State Diagram

(system, component, class)

-Functional Lifecycle

-Event Handling


-Processing


60/96


GSD :: LLD/LLVP




HIGH LEVELVIRTUAL

PROTOTYPING

MEDIUM LEVELVIRTUAL

PROTOTYPING

LOW LEVELDESIGN


LOW LEVELSYNTHESIS

LOW LEVELVIRTUAL

PROTOTYPING


LOW LEVEL

SIMULATION



61/96


GSD :: LLD/LLVP

Single Architecture Graphical Environment so to

- define, simulate and analyze the equipment / board architecture (and then thehigh level partitioning) using Executable SysML/UML with opportune profilesand stereotypes

- define, programming, simulate, and analyze the WF components for the GPPProcessing Units

Single Design Graphical Environment so to

- define, simulate, analyze and deploy the digital signal processing WFcomponents for FPGA and DSP Processing Units

- implement HW in the Loop evaluation for a single Processing Unit

- implement System in the Loop simulation


62/96


63/96


GSD :: LLD/LLVP :: OEM

FPGA Manufacturers provide DSP

focused design tools and relatedlibraries that enable the use ofthese inside model-based designenvironments.

Previous experience with FPGAs or

RTL design methodologies are notrequired.

Designs are captured in the DSPmodeling environment usingspecific blocks.

All the downstream FPGAimplementation steps includingsynthesis and place & route areautomatically performed togenerate an FPGA programmingfile.


64/96



The libraries are composed by:

- common DSP building blocks (adders,multipliers, registers, ...)

- complex DSP building blocks (FEC, FFT, filters,memories, ...)

The FPGA Manufacturer IP core generatordelivers optimized results for the selecteddevices.

These plug-in tools provide resource estimators

that quickly estimate the area of a design priorto place and route. This can be a valuable aidin the HW/SW partitioning process by helpingsystem designers take full advantage of theFPGA resources.

GS O


65/96



These plug-in tools provide

accelerated simulation throughHW co-simulation, in fact they willautomatically create a HWsimulation token for a designcaptured in the FPGA blocks thatwill on a set of FPGA evaluationboards.

This HW EVB will co-simulate withthe rest of the EDA system toprovide an accelerated simulation.

GSD LLD/LLVP OEM


66/96



These plug-in tools provide a system

integration platform for the designof DSP FPGAs that allows the RTL,Modeling Blocks, ModelingLanguages and C/C++ componentsof a DSP system to come togetherin a single simulation andimplementation environment.

In fact:

- there is the support of "black box"blocks that allow RTL to beimported and co-simulated usingRTL/Post_Layout simulators

- there is also support of HW/SWmacro for processors integratedonto the FPGA (ISS)


67/96


GSD :: LLD/LLVP :: OEM :: Design Gaps

The main problems arise from the FPGA side:- No portability (design strictly linked to the FPGA Manufacturer / Architecture)

- Synthesis optimized model block by model block, but maybe not for the overall

- Difficulty during the partitioning iterations

Other problems could be:

- C/C++ and Modeling Language blocks driven by the RTL blocks during co-simulation

- Transactions among Processing Units exclusively behavioral

- No single language

(FPGA)

Direct Synthesis / Place & Route


68/96


GSD :: LLD/LLVP :: FPGA High Level Synthesis

High Level Model Synthesis Tools (provided byRTL Synthesis companies) support modelbased design environments.

Specialized IP model libraries allows algorithmand hardware designers to quickly createsynthesizable fixed-point, multi-ratealgorithms.

High Level Synthesis engines allows thecreation of optimized RTL implementations(as pipelining, scheduling, and binding) forthese algorithms given the user-specifiedtarget and architectural constraints.

Sometimes C model available.

(FPGA)

High Level Model Design Model HL Synthesis RTL Synthesis Place & Route


69/96


GSD::LLD/LLVP::FPGA HL Synthesis::Design Gaps

(FPGA)

High Level Model Design Model HL Synthesis RTL Synthesis Place & Route

Problems could be:

- Difficulty during the partitioning iterations

- C/C++ and Modeling Language blocks driven by the RTL blocks during co-simulation

- Transactions among Processing Units exclusively behavioral- No single language


70/96


GSD :: LLD/LLVP :: FPGA C++ High Level Synthesis

(FPGA)

High Level C++ Design C++ HL Synthesis RTL Synthesis Place & Route

High Level C++ Synthesis Tools (provided byRTL synthesis companies) accept a broadsubset of C++ that includes common choicesfor fixed point data types.

Optimizations for parallelism like single- to-multi-threaded and application on multi-levelnested loops are usually available.

C++ code is usually analyzed to decide

architectural performance trade-offs.

For a given set of constraints (clock,throughput and target device) the such toolsusually generate RTL test bench scripts, testvectors, TLM System-C, CA System-Cwrappers, CA RTL test bench.

GSD LLD/LLVP FPGA HDL/C HL S h i


71/96


GSD :: LLD/LLVP :: FPGA HDL/C++ HL Synthesis

(DSP)

High Level Model Design

C++ Coder DSP Deploy

(FPGA)

HDL Coder OEM RTL Synthesis Place & Route

OEM RTL Synthesis Place & Route

Possible alternative given by general purposeModeling Environment providers with HDL codingphase leveraged by OEM environments providedby FPGA manufacturers (company agreement).


72/96



A Top-Down Approach at Selex ElsagD-HW/FW/SW (possible) Future Flow

Design Gaps


73/96


Design Gaps

Embedded Design Gaps:

- Different Design Languages are spoken

- at different levels of abstraction

- by System, HW, SW designers and developers

- Simulation Time is too long

- Problems, bottlenecks, and misunderstandings are detected too late

Then a more efficient platform modeling must be found.

Design Gaps :: Analysis


74/96


Design Gaps :: Analysis

Different Languages Gap

System Design is standardized on Matlab.Hardware Design is standardized on Verilog and VHDL.

Software Design is standardized on C++.

Simulation Time too long

Hardware Design simulation is done at Register Transfer Level and at gate Level.

Problems found too late

Analysis at Higher Level of Abstraction is done with difficulty.

This is a mandatory problem because there are the simultaneous increase indesign complexity and pressure to get designs out faster with first time designsuccess.

A possibility can be given by System-C & Transaction Level Modeling.


75/96


76/96

System C :: Language Features


77/96


System-C :: Language Features

Modules are the basic building blocks of a System-C design hierarchy; they arestructural entities which contain processes, ports, channels, and other modules.A System-C model usually consists of several modules which communicate via ports.

Channels are the communication elements of System-C; they implement one or moreinterfaces, and serve as a container for communication functionality; they can be eithersimple wires or complex communication mechanisms; in the library there are channelentities from the elementary signals, buffers, fifo, mutex, semaphores, ... to buses, ....

Signals are equivalent to the Verilog wire.

Ports are the objects through which a module can access a channels interface, thenthey are allowing communication from inside a module to the outside (usually to othermodules).

Processes are the main computation elements. They are concurrent.

Events allow synchronization between processes.

There are several Data Types which support the modeling of hardware (from bits, ...to fixed point representation).

System C :: Languages Comparison


78/96


System-C :: Languages Comparison

Comparing the languages, we have:

Requirements

Architecture

HW/SW

Transistors

BehavioralFunctional Verification

Test Bench

Register Transfer Level

Gates

Verilog VHDL

VHDL

System

Verilog

SystemC

Matlab

System-C :: Advantages


79/96


System-C :: Advantages

Same LanguageC++ adopted as single language by System, HW, SW Designers and Developers(C++ can be derived by languages like Matlab)

Faster Simulation TimeSame performances at Register Transfer Level, but higher and higher

performances at higher levels of abstraction (moving from pin level to transaction

level models, moving from transaction level models to un-timed level models)

Problems found beforeSystem-C offers real productivity gains by letting engineers design both the HWand the SW components together as these components would exist on the finalsystem, but at higher level of abstraction. This means that it is possible toconcentrate on the actual functionality of the system more than of itsimplementation details. Moreover, since the detailed implementation has not beenfinalized yet, it is still possible to perform consistent changes to the design,enabling an effective evaluation of different architecture alternatives (including thepartitioning of the functionalities between HW and SW).

TLM :: Introduction


80/96


TLM :: Introduction

Using a language for System-Level modeling, such as System-C, is not enough forbuilding an effective simulatable model: it is also necessary to define modelingstyles and interoperability rules among the various models.

Moreover, it is mandatory to determine which features to abstract (and to whatextent) so to create an executable model that allows a meaningful, efficient, andaccurate analysis of the intended system.

Transaction Level Modeling (TLM) is an efficient technique for abstract modeling ofcommunication (and then related computation): the transaction is the exchange ofdata or an event between two System-C modules. The details of communicationbetween the modules are separated from the implementation details of both thefunctional unitsand communication architecture.

Communication mechanisms (fifos, busses, ) are modeled as channels, and are

presented to modules using System-C interface classes: a small set of System-C /TLM Interfaces can be defined and different component (at different levels ofabstraction) can implement these interfaces.

Transaction requests take place by calling interface functions of these channelmodels, which encapsulate low-level details of the information exchange.

TLM :: Introduction


81/96


TLM :: Introduction

A better acronym would have been TBM (Transaction Based Modeling) because thistechnique doesnt denote a single level of abstraction, but rather a modeling

technique used at different levels of abstraction and where at least one, betweencomputation and communication, introduces an approximate concept of time.

In fact, the underlying concept of TLM is centered on modeling only the level ofdetail that is needed at the used level of abstraction; by eliminating the un-necessary details, design teams can obtain huge gains in simulation speed; at thislevel, changes to the design are also relatively easy and cost-effective because thedevelopment team has not yet delved in low-details such as the chosen bus.

At the transaction level, the emphasis is more on the functionality of the datatransfers - what data are transferred to and from what locations - and less on theiractual implementation, that is, on the actual protocol used for data transfer. Thisapproach makes it easier for the system-level designer to experiment, for example,

with different bus architectures (all supporting a common abstract interface)without having to recode models that interact with any of the buses, provided thesemodels interact with the bus though the common interface.

TLM is coming with a library of System-C primitives allowing the users toimplement several Transaction Level communication protocols with differentdegrees of accuracy.

TLM :: Introduction


82/96


TLM :: Introduction

Design, Simulation and Analysis must be follow different levels of Abstraction.

UTFU TF UTF

UTFU TF

TL MT LM TL M

TL M TL M

RTLR TL RTL

RTL RTL

The Un-Timed Level is allowing to provide theexecutable specification

The Transaction Level is allowing:- Early analysis of HW and HW/SW Architecture

- Timing Estimation

The Pin Level is allowing:- RTL/behavioral HW/SW design and verification

At Transaction Level the focus is about: the type of data that flows (from/to andtiming estimation).

TLM :: Basics


83/96


TLM :: Basics

Primitive and Hierarchical Channels are showed in the following figure.

Hierarchical Channels contain processes, ports, modules and channels, but PrimitiveChannels not.Communication is based on Interface Method Calls (IMC):

> Process calls an interface method of a channel> The collection of a fixed set of communication Methods is called an Interface(virtual object without data)

> Channels implement one or more Interfaces> Modules can be connected via their Ports to those Channels

At higher level of abstraction TLM abstracts the signal-level details of a communicationprotocol in a function call specifying payload and its attribute (command, data, address,enables, ). So instead of having to wiggle individual signals in the proper order, you

just issue a function call to say read data.


84/96

TLM :: Model Types


85/96


TLM :: Model Types

Processing Elements Assembly Model

Higher level of abstraction.

The Processing Elements (PE) arecommunicating each other by messagepassing channels.

Bus Arbitration Model

Superior level of abstraction.

Abstract bus channels.

Bus Arbiter arbitrates bus conflict.

TLM :: Model Types


86/96


TLM :: Model Types

Time Accurate CommunicationModel


There is an approximate timedcomputation (time constraints aregiven).

Protocol channel provides functionsfor all abstraction bus transactions.

TLM :: Model Types


87/96


TLM :: Model Types

Cycle Accurate Communication Model


Modeled at RTL (Register Transfer Level).

PEs are pin accurate and execute cycle accurately.

Wrappers convert data transfer from higher level of abstraction to lower level ofabstraction.

TLM :: Model Types


88/96


TLM :: Model Types

TLM :: Model Types


89/96


TLM :: Model Types

TLM :: Model Types :: Design Tasks


90/96


TLM :: Model Types :: Design Tasks

Bus-arbitrationmodel

Specification

model

1

PE-assemblymodel

2

Time-accurate

Communicationmodel

3

Implementationmodel

4

Cycle-accurate

Computationmodel

5

6

7 8

System

Design

Component

Design

Design Tasks

1) PE assembly and model generation

2) Communication Exploration and bus-arbitration model generation

3) Protocol refinement and time-accuratecommunication model generation

4) RTL/ISS synthesis

5) IP Replacement

6) Communication synthesis andinterconnect network generation

7) Accurate communication feedback

8) Accurate computation feedback

System-C :: Constraints


91/96


Syste C Co st a ts

As seen previously the road toward abstraction was from transistor to gate to

register to transaction, allowing the designers/developers:-the implementation of more and more complex digital systems

-the focalization on

-Task partitioning

-System functionality

-More organized test benches

But, any level of abstraction requires a way of describing its immediate lower levelin a compatible language with the higher abstraction level:

From System-C (Transaction) to HDL (Register)

From HDL (Register) to Net List (Gate)

From Net list (Gate) to Component (Transistor)

System-C :: Design Methodologies


92/96


y g g



93/96


y g g



94/96


y g g

Requirements must strictly follow the entire Design and Development process.

An Executable SysML/UML approach can:

-Offer an High Level of Abstraction

-Allow the Model Execution (a model independent of, and earlier than implementationchoices

The model must be translated:

-to the lower Level of Abstraction (System-C)

-to the implementation (C/C++)

Future Flow :: SysML/UML


95/96


y

Component_1


Component_1.1

Component Diagram



Class_1

{ attributes_1 }

{ methods_1 }

Class_3

{ attributes_3 }

{ methods_3 }

Class_4

{ attributes_4 }

{ methods_4 }

Class_5

{ attributes_5 }

{ methods_5 }

Class_2

{ attributes_2 }

{ methods_2 }

1. State_3

entry / action_3.1

exit / action_3.2

1. State_1

entry / action_1.1

exit / action_1.2

1. State_2

entry / action_2.1

exit / action_2.2

1. State_4

entry / action_4.1

exit / action_4.2

Event_a

Event_b

Event_dEvent_c

Event_e Event_f

Statement_1;

Statement_2;

Statement_n;

Class Diagram

-Abstractions

-Associations

-Operations

State Diagram

(system, component, class)

-Functional Lifecycle

-Event Handling


-Processing

VSD


96/96

System-C and TLM are two of the enabling technologies for VSD (Virtualized Systems

Development) that is a development methodology where the actual hardware of asystem is replaced with a virtual platform running on a PC/Server.

The virtual platform can run at different levels of abstraction and it is fast enough tobe used as an alternative to physical hardware for HW/FW/SW development.

The virtual platform should be full-system, i.e., contain the whole target system,including multiple chips, the board (or eventually multiple boards and multiplenetworks).

VSD provides access to the target system long before prototype hardware is available;this enables FW/SW development to start early.

Progettazione Grafica di Sistemi: un approccio top-down di Selex Communications

Documents

Transcript of Progettazione Grafica di Sistemi: un approccio top-down di Selex Communications