This Presentation describes the ARM CORTEX M3 core processor with the details of the core peripherals. Soon a CORTEX base controller(STM32F100RBT6) ppt will be uploaded. For more information mail me at:gaurav.iitkg@gmail.com.
It is a presentation for the Embedded System Basics. It will be very useful for the engineering students who need to know the basics of Embedded System.
This Presentation describes the ARM CORTEX M3 core processor with the details of the core peripherals. Soon a CORTEX base controller(STM32F100RBT6) ppt will be uploaded. For more information mail me at:gaurav.iitkg@gmail.com.
It is a presentation for the Embedded System Basics. It will be very useful for the engineering students who need to know the basics of Embedded System.
Presents features of ARM Processors, ARM architecture variants and Processor families. Further presents, ARM v4T architecture, ARM7-TDMI processor: Register organization, pipelining, modes, exception handling, bus architecture, debug architecture and interface signals.
EC8791-Embedded and Real Time Systems #7th Sem ECE #Embedded System Introduction # Embedded System Real Time Examples #Career opportunity in Embedded System Filed #Growth of Embedded System
Describes ARM7-TDMI Processor Instruction Set. Explains classes of ARM7 instructions, syntax of data processing instructions, branch instructions, load-store instructions, coprocessor instructions, thumb state instructions.
Embedded Systems (18EC62) - ARM Cortex-M3 Instruction Set and Programming (Mo...Shrishail Bhat
Lecture Slides for Embedded Systems (18EC62) - ARM Cortex-M3 Instruction set and Programming (Module 2) for VTU Students
Contents
Assembly basics, Instruction list and description, Thumb and ARM instructions, Special instructions, Useful instructions, CMSIS, Assembly and C language Programming
Challenges faced during embedded system design:
The challenges in design of embedded systems have always been in the same limiting requirements for decades: Small form factor; Low energy; Long-term stable performance without maintenance.
Presents features of ARM Processors, ARM architecture variants and Processor families. Further presents, ARM v4T architecture, ARM7-TDMI processor: Register organization, pipelining, modes, exception handling, bus architecture, debug architecture and interface signals.
EC8791-Embedded and Real Time Systems #7th Sem ECE #Embedded System Introduction # Embedded System Real Time Examples #Career opportunity in Embedded System Filed #Growth of Embedded System
Describes ARM7-TDMI Processor Instruction Set. Explains classes of ARM7 instructions, syntax of data processing instructions, branch instructions, load-store instructions, coprocessor instructions, thumb state instructions.
Embedded Systems (18EC62) - ARM Cortex-M3 Instruction Set and Programming (Mo...Shrishail Bhat
Lecture Slides for Embedded Systems (18EC62) - ARM Cortex-M3 Instruction set and Programming (Module 2) for VTU Students
Contents
Assembly basics, Instruction list and description, Thumb and ARM instructions, Special instructions, Useful instructions, CMSIS, Assembly and C language Programming
Challenges faced during embedded system design:
The challenges in design of embedded systems have always been in the same limiting requirements for decades: Small form factor; Low energy; Long-term stable performance without maintenance.
introduction to Embedded System & Design.
Embedded systems overview
What are they?
Design challenge – optimizing design metrics
Technologies
Processor technologies
IC technologies
Design technologies
Introduction to Systems with Examples and Introduction to Embedded Systems, History, Advantages, Applications, Classifications,What is inside Embedded System, Architecture, Features and Languages used in Embedded Systems advantages and disadvantages
Embeddedsystem basic for Engineering StudentsElectro 8
Electro8 Is a Leading Embedded System Development Company in Chennai,We Offering Final Year Embedded and Matlab projects,We are the Vendor of Godraj and Spoorthi,Global ad ,Micron solution
like our page for more updates:
https://www.facebook.com/Technogroovyindia
With Best Regard's
Technogroovy Systems India Pvt. Ltd.
www.technogroovy.com
Call- +91-9582888121
Whatsapp- +91-8800718323
embedded systems & robotics Projects Based training @TechnogroovyTechnogroovy India
like our page for more updates:
https://www.facebook.com/Technogroovyindia
With Best Regard's
Technogroovy Systems India Pvt. Ltd.
www.technogroovy.com
Call- +91-9582888121
Whatsapp- +91-8800718323
Designs and develops robotic prototypes. Constructs, configures, tests, and debugs robots and robotic systems. Installs, operates, calibrates, and maintains robots. Ensures that robotic machines operate safely, dependably, and with precision; identifies and implements modifications.
Embedded systems open gates to a new world where standard of living is sophisticated using technology. This is a brief look at the term Embedded Systems.
Similar to Introduction to embedded system design (20)
SAP Sapphire 2024 - ASUG301 building better apps with SAP Fiori.pdfPeter Spielvogel
Building better applications for business users with SAP Fiori.
• What is SAP Fiori and why it matters to you
• How a better user experience drives measurable business benefits
• How to get started with SAP Fiori today
• How SAP Fiori elements accelerates application development
• How SAP Build Code includes SAP Fiori tools and other generative artificial intelligence capabilities
• How SAP Fiori paves the way for using AI in SAP apps
PHP Frameworks: I want to break free (IPC Berlin 2024)Ralf Eggert
In this presentation, we examine the challenges and limitations of relying too heavily on PHP frameworks in web development. We discuss the history of PHP and its frameworks to understand how this dependence has evolved. The focus will be on providing concrete tips and strategies to reduce reliance on these frameworks, based on real-world examples and practical considerations. The goal is to equip developers with the skills and knowledge to create more flexible and future-proof web applications. We'll explore the importance of maintaining autonomy in a rapidly changing tech landscape and how to make informed decisions in PHP development.
This talk is aimed at encouraging a more independent approach to using PHP frameworks, moving towards a more flexible and future-proof approach to PHP development.
DevOps and Testing slides at DASA ConnectKari Kakkonen
My and Rik Marselis slides at 30.5.2024 DASA Connect conference. We discuss about what is testing, then what is agile testing and finally what is Testing in DevOps. Finally we had lovely workshop with the participants trying to find out different ways to think about quality and testing in different parts of the DevOps infinity loop.
Elevating Tactical DDD Patterns Through Object CalisthenicsDorra BARTAGUIZ
After immersing yourself in the blue book and its red counterpart, attending DDD-focused conferences, and applying tactical patterns, you're left with a crucial question: How do I ensure my design is effective? Tactical patterns within Domain-Driven Design (DDD) serve as guiding principles for creating clear and manageable domain models. However, achieving success with these patterns requires additional guidance. Interestingly, we've observed that a set of constraints initially designed for training purposes remarkably aligns with effective pattern implementation, offering a more ‘mechanical’ approach. Let's explore together how Object Calisthenics can elevate the design of your tactical DDD patterns, offering concrete help for those venturing into DDD for the first time!
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Albert Hoitingh
In this session I delve into the encryption technology used in Microsoft 365 and Microsoft Purview. Including the concepts of Customer Key and Double Key Encryption.
Observability Concepts EVERY Developer Should Know -- DeveloperWeek Europe.pdfPaige Cruz
Monitoring and observability aren’t traditionally found in software curriculums and many of us cobble this knowledge together from whatever vendor or ecosystem we were first introduced to and whatever is a part of your current company’s observability stack.
While the dev and ops silo continues to crumble….many organizations still relegate monitoring & observability as the purview of ops, infra and SRE teams. This is a mistake - achieving a highly observable system requires collaboration up and down the stack.
I, a former op, would like to extend an invitation to all application developers to join the observability party will share these foundational concepts to build on:
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...DanBrown980551
Do you want to learn how to model and simulate an electrical network from scratch in under an hour?
Then welcome to this PowSyBl workshop, hosted by Rte, the French Transmission System Operator (TSO)!
During the webinar, you will discover the PowSyBl ecosystem as well as handle and study an electrical network through an interactive Python notebook.
PowSyBl is an open source project hosted by LF Energy, which offers a comprehensive set of features for electrical grid modelling and simulation. Among other advanced features, PowSyBl provides:
- A fully editable and extendable library for grid component modelling;
- Visualization tools to display your network;
- Grid simulation tools, such as power flows, security analyses (with or without remedial actions) and sensitivity analyses;
The framework is mostly written in Java, with a Python binding so that Python developers can access PowSyBl functionalities as well.
What you will learn during the webinar:
- For beginners: discover PowSyBl's functionalities through a quick general presentation and the notebook, without needing any expert coding skills;
- For advanced developers: master the skills to efficiently apply PowSyBl functionalities to your real-world scenarios.
The Art of the Pitch: WordPress Relationships and SalesLaura Byrne
Clients don’t know what they don’t know. What web solutions are right for them? How does WordPress come into the picture? How do you make sure you understand scope and timeline? What do you do if sometime changes?
All these questions and more will be explored as we talk about matching clients’ needs with what your agency offers without pulling teeth or pulling your hair out. Practical tips, and strategies for successful relationship building that leads to closing the deal.
Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...UiPathCommunity
💥 Speed, accuracy, and scaling – discover the superpowers of GenAI in action with UiPath Document Understanding and Communications Mining™:
See how to accelerate model training and optimize model performance with active learning
Learn about the latest enhancements to out-of-the-box document processing – with little to no training required
Get an exclusive demo of the new family of UiPath LLMs – GenAI models specialized for processing different types of documents and messages
This is a hands-on session specifically designed for automation developers and AI enthusiasts seeking to enhance their knowledge in leveraging the latest intelligent document processing capabilities offered by UiPath.
Speakers:
👨🏫 Andras Palfi, Senior Product Manager, UiPath
👩🏫 Lenka Dulovicova, Product Program Manager, UiPath
Accelerate your Kubernetes clusters with Varnish CachingThijs Feryn
A presentation about the usage and availability of Varnish on Kubernetes. This talk explores the capabilities of Varnish caching and shows how to use the Varnish Helm chart to deploy it to Kubernetes.
This presentation was delivered at K8SUG Singapore. See https://feryn.eu/presentations/accelerate-your-kubernetes-clusters-with-varnish-caching-k8sug-singapore-28-2024 for more details.
UiPath Test Automation using UiPath Test Suite series, part 3DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 3. In this session, we will cover desktop automation along with UI automation.
Topics covered:
UI automation Introduction,
UI automation Sample
Desktop automation flow
Pradeep Chinnala, Senior Consultant Automation Developer @WonderBotz and UiPath MVP
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
By Design, not by Accident - Agile Venture Bolzano 2024
Introduction to embedded system design
1. INTRODUCTION TO EMBEDDED
SYSTEM DESIGN
Mukesh Kumar
mkb@genericembedded.com
www.genericembedded.com
www genericembedded com
2. Agenda (1)
• Introduction to Embedded System Design
– General Introduction to Embedded Systems
General Introduction to Embedded Systems
– Hardware Platforms and Components
• System Specialization
y p
• Application Specific Instruction Sets
– Micro Controller
– Di i l Si l P
Digital Signal Processors and VLIW
d VLIW
– Programmable Hardware
– ASICs
3. Agenda (2)
Agenda (2)
• Challenges in embedded system design
Challenges in embedded system design
• Dependability, efficiency, …
– Design flows
Design flows
– Requirements for specification techniques
– Models of computation
Models of computation
• Local model
• Communication
4. What is Embedded System?..
y
Embedded systems (ES) information
Embedded systems (ES) = information
processing systems embedded into a larger
product
An embedded system is a computer system
designed to do one or a few dedicated and/or
specific functions often with real‐time
computing constraints. It is embedded as part
of a complete device often including hardware
f l d i f i l di h d
and mechanical parts.
15. Characteristics of Embedded Systems (1)
• Must be dependable:
– Reliability: R(t) = probability of system working correctly
provided that is was working at t=0
– Maintainability: M(d) = probability of system working
correctly d time units after error occurred.
correctly d time units after error occurred
– Availability: probability of system working at time t
– Safety: no harm to be caused
Safety: no harm to be caused
– Security: confidential and authentic communication
Even perfectly designed systems can fail if the assumptions about the
workload and possible errors turn out to be wrong. Making the system
dependable must not be an after‐thought, it must be considered from
the very beginning
beginning.
16. Characteristics of Embedded Systems (2)
• Must be efficient:
– Energy efficient
– Code‐size efficient (especially for systems on a chip)
– Run‐time efficient
– Weight efficient
Weight efficient
– Cost efficient
• D di
Dedicated towards a certain application: Knowledge
d d i li i K l d
about behavior at design time can be used to
minimize resources and to maximize robustness.
• Dedicated user interface (no mouse, keyboard and
screen).
17. Characteristics of Embedded Systems (3)
• Many ES must meet real‐time constraints:
– A real-time system must react to stimuli from
the controlled object (or the operator) within the
time interval dictated by the environment.
– For real‐time systems, right answers arriving too late
(or even too early) are wrong.
(or even too early) are wrong
• “A real‐time constraint is called hard, if not
meeting thatconstraint could result in a
g
catastrophe”[Kopetz, 1997].
• All other time‐constraints are called soft.
• A guaranteed system response has to be
explained without statistical arguments.
18. Characteristics of Embedded Systems (4)
• Frequently connected to physical environment
through sensors and actuators,
• Hybrid systems (analog + digital parts).
• Typically, ES are reactive systems:
• “A reactive system is one which is in continual
interaction with is environment and executes at
a pace determined by that environment“
d i db h i “
[Bergé, 1995]
• B h i d
Behavior depends on input and current state.
d i t d t t t
– automata model often appropriate,
19. Comparison
Embedded Systems General Purpose Computing
• Few applications that are known
F li i h k • Broad class of applications.
B d l f li i
at design‐time.
• Not programmable by end user. • Programmable by end user.
• Fixed run‐time equirements • Faster is better.
(additional computing power not
useful).
• Criteria:
• Criteria:
– cost
– cost
– average speed
– power consumption
– predictability
– …
20. Agenda
• General Introduction to Embedded Systems
General Introduction to Embedded Systems
• Hardware Platforms and Components
–S t
System Specialization
S i li ti
– Application Specific Instruction Sets
• Mi
Micro Controller
C ll
• Digital Signal Processors and VLIW
– Programmable Hardware
Programmable Hardware
– ASICs
23. Agenda
• General Introduction to Embedded Systems
General Introduction to Embedded Systems
• Hardware Platforms and Components
– System Specialization
System Specialization
– Application Specific Instruction Sets
• Mi
Micro Controller
C ll
• Digital Signal Processors and VLIW
– Programmable Hardware
Programmable Hardware
– ASICs
25. General‐purpose Processors
• High performance
– Highly optimized circuits and technology
– Use of parallelism
• superscalar: dynamic scheduling of instructions
• super‐pipelining: instruction pipelining, branch prediction,
speculation
– complex memory hierarchy
• Not suited for real‐time applications
f pp
– Execution times are highly unpredictable because of
intensive resource sharing and dynamic decisions
• Properties
– Good average performance for large application mix
– High power consumption
27. System Specialization
• The main difference between general purpose highest
volume microprocessors and embedded systems is
p y
specialization.
• Specialization should respect flexibility
– application domain specific systems shall cover a class of
application domain specific systems shall cover a class of
applications
– some flexibility is required to account for late changes,
debugging
• System analysis required
– identification of application properties which can be
used for specialization
df i li ti
– quantification of individual specialization effects
31. Agenda
• General Introduction to Embedded Systems
General Introduction to Embedded Systems
• Hardware Platforms and Components
– System Specialization
System Specialization
– Application Specific Instruction Sets
• Mi
Micro Controller
C t ll
• Digital Signal Processors and VLIW
–PProgrammable Hardware
bl H d
– ASICs
32. Microcontroller
• control‐dominant applications
– supports process scheduling and
synchronization
– preemption (interrupt),context
switch
it h
– short latency times
• low power consumption
• peripheral units often
integrated
• suited for real‐time
applications
34. Agenda
• General Introduction to Embedded Systems
General Introduction to Embedded Systems
• Hardware Platforms and Components
– System Specialization
System Specialization
– Application Specific Instruction Sets
• Micro Controller
Micro Controller
• Digital Signal Processors and VLIW
– Programmable Hardware
– ASICs
40. Agenda
• General Introduction to Embedded Systems
General Introduction to Embedded Systems
• Hardware Platforms and Components
– System Specialization
System Specialization
– Application Specific Instruction Sets
• Micro Controller
Micro Controller
• Digital Signal Processors and VLIW
– Programmable Hardware
bl d
– ASICs
42. FPGA ‐ Classification
• Granularity of logic units:
– Gate, tables, memory, functional blocks (ALU,
control, data path, processor)
• Communication network:
– Crossbar, hierarchical mesh, tree
• Reconfiguration:
– fixed at production time, once at design time,
p , g ,
dynamic during run‐time
44. Agenda
• General Introduction to Embedded Systems
General Introduction to Embedded Systems
• Hardware Platforms and Components
– System Specialization
System Specialization
– Application Specific Instruction Sets
• Micro Controller
Micro Controller
• Digital Signal Processors and VLIW
–PProgrammable Hardware
bl H d
– ASICs
45. Application Specific Circuits (ASICS)
• Custom‐designed circuits
necessary
– if ultimate speed or
– energy efficiency is the goal and
energy efficiency is the goal and
– large numbers can be sold.
• Approach suffers from
–llong design times,
d i i
– lack of flexibility
(
(changing standards) and
g g )
– high costs
(e.g. Mill. $ mask costs).
46. Agenda (2)
Agenda (2)
• Challenges in embedded system design
Challenges in embedded system design
• Dependability, efficiency, …
– Design flows
Design flows
– Structure of this course
– Requirements for specification techniques
Requirements for specification techniques
– Models of computation
• L l
Local model
d l
• Communication
47. Quite a number of challenges, e.g.
dependability
• Dependability?
– Non‐real time protocols used for real‐time applications
(e.g. Berlin fire department)
– Over‐simplification of models
(e.g. aircraft anti‐collision system)
– Using unsafe systems for safety‐critical missions
(e.g. voice control system in Los Angeles; ~ 800
planes without voice connection to tower for > 3 hrs
l h f h
48. It is not sufficient to consider ES
just as a special case of software engineering
just as a special case of software engineering
EE knowledge must be available,
Walls between EE and CS must be torn down
CS EE
The same for walls to other disciplines and more challenges ….
49. Agenda (2)
Agenda (2)
• Challenges in embedded system design
Challenges in embedded system design
• Dependability, efficiency, …
– Design flows
Design flows
– Requirements for specification techniques
– Models of computation
Models of computation
• Local model
• Communication
50. Hypothetical design flow
Specification Design repository Design
nowledge
plication Kn
ES‐hardware Test *
Application mapping
System software
System software * Could be
Could be
App
Optimization
O ti i ti
(RTOS, middleware, integrated
Evaluation & Validation into loop
…) (energy, cost, performance,
…)
)
Generic loop: tool chains differ in the number and type of iterations
e e c oop oo c a s d e e u be a d ype o e a o s
52. Iterative design (2)
‐ After unrolling loop ‐
• Example: V‐model
Requirement
analysis System
architecture System
System
design Software
architecture
Software
design
Unit
Integration tests
System testing
integration
Acceptance
& use
Skipping some explicit
repository updates ..
53. Hypothetical design flow
2: Specification Design repository Design
owledge
Application Kno
3: ES‐hardware 8. Test *
6: Application
mapping
4: System software
4: System software 7: Optimization
7 O ti i ti * Could be
Could be
(RTOS, middleware, integrated
5: Evaluation & Validation into loop
…) (energy, cost, performance,
…)
)
Numbers denote sequence of chapters
54. Motivation for considering specs
Motivation for considering specs
– Why considering specs?
– If something is wrong with the specs then it
If something is wrong with the specs, then it
will be difficult to get the design right,
potentially wasting a lot of time.
– Typically, we work with models of the
system under design (SUD)
What is a model anyway?
55. Models
• Definition: A model is a simplification of another entity,
which can be a physical thing or another model. The model
which can be a physical thing or another model. The model
contains exactly those characteristics and properties of the
modeled entity that are relevant for a given task. A model
• is minimal with respect to a task if it does not contain any
is minimal with respect to a task if it does not contain any
other characteristics than those relevant for the task.
[Jantsch, 2004]:
Which requirements do we have for our models?
56. Requirements for specification techniques:
Hierarchy
• Hierarchy
Humans not capable to understand systems
containing more than ~5 objects.
Most actual systems require more objects
Hierarchy
proc
– Behavioral hierarchy proc
Examples: states, processes, procedures. proc
– Structural hierarchy
Examples: processors, racks,
p
printed circuit boards
58. Requirements for specification techniques (3):
Timing
Ti i
– Timing behavior
Essential for embedded and cy‐phy systems!
• Additional information (periods, dependences,
scenarios, use cases) welcome
• Also the speed of the underlying platform must be
Also, the speed of the underlying platform must be
known
• Far‐reaching consequences for design processes!
“The lack of timing in the core abstraction (of computer science) is a flaw, from the
perspective of embedded software” [Lee, 2005]
59. Requirements for specification techniques (3):
Timing (2)
Ti i (2)
• 4 types of timing specs required, according to Burns, 1990:
1. Measure elapsed time
Check, how much time has elapsed since last call
? execute
t
2. Means for delaying processes
t
61. Specification of embedded systems (4):
Support for designing reactive systems
Support for designing reactive systems
– State‐oriented behavior
Required for reactive systems;
classical automata insufficient.
– Event‐handling
(external or internal events)
– Exception‐oriented behavior We will see, how all the
Not acceptable to describe arrows labeled k can be
replaced by a single one.
p y g
exceptions for every state
exceptions for every state
62. Requirements for specification
techniques (5)
techniques (5)
– Presence of programming elements
– Executability (no algebraic specification)
y( g p )
– Support for the design of large systems ( OO)
– Domain‐specific support
– Readability
R d bilit
– Portability and flexibility
– Termination
– Support for non‐standard I/O devices
– Non‐functional properties
– Support for the design of dependable systems
S t f th d i fd d bl t
– No obstacles for efficient implementation
– Adequate model of computation
q p
What does it mean “to compute”?
63. Models of computation
Models of computation
• What does it mean, “to compute”?
• Models of computation define:
C‐1
– Components and an execution model for
computations for each component
– Communication model for exchange of
Communication model for exchange of C‐2
information between components.
64. Communication
Shared memory
y
Comp‐1 memory Comp‐2
Variables accessible to several components/tasks.
Model mostly restricted to local systems.
65. Shared memory
Shared memory
• Potential race conditions ( inconsistent results possible)
Critical sections = sections at which exclusive access to
Critical sections = sections at which exclusive access to
resource r (e.g. shared memory) must be guaranteed.
task a { task b { Race‐free access to shared
.. .. memory protected by S
P(S) //obtain lock P(S) //obtain lock possible
.. // critical section .. // critical section
V(S) //release lock V(S) //release lock
} }
P(S) and V(S) are semaphore operations,
allowing at most n accesses, n =1 in this case (mutex, lock)
68. Agenda (2)
Agenda (2)
• Challenges in embedded system design
Challenges in embedded system design
• Dependability, efficiency, …
– Design flows
Design flows
– Requirements for specification techniques
– Models of computation
Models of computation
• Local model
• Communication
• Testing
69. Test: Goals
Test: Goals
1. Production test
2. Is there any way of using test patterns for production
2 I th f i t t tt f d ti
test already during the design?
3. Test for faults after delivery to customer
3 T t f f lt ft d li t t
70. Why is testing of embedded
systems difficult?
– Embedded/cyber physical systems integrated into a
Embedded/cyber‐physical systems integrated into a
physical environment may be safety‐critical. As a
result, expectations for the product quality are
higher than for non‐safety critical systems.
h h h f f l
– Testing of timing‐critical systems has to validate the
correct timing behavior. This means that just testing
the functional behavior is not sufficient.
– Testing embedded/cyber‐physical systems in their
real environment may be dangerous.
71. Scope
Testing includes
the application of test patterns to the inputs of the
device under test (DUT) and
the observation of the results.
the observation of the results
More precisely, testing requires the following steps:
p y, g q g p
1. test pattern generation,
2. test pattern application,
3. response observation, and
4. result comparison.
72. Fault models and test pattern
generation
• T
Test pattern generation typically
i i ll
considers certain fault models and
generates patterns that enable a distinction
between the faulty and the fault‐free case.
Examples:
• Boolean differences
• D‐Algorithm
• Self‐test programs
73. Stuck at fault model
Stuck‐at fault model
• Hardware fault model:
• Net permanently connected to ground or Vdd
– Simplification of the real situation
– Nevertheless useful in many cases
• Example: Stuck‐at‐1at port p
Stuck‐at‐1at port p
74. Other Hardware fault models
Other Hardware fault models
Fault models include:
stuck‐open faults:
stuck open faults:
for CMOS, open
transistors can
behave like
behave like
memories www.cedcc.psu.edu/ee497f
/rassp_43/sld022.htm
delay faults: circuit is
functionally correct,
but the delay is not.
but the delay is not.
75. Fault models and test pattern
generation
• T
Test pattern generation typically
i i ll
considers certain fault models and
generates patterns that enable a distinction
between the faulty and the fault‐free case.
Examples:
• Boolean differences
• D‐Algorithm
• Self‐test programs
76. The D‐algorithm: a simple example
no error error
0
p 0 /1
0 1/0
1/0
1
1
1
• Could we check for a stuck at one error at port p (s‐a‐1(p)) ?
• Solution (just guessing):
Solution (just guessing):
– Signal f='1' if there is an error
– a='0', b='0' in order to have f='0' if there is no error
– g= 1 in order to propagate error
g='1' in order to propagate error
– c='1' in order to have g='1' (or set d='1') Symbolic values D
– e='1' in order to propagate error and D are assigned to
signals f, h and i
– i= 1 if there is no error & i='0' if there is
i='1' if there is no error & i= 0 if there is
77. Generation of Self‐Test Program Generation
‐ Key concept ‐
y p
1. Store pattern of all ‘1’s in the register file
2. Perform xor between register and constant “00..0";
3. Test if result contains ‘0’ bit
4. If yes, report error;
5. Otherwise start test for next fault;
Otherwise start test for next fault;
Exmaple: checksum matching.
78. Software fault injection
Software fault injection
• Errors are injected into the memories.
j
• Advantages:
– Predictability: it is possible to reproduce every injected
it is possible to reproduce every injected
fault in time and space.
– Reachability: possible to reach storage locations within
y p g
chips instead of just pins.
– Less effort than physical fault injection: no modified
hardware.
hard are
Same quality of results?
80. References:
• “Embedded System Design” Book and
Embedded System Design Book and
Lecture of Peter Marwedel
• “Hard Real Time Computing Systems” Book
Hard Real‐Time Computing Systems Book
of Giorgio Buttazzo.
• “E b dd d S
“Embedded System Design : A unified
D i A ifi d
Hardware/software introduction”
Vahid/Givargis
V hid/Gi i