1. Basics of Embedded Systems IAX0230 Design Cycle: Modeling, Modular Programming, Debugging, Testing
Prof. Dr. Kalle Tammemäe
Prof. Dr.-Ing. Thomas Hollstein
Dr. Uljana Reinsalu

2. Outline Product Life Cycles Design Specification System Architecture
Implementation
Integration

3. Technology Hype Cycle

4. Technology Hype Cycle

5. System Design: V Model (HW/SW)
System Properties and Constraints
Customer Application
Product
Level
Quality Assurance
Analysis of
System Requirements
System Delivery
Validation
Product Spec.
Product
Cost Analysis
Quality Assurance
System
Level
Design of
System Architecture
System Integration
Abstract Interfaces
Prototype Generation and/or
Manufacturing
Validation
Analysis of HW/SW
Component Requirements
Quality Assurance
HW/SW
Component
Level
HW/SW
Integration
Validation
HW/SW Co-Design
Implemented HW/SW Modules
HW/SW
IP Database
and Implementation
Level
HW and SW Component
Implementation

6. Electronic Control Unit 1
Specification Management
Example: Automotive Electronics:
Source: Audi
Car Electronics
OEM
Requested specification
(R-Spec)
Committed specification
(C-Spec)
Integration Test & Certification
(ITC)
ITEMIZATION: SUBCONTRACT
Electronic Control Unit 1
...
ECU n
Tier 1
R-Spec
(ITC)
...
(C-Spec)
...
ASIC 1
ASIC k
Tier 2
PARALLELIZED DEVELOPMENT PROGRESS

7. Client‘s feedback, new features, new product ideas
Product Life Cycle
New requirements
New constraints
Requirements
Constraints
Client‘s feedback, new features, new product ideas
What?
Client: 
Analysis
Deployment
Specifications
Constraints
Interaction meeting Specs
Comm.
Works?
How?
Engineering!
Design
Integration & Test
Requirements are broad and Specifications go into the details.
Block Diagrams, Algorithms, Data Structures, Data
Flow Graphs, Interfacing
Components meeting Specs
Development
Component Testing
Works? Validation of Correctness, Performance & Efficiency
Implementation
Hardware
Software

8. Design Specification: Data Flow Graph
Example: Position Measurement System
A data flow-graph showing how the position signal passes through the system
Rectangles represent h/w components and Ovals represent s/w modules
Data flow-graphs give a high-level design of the system showing the flow of “information”

9. Design Specification: Call Flow Graph
Position Measurement System
Call Flow-Graphs give a high-level detail of the various modules (hardware and software) and their interactions.
Normally h/w is passive and software initiates communication between the h/w and s/w. However it is possible for the h/w to initiate communication by using interrupts. The h/w causes an interrupt in response to which an ISR (interrupt service routine) is executed. The Timer ISR in this system gets the next sample from the ADC driver, converts it to a position value and sends it to the LCD driver for display on the LCD h/w.
[J.Valvano Lec]

10. Design Specification: Structured Control-Flow
Common Constructs (as Flowcharts)
The Fork-Join construct is used in Parallel programming. This is different from multi-threading used in concurrent (Distributed) programming. In multi-threading there may be multiple threads that are active but at any given instant only one of them is being executed.
In desktop systems that have multiple cores and parallel computers with several processors, multiple threads can be simultaneously executed.
[J.Valvano Lec]

11. Design Specification: Flowchart
Example: Toaster oven:
[J.Valvano Lec]

12. Design Specification: Flowchart
Example 1.3. Design a flowchart for a system that performs two independent tasks. The first task is to output a 20 kHz square wave on PORTA in real time (period is 50 ms). The second task is to read a value from PORTB, divide the value by 4, add 12, and output the result on PORTD. This second task is repeated over and over.
< : Hardware Interrupt causing the main program to be suspended and the corresponding ISR to execute
> : Return from Interrupt causing the control to be returned to the point where the main program was suspended.
The execution sequence of this simple system might be something like: ABCDB<E>CDBC<E>DBCD<E>BCD…
We say this code is multi-threaded because we have two threads: The foreground thread computes the primes and the background thread issues a pulse. They are both active at the same time.
[J.Valvano Lec] 12

13. Test: Black Box Testing
Observation points: access to outer port signals only (testing of components which don‘t allow inner access; the internal structure is not known)
Strengh of Method: Test against specification possible
Component under Test
Inputs
Outputs
OBSERVATION POINT
OBSERVATION POINT

14. Test: White Box Testing
Observation points: outer ports and partially inner objects/code; inner structure is known and can be observed
Component under Test
Inputs
Outputs
OBSERVATION POINT
OBSERVATION POINT

15. Test: White Box Testing
Also called: „Glass Box Test“
Internal structure/source code is known
Control-flow oriented test method; test of
Line coverage (each line of code executed)
Statement/node coverage (each statement is executed
Branch/edge coverage (all branches of control-flow are executed)
Condition/term coverage (coverage of logical terms in conditions)
Path coverage: consideration of pathes through a module
White-Box tests are not sufficient as only test method; they should be combined with black box tests
Advantage: Increase of test performance
Disadvantage: test against specification difficult

16. Debugging Aka: Testing, Diagnostics, Verification Debugging Actions
Functional debugging, input/output values
Performance debugging, input/output values with time
Tracing, measure sequence of operations
Profiling,
measure percentage for tasks,
time relationship between tasks
Performance measurement, how fast it executes
Optimization, make tradeoffs for overall goals:
improve speed,
improve accuracy,
reduce memory,
reduce power,
reduce size,
reduce cost
Debugging principles
Control and observability
Can’t see everything; need to be smart when debugging
[J.Valvano Lec] 16

17. Debugging Intrusiveness
Intrusive Debugging
degree of perturbation caused by the debugging itself
how much the debugging slows down execution
Non-intrusive Debugging
characteristic or quality of a debugger
allows system to operate as if debugger did not exist
e.g., logic analyzer, ICE
Minimally intrusive
negligible effect on the system being debugged
e.g., dumps (ScanPoint) and monitors
Highly intrusive
print statements, breakpoints and single-stepping
Minimally intrusive
Dumps execute faster (<1us) compared to print statements (10ms)
[J.Valvano Lec] 17

18. Debugging Functionaliy in Keil SW
Interface
Breakpoints
Registers including xPSR
Memory and Watch Windows
Logic Analyzer, GPIO Panel
Single Step, StepOver, StepOut, Run, Run to Cursor
Watching Variables in Assembly
EXPORT VarName[DATA,SIZE=4]
Command Interface (Advanced but useful)
WS 1, `VarName,0x10
LA (PORTD & 0x02)>>1
Commands given: 1:
WS 1, `VarName,0x10
Puts the variable called VarName in the first watch window 2:
LA (PORTD & 0x02)>>1
Puts port D pin 2 in logic anlayzer
[J.Valvano Lec] 18

19. Debugging
Instrumentation: Code we add to the system that aids in debugging
E.g., print statements
Good practice: Define instruments with specific pattern in their names
Use instruments that test a run time global flag
leaves a permanent copy of the debugging code
causing it to suffer a runtime overhead
simplifies “on-site” customer support.
Use conditional compilation (or conditional assembly)
Keil supports conditional assembly
Easy to remove all instruments
Visualization: How the debugging information is displayed
Black box testing
Control inputs, observe outputs
White box testing
0) pick the most likely place of failure
1) desk check: conceive of what you expect will happen at each step
2) breakpoint at the start of the place
3) single step (or step over)
4) compare what actually happened to what you wanted to have happen
[J.Valvano Lec] 19

20. Conclusion Specification has to be set up seriously
Design Implementation: consider the necessity of test during design and plan test procedures
Structures Design approach (block diagram, control & data flow graphs, ...) increases implementation and test efficiency and also becames part of the code documentation
minimum 50% of the the overall effort should go in specification, design and test planning (saves a lot of time during test later on)