AES Module 2 Notes
AES Module 2 Notes
Module – 2
Software CoDesign and Program Modelling
101
Fundamental Issues in Hardware Software Co-Design
In hardware software co-design, models are used for capturing and describing the
system characteristics.
A model is a formal system consisting of objects and composition rules.
It is hard to make a decision on which model should be followed in a particular
system design.
Most often designers switch between a variety of models from the requirements
specification to the implementation aspect of the system design.
The reason being, the objective varies with each phase.
For example, at the specification stage, only the functionality of the system is
in focus and not the implementation information.
When the design moves to the implementation aspect, the information about
the system components is revealed and the designer has to switch to a model
capable of capturing the system's structure.
A model only captures the system characteristics and does not provide information on
'how the system can be manufactured?’.
The architecture specifies how a system is going to implement in terms of the number
and types of different components and the interconnection among them.
The commonly used architectures in system design are Controller Architecture,
Datapath Architecture, Complex Instruction Set Computing (CISC), Reduced
Instruction Set Computing (RISC), Very Long Instruction Word Computing (VLIW),
Single Instruction Multiple Data (SIMD), Multiple Instruction Multiple Data (MIMD),
etc.
Some of them fall into Application Specific Architecture Class (like controller
architecture), while others fall into either general purpose architecture class
(CISC, RISC, etc.) or Parallel processing class (like VLIW, SIMD, MIMD,
etc.).
A model can be captured using multiple programming languages like C, C++, C#,
Java, etc. for software implementations and languages like VHDL, System C, Verilog,
etc. for hardware implementations.
On the other hand, a single language can be used for capturing a variety of models.
Certain languages are good in capturing certain computational model.
For example, C++ is a good candidate for capturing an object oriented model.
The only pre-requisite in selecting a programming language for capturing a model is
that the language should capture the model easily.
The Data Flow Graph (DFG) model translates the data processing requirements into a
data flow graph.
It is a data driven model in which the program execution is determined by data.
This model emphasises on the data and operations on the data which transforms the
input data to output data.
Embedded applications which are computational intensive and data driven are
modelled using the DFG model.
DSP applications are typical examples for it.
Data Flow Graph (DFG) is a visual model in which the operation on the data
(process) is represented using a block (circle) and data flow is represented using
arrows.
An inward arrow to the process (circle) represents input data and an outward arrow
from the process (circle) represents output data in DFG notation.
𝑥 = 𝑎 + 𝑏 and 𝑦 = 𝑥 − 𝑐.
Suppose one of the functions in our application contains the computational requirement
17EC62
In a DFG model, a data path is the data flow path from input to output.
A DFG model is said to be acyclic DFG (ADFG) if it doesn't contain multiple values
for the input variable and multiple output values for a given set of input(s).
Feedback inputs (Output is fed back to Input), events, etc. are examples for
non- acyclic inputs.
A DFG model translates the program as a single sequential process execution.
The DFG model is a data driven model in which the execution is controlled by data and
it doesn't involve any control operations (conditionals).
The Control DFG (CDFG) model is used for modelling applications involving
conditional program execution.
CDFG models contains both data operations and control operations. The CDFG uses
Data Flow Graph (DFG) as element and conditional (constructs) as decision makers.
CDFG contains both data flow nodes and decision nodes, whereas DFG contains only
data flow nodes.
𝐼𝑓 𝑓𝑙𝑎𝑔 = 1, 𝑥 = 𝑎 + 𝑏; 𝑒𝑙𝑠𝑒 𝑦 = 𝑎 − 𝑏;
Consider the implementation of the CDFG for the following requirement.
The State Machine Model is used for modelling reactive or event-driven embedded
systems whose processing behaviour are dependent on state transitions.
Embedded systems used in the control and industrial applications are typical
examples for event driven systems.
The State Machine model describes the system behaviour with 'States', 'Events', 'Actions'
and 'Transitions’.
State is a representation of a current situation.
An event is an input to the state.
The event acts as stimuli for state transition.
Transition is the movement from one state to another.
Action is an activity to be performed by the state machine.
A Finite State Machine (FSM) model is one in which the number of states are finite.
The system is described using a finite number of possible states.
As an example, let us consider the design of an embedded system for driver/passenger
'Seat Belt Warning' in an automotive using the FSM model.
The system requirements are captured as.
When the vehicle ignition is turned on and the seat belt is not fastened within
10 seconds of ignition ON, the system generates an alarm signal for 5 seconds.
The Alarm is turned off when the alarm time (5 seconds) expires or if the
driver/passenger fastens the belt or if the ignition switch is turned off,
whichever happens first.
The 'Ignition Key ON' event triggers the 10 second timer and transitions the state to
'Waiting’.
If a Seat Belt ON’ or 'Ignition Key OFF' event occurs during the wait state, the state
transitions into 'Alarm Off’.
When the wait timer expires in the waiting state, the event 'Timer Expire' is generated
and it transitions the state to 'Alarm On' from the 'Waiting' state.
The 'Alarm On' state continues until a 'Seat Belt ON' or 'Ignition Key OFF' event or
'Alarm Time Expire' event, whichever occurs first.
The occurrence of any of these events transitions the state to 'Alarm Off’.
Design an automatic tea/coffee vending machine based on FSM model for the
following requirement.
The tea/coffee vending is initiated by user inserting a 5 rupee coin.
After inserting the coin, the user can either select 'Coffee' or 'Tea' or press
'Cancel' to cancel the order and take back the coin.
Solution
Design a coin operated public telephone unit based on FSM model for the following
requirements.
The calling process is initiated by lifting the receiver (off-hook) of the
telephone unit.
After lifting the phone the user needs to insert a 1 rupee coin to make the call.
If the line is busy, the coin is returned on placing the receiver back on the
hook (on-hook).
If the line is through, the user is allowed to talk till 60 seconds and at the end
of 45th second, prompt for inserting another 1 rupee coin for continuing the
call is initiated.
If the user doesn't insert another 1 rupee coin, the call is terminated on
completing the 60 seconds time slot.
The system is ready to accept new call request when the receiver is placed back
on the hook (on-hook).
The system goes to the 'Out of Order' state when there is a line fault.
Sequential Program Model
Object-Oriented Model
The object-oriented model is an object based model for modelling system requirements.
It disseminates a complex software requirement into simple well defined pieces called
objects.
Object-oriented model brings re-usability, maintainability and productivity in system
design.
In the object-oriented modelling, object is an entity used for representing or modelling
a particular piece of the system.
Each object is characterized by a set of unique behaviour and state.
A class is an abstract description of a set of objects and it can be considered as a
'blueprint' of an object.
A class represents the state of an object through member variables and object
behaviour through member functions.
The member variables and member functions of a class can be private, public or protected.
Private member variables and functions are accessible only within the class,
whereas public variables and functions are accessible within the class as well
as outside the class.
The protected variables and functions are protected from external access.
However, classes derived from a parent class can also access the protected member
functions and variables.
The embedded firmware is responsible for controlling the various peripherals of the
embedded hardware and generating response in accordance with the functional
requirements.
Firmware is considered as the master brain of the embedded system.
Imparting intelligence to an Embedded system is a one time process and it can happen
at any stage.
It can be immediately after the fabrication of the embedded hardware or at a
later stage.
For most of the embedded products, the embedded firmware is stored at a permanent
memory (ROM) and they are non-alterable by end users.
Some of the embedded products used in the Control and Instrumentation
domain are adaptive.
Designing embedded firmware requires understanding of the particular embedded
product hardware, like various component interfacing, memory map details, I/O port
details, configuration and register details of various hardware chips used and some
programming language.
Embedded firmware development process starts with the conversion of the firmware
requirements into a program model using modelling tools.
Once the program model is created, the next step is the implementation of the tasks
and actions by capturing the model using a language which is understandable by the
target processor/controller.
The firmware design approaches for embedded product is purely dependent on the
complexity of the functions to be performed, the speed of operation required, etc.
Two basic approaches are used for embedded firmware design:
Super Loop Based Approach (Conventional Procedural Based Design)
Embedded Operating System (OS) Based Approach
The Super Loop based firmware development approach is adopted for applications
that are not time critical and where the response time is not so important.
It is very similar to a conventional procedural programming where the code is
executed task by task.
The task listed at the top of the program code is executed first and the tasks just below
the top are executed after completing the first task.
In a multiple task based system, each task is executed in serial in this approach.
The firmware execution flow for this will be
Configure the common parameters and perform initialisation for various
hardware components memory, registers, etc.
17EC62
Almost all tasks in embedded applications are non-ending and are repeated infinitely
throughout the operation.
This repetition is achieved by using an infinite loop.
Hence the name 'Super loop based approach’.
The only way to come out of the loop is either a hardware reset or an interrupt assertion.
Advantage of Super Loop Based Approach:
It doesn't require an operating system
There is no need for scheduling which task is to be executed and assigning
priority to each task.
The priorities are fixed and the order in which the tasks to be executed are also
fixed.
Hence the code for performing these tasks will be residing in the code memory
without an operating system image.
Applications of Super Loop Based Approach:
This type of design is deployed in low-cost embedded products and products
where response time is not time critical.
Some embedded products demands this type of approach if some tasks itself
are sequential.
17EC62
For example, reading/writing data to and from a card using a card reader
requires a sequence of operations like checking the presence of card,
authenticating the operation, reading/writing, etc.
It should strictly follow a specified sequence and the combination of these
series of tasks constitutes a single task-namely data read/write.
A typical example of a 'Super loop based’ product is an electronic video game toy
containing keypad and display unit.
The program running inside the product may be designed in such a way that it
reads the keys to detect whether the user has given any input and if any key
press is detected the graphic display is updated.
The keyboard scanning and display updating happens at a reasonably high rate.
Even if the application misses a key press, it won't create any critical issues;
rather it will be treated as a bug in the firmware.
Drawbacks of Super Loop Based Approach:
Any failure in any part of a single task will affect the total system.
If the program hangs up at some point while executing a task, it will
remain there forever and ultimately the product stops functioning.
Watch Dog Timers (WDTs) can be used to overcome this, but this, in
turn, may cause additional hardware cost and firmware overheads.
Lack of real timeliness.
If the number of tasks to be executed within an application increases, the
time at which each task is repeated also increases.
This brings the probability of missing out some events.
The Embedded Operating System (OS) based approach contains operating systems,
which can be either a General Purpose Operating System (GPOS) or a Real Time
Operating System (RTOS) to host the user written application firmware.
The General Purpose OS (GPOS) based design is very similar to a conventional PC
based application development where the device contains an operating system
(Windows/Unix/Linux, etc. for Desktop PCs) and you will be creating and running
user applications on top of it.
Example of a GPOS used in embedded product development is Microsoft
Windows XP Embedded.
Examples of Embedded products using Microsoft Windows XP OS are
Personal Digital Assistants (PDAs), Hand held devices/Portable devices and
Point of Sale (POS) terminals.
Use of GPOS in embedded products merges the demarcation of Embedded Systems
and general computing systems in terms of OS.
For developing applications on top of the OS, the OS supported APIs are used.
Similar to the different hardware specific drivers, OS based applications also require
'Driver software' for different hardware present on the board to communicate with
them.
17EC62
Each source module is written in Assembly and is stored as .src file or .asm file.
Each file can be assembled separately to examine the syntax errors and incorrect
assembly instructions.
On successful assembling of each .src/.asm file a corresponding object file is created with
extension '.obj’.
17EC62
The object file does not contain the absolute address of where the generated
code needs to be placed on the program memory and hence it is called a re-
locatable segment.
It can be placed at any code memory location and it is the responsibility. of the
linker/locater to assign absolute address for this module.
Libraries are specially formatted, ordered program collections of object modules that may
be used by the linker at a later time.
Library files are generated with extension '. lib’.
When the linker processes a library, only those object modules in the library that are
necessary to create the program are used.
Library file is some kind of source code hiding technique.
For example, 'LIB51' from Keil Software is an example for a library creator and
it is used for creating library files for A51 Assembler/C51 Compiler for 8051
specific controllers.
Linker and Locater is another software utility responsible for "linking the various
object modules in a multi-module project and assigning absolute address to each
module".
Linker generates an absolute object module by extracting the object modules from the
library, if any, and those obj files created by the assembler, which is generated by
assembling the individual modules of a project.
It is the responsibility of the linker to link any external dependent variables or
functions declared on various modules and resolve the external dependencies among
the modules.
An absolute object file or module does not contain any re-locatable code or data.
All code and data reside at fixed memory locations.
The absolute object file is used for creating hex files for dumping into the code
memory of the processor/controller.
'BL51' from Keil Software is an example for a Linker & Locater for A51
Assembler/C51 Compiler for 8051 specific controller.
HEX files are ASCII files that contain a hexadecimal representation of target application.
17EC62
Hex file is created from the final 'Absolute Object File' using the Object to Hex File
Converter utility.
'OH51' from Keil software is an example for Object to Hex File Converter
utility for A51 Assembler/C51 Compiler for 8051 specific controller.
Also more lines of assembly code are required for performing an action which
can be done with a single instruction in a high-level language like 'C'.
Developer Dependency
Unlike high level languages, there is no common written rule for developing
assembly language based applications.
In assembly language programming, the developers will have the freedom to
choose the different memory location and registers.
Also the programming approach varies from developer to developer depending
on his/her taste.
For example, moving data from a memory location to accumulator can be achieved
through different approaches.
If the approach done by a developer is not documented properly at the
development stage, he/she may not be able to recollect why this approach is
followed at a later stage or when a new developer is instructed to analyse this
code, he/she also may not be able to understand what is done and why it is
done.
Hence upgrading an assembly program or modifying it on a later stage is very
difficult.
Non-Portable
Target applications written in assembly instructions are valid only for that
particular family of processors (e.g. Application written for Intel x86 family of
processors) and cannot be re-used for another target processors/controllers
(Say ARM11 family of processors).
If the target processor/controller changes, a complete re-writing of the
application using the assembly instructions for the new target processor/controller
is required.
Any high level language (like C, C++ or Java) with a supported cross compiler for the
target processor can be used for embedded firmware development.
The most commonly used high level language for embedded firmware application
development is 'C’.
‘C’ is well defined, easy to use high level language with extensive cross
platform development tool support.
Nowadays cross-compilers for C++ is also emerging out and embedded developers
are making use of C++ for embedded application development.
The various steps involved in high level language based embedded firmware
development is same as that of assembly language based development except that the
conversion of source file written in high level language to object file is done by a
cross-compiler.
In Assembly language based development it is carried out by an assembler.
The various steps involved in the conversion of a program written in high level
language to corresponding binary file/machine language is illustrated in the figure.
17EC62
The program written in any of the high level languages is saved with the
corresponding language extension (.c for C, .cpp for C++ etc).
Any text editor like ‘Notepad' or 'WordPad' from Microsoft or the text editor provided by
an Integrated Development (IDE) tool can be used for writing the program.
Most of the high level languages support modular programming approach and hence
we can have multiple source files called modules written in corresponding high level
language.
The source files corresponding to each module is represented by a file with
corresponding language extension.
Translation of high level source code to executable object code is done by across-
compiler. Each high level language should have a cross-compiler for converting the high
level source code into the target processor machine code.
C51 Cross-compiler from Keil software is an example for Cross-compiler used
for 'C' language for the 8051 family of microcontroller.
Conversion of each module's source code to corresponding object file is performed by
the cross-compiler.
Rest of the steps involved in the conversion of high level language to target
processor's machine code are same as that of the steps involved in assembly language
based development.
Certain embedded firmware development situations may demand the mixing of high
level language with Assembly and vice versa.
High level language and assembly languages are usually mixed in three ways:
Mixing Assembly Language with High Level Language
Mixing High Level Language with Assembly Language
Inline Assembly programming
Mixing the code written in a high level language like 'C' and Assembly language is
useful in the following scenarios:
The source code is already available in Assembly language and a routine written
in a high level language like 'C' needs to be included to the existing code.
The entire source code is planned in Assembly code for various reasons like
optimised code, optimal performance, efficient code memory utilisation and
proven expertise in handling the Assembly, etc. But some portions of the code
may be very difficult and tedious to code in Assembly. For example, 16-bit
multiplication and division in 8051 Assembly Language.
To include built in library functions written in 'C' language provided by the
cross compiler. For example, Built in Graphics library functions and String
operations supported by 'C’.
Most often the functions written in 'C' use parameter passing to the function and
returns value/s to the calling functions.
Parameters are passed to the function and values are returned from the function using
CPU registers, stack memory and fixed memory.
Its implementation is cross compiler dependent and it varies across cross compilers.
130
17EC62