325 Midterm Prep

The important parts… I think…

MTE 325

MTE 325 is a weird class in which there aren’t obvious systematic ways to do things and you really need to understand the content to do well on assessments

Therefore, this is the only class where I compile course notes to reach the full breadth of what we’ve learned in case I need to know it

Diagrams

Note that I’m sometimes looking at diagrams within the lecture slides when I’m making this outline, if an explanation doesn’t sense, try to find the corresponding diagram that I’m describing from the lecture section

Section I: Introduction

System-Centric

• System is controlled using an open or closed loop control system Computer-Centric
• Computer implements instructions in software to control a system

Computer Interfacing

A computer system is made up of at minimum I/O, CPU and memory

Sensors and actuators provide data, and take action to and from a control system

Signals

• Signals can be analog or digital but contain noise, timing, and signal levels

Section II: Embedded Systems

Embedded Systems

An embedded system is a computer designed to do a task without the user being aware of its existance

The user can provide input but doesn’t have to

Hardware Software Co-design

• Simultaneously designing hardware and software components at the same time (switching between each other)

Microprocessors and Microcontrollers (CPU)

By Definition a microprocessor only contains a processor (JUST A CPU) and this term usually refers to a CPU.

Microcontroller

• A microcontroller is a bare minimum computer containing:
  • Processor
  • Memory
  • I/O System on a Chip
• A microcontroller that is also a fully functional system implemented on one single chip (can run an operating system) (has all the things a microcontroller has) System on a programmable Chip
• This is an SoC that is reconfigurable in terms of its peripherals (reprogrammable using PLDs and has custom hardware)

Section III: Embedded Programming

We use C

Voltatile

We use the volatile keyword to tell the compiler not to make optimizations and that this keyword needs to be read from memory every time it is used because it could unexpectedly change (is volatile)

Section IV: Software and Synchronization

Latency

• The formal definition for CPU and device latency is the time between the receipt of a service request and the service actually being initiated
• Request latency can be defined as the time between the request and completion of a service Throughput
• A measure of how many items can be processed per unit of time

Drivers

Device drivers are the software associated with a particular device and includes:

• Data structures
• Initialization functions
• I/O functions
• ISRs

Synchronization

Mechanisms Include

• Blind Synchronization is when the software waits some arbitrary delay and then forces a sample
• Occasional Polling is when the device status is checked based on the convenience of the designer
• Periodic Polling is when the device status is checked after a predetermined amount of time and this cycle repeats until a device is ready
• Tight polling is when a device status is continuously checked without a break until the device is ready
• Interrupt handling is when the device generates a hardware interrupt when its ready to do something

There are two types of synchronization mechanisms:

• CPU oriented (where the device waits for the CPU to initialization synchronization)
  • Blind cycling
  • Occasional polling
  • Periodic polling
• Device oriented (where the device initializes synchronization)
  • Tight polling
  • Interrupt handling

Polling Loops

There are two ways you can construct a polling loop

you can assume your device is ready and output your data first and then poll or poll first and then output your data when your device is ready

Interrupt Service Routines

You can have one IRQ line for all device, or multiple running in parallel for each device

These should:

• execute as fast as possible
• avoid blocking I/O functions The ISR:
• Saves any registers modified by the ISR
• Ack the device
• Re-enable interrupts so that higher priority interrupts can take over
• Test for a valid interrupt / determine the source of the interrupt
• Do its action
• Disable interrupts and restore registers
• Return

Section V: Synchronization, Data Generation, and Data Transfer

*The two sides of an interface (the device, and the CPU use different views of time

The producer consumer data model

• The producer produces data or events for the consumer

Synchronization

• Refers to the interaction required to make two devices with different views of time interact
• Can be active or passive
  • Where active synchronization forces a change in the operation of the other device
  • Where passive synchronization asks for a change in the operation of the other device but this request does not need to be responded to
  • Interrupts are usually active whereas polling is passive Synchronization needs to be considered at multiple levels:
• When data is generated (Data Generation)
  • Data can be generated with the following mechanisms
    • Spontaneous: Data is generated and provided whenever
    • Consumer Sensitive: Data is produced after previous data has been consumed
    • Consumer Responsive: Consumer asks for data
• When data is ready (Data Notification)
  • Data is notified in the following ways
    • Consumer initiated scenarios where the consumer lets the producer know its ready for more data
    • Produced initiated scenarios where the producer tells the consumer it has data ready which the consumer needs to accept
• When data is being transferred (Data Transfer)
  • Data Persistence
    • Data can be persistent or transient where transient data is only valid for a specific amount of time

Synchronous vs Asynchronous Systems

Blind Synchronization

• The consumer just reads data without considering anything else
• Errors could occur if data is changed too close to a sample time
• Data can be missed, or read twice since we don’t know when we are reading
• Ex. sampling on the falling edge of a consumer clock (we don’t know whats happening with the producer)

Synchronous Systems

• These systems share a common clock or view of time where the producer and consumer use different edges to make sure data is good

Asynchronous Systems

• The CPU and device still have different clocks but the device or CPU will send a data ready event when its good for a transaction which the other will act upon

Generalized IO

These are the steps required to have an I/O transfer happen:

• Global Initialization: Enable your I/O (GPIO etc)
• Transfer Initialization: Do everything you need to do to start your transfer
• Data Transfer: Actually do the transfer

Terminology

• Transfer time = max(t_transfer_prod, t_transfer_con)
• t_wait = The time required by the initiator to sync with the device it should sync with
• t_sync = The time spent by the initiator to detect new data or respond to new data depending on whether polling or interrupt handling is done
• t_interdata = Time in between the generation of data blocks \begin{split}t_{wait}=t_{sync-poll}\vert\vert t_{sync-inter}+t_{interdata} & \end{split}
  t_sync is fixed per transfer cycle but t_transfer is multiplied by n where n is the amount of data units in one block of data being sent in a transfer

Example

If we want to transfer 256 units of data, we can send n units per block where if n is 256 we only sync once, or if n = 1 we need to sync 256 times

Section VI: Computer Architecture & Drivers

A little weak here so study up

Busses (Intro)

Just a set of wires that transmit data where one wire can send one bit of data so your bus width is the number of bits you can send at once

Memory

MMIO is the idea where the CPU can’t tell the difference between memory and an interface since we interact with an interface using memory

Clocks

• Clock signals have a fixed duty cycle (same high and low time) and are edge-triggered
• Things here are predictable

The CPU Interface

Contains

• Clock enable signals (MDR and MAR in)
• Tri-state enable signals (MDR out)
• Direction control signals (R/W)
• Ack signal (MFC)
  • It sounds like the MFC is just a signal to tell you when a memory function is done doing its thing

The MDR BUS

The MUX decides if data from the internal or external system bus is being stored in the MDR where the MDRin + MFC signals decide if it gets clocked in Then tri-states in each direction dictate MDR output to the internal or external busses.

The MDR is bi-directional as you can see :)

THE MAR BUS

See Microprocessors and Microcontrollers (CPU) and go to the MAR section

CPU and Memory Timing

During a read, the CPU asserts and address causing the memory to eventually respond

Synchronous Interactions

• The CPU and memory share a common clock here, for example, if memory takes 6 cycles to respond to the CPU, then the CPU will know data is valid after 6 cycles
• The CPU needs to start each transaction with a synchronization pulse

Asynchronous Interactions

• In the same situation (memory required 6 clock periods to respond)
• The CPU once again sends a sync pulse
• Memory tells the CPU when an address is valid and for how long
• The CPU reads the address and tells memory when its done reading

Multiple Drivers

Bus Conflicts

Sharing a bus line is dangerous cause you can get bus conflicts if two drivers try to write different values to the same line

!!! We use transistors, and pull resistors to drive voltages !!! There is a hierarchy here (top to bottom takes priority)

• Active (Transisitors)
• Passive (Resisitors)
• High Impedance (Hanging Line)

Derivations

Make sure you can derive anything using NMOS PMOS CMOS and PU PD Resistors

Btw CMOS’s prevent hanging lines by either actively driving up or down to a source or drain

Tri-States

Tri-states prevent bus conflicts so are used often, basically when the enable bit (e) is off, it drives high impedance (Z), otherwise it drives the value of i

Parasitic Capacitances

• An ideal signal is a square but becomes like a wave with round edges which is bad
• When R is small we need a large slow transistor to handle the current
• When R is large, the bus discharges slowly

Types of Output Drivers

• Push-pull output drivers are used by all gates
  • These are not capable of a high impedance state so they are not suitable for bus sharing since that is a pre-requisite
• Open-drain output drivers are denoted by o/d on the logic gate
  • These drivers can actively drive a 0, passively drive a 1 through a pull-up resistor, and when not driving 0, can drive high impedance
• Tri-states are ideal for bus sharing and can actively drive a 1, 0 and have a high impedance state

Device Selection

If a bus line has multiple drivers, we need a technique to intentionally choose which driver we want to drive the bus line

Explicit Selection

• Selects a device using bus signals
  • Address values
  • Arbitration
  • Timing
  • Event Implicit Selection
• Resolves bus conflicts using wired logic in a predictable manner
• Using tri-states etc

We can use tri-states with active selection if we intentionally send an address through an address decoder from the CPU and send the resulting data as enable bits to tri-states

Address Decode Circuitry

The system could have a centralized address decoder for all devices, or one per device

We could also Alias the address where we only consider some bits in the address vs all of them

The CPU drives an address via the address line to an address and timing decoder (black box) that decodes the address and uses it to select a register on the device interface

Metastability

Happens when setup or hold times are violated (we’ll talk about this later)

This is when we don’t know what the value is with certainty anymore

Synchronization chains can mitigate metastability (Chain together D registers with a clock clocking the data into the registers)

Section VII: Buses + Data Transfer

Synchronous Bus Transfers

A common view of time is available to all devices

Data being valid

For a common view of time, we assume data is valid on the falling edge of a clock cycle

Terminology

• t_pa = The time for the address to propagate from controller to peripherals
• t_pd = The time for data to propogate from the data source to receivers
• t_p = The maximum of the propagation delay signals
• t_setup = The minimum time that a signal has to be available before the next rising clock edge
• t_hold = The minimum time that data is held stable after a clock edge which marks the data as valid
• t_select = The time it takes for a device to notice that its being selected
• t_access = The time required for the device interface to access requested informatiojn
• t_store = The time required for the device interface to capture and store data
• t_skew = The maximum different in propagation times
• t_margin = Time reserved for unexpected occurances

More on Skew

• Caused by wire lengths, logic gate delays, difference in rise and fall times

Data Synchronization Techniques

• Synchronous: Entities communicate with a common clock
• Asynchronous: Entities communicate directly to set variable transfer times
• Semi-Synchronous: Entities use a common clock but the number of cycle they wait for before initializing a transfer is variable and in control of the peripheral

Synchronous Bus Read EXAMPLE

1. The controller provides an address to the peripheral (t_pa, t_skew)
2. Wait t_margin
3. Peripheral realizes its selected and accesses information at address (t_select, t_access)
4. Sends data back (t_pd, t_skew)
5. Wait t_margin
6. Data is available and then held for use (t_setup, t_hold)

In general, for a synchronous bus READING After rising edge of clock:

• propagation delay for giving an address
• skew time After the falling edge of the clock
• Address decode time (t_select)
• Read time from peripheral
• propagation delay for data
• skew time
• setup time
• hold time is here but to allow for consecutive synchronous cycles we say that t_hold = 0 so that we don’t miss a rising edge

Optimized timing:
$t_{optimized,read}=t_{PA}+t_{skew}+t_{hold}+t_{select}+t_{Access}+t_{PD}+t_{skew}+t_{setup}$

Synchronous Bus Write EXAMPLE

1. Controller provides an address and data (t_pa, t_pd, t_skew)
2. Wait t_margin
3. The peripheral realizes its being selected, decodes the address and stores it (t_select, t_store)
4. Wait t_margin
5. Data is available and held (t_setup, t_hold)
6. Controller removes data from peripheral The clock signals for a write are as follows:
   Normal Clock:
   $!Clock\cdot Addres{s}_{Decoded}\cdot !R/W$
   Register Clock:
   $!\left(!Clock\cdot Addres{s}_{Decoded}\cdot !R/W\right)$
   Where the normal clock is the CPU clock and the register clock is the clock for the D register and tells it when to clock in data

By inverting the register clock, the register clock goes high as R/W goes high

In general, for a synchronous bus WRITING After the rising edge

• propagation delay for sending the address and data (the max of the two)
• Skew time After the falling edge
• Decode the address
• Initiate data storage
• Setup time
• Hold time but here to allow for consecutive cycles we say that t_hold = 0

Since a synchronous bus system using one single clock period, the slower of the two clock rates between the CPU and the device must be used to determine the optimized time for a bus cycle

Optimized timing:
$t_{optimized,write}=t_p+t_{skew}+t_{hold}+t_{select}+t_{store}+t_{setup}$

Asynchronous Bus Transfers

Asynchronous systems allow the speed of the bus to be compatible with a variety of different speed

Asynchronous Bus Read EXAMPLE

1. Controller provides address (t_pa, t_skew)
2. Wait for skew on controller side, then margin time (t_skew, t_margin)
3. Controller asserts controller
4. Peripheral realizes its selected and accesses data (t_select, t_access)
5. Sends data back and asserts peripheral (t_pd, t_skew)
6. Controller sees skew on the controller side and waits for the margin time (t_skew, t_margin)
7. Controller sets up data in latch and holds (t_setup, t_latch)
8. Controller de-asserts controller
9. Peripheral de-asserts peripheral and removes data from controller

Limiting factors for bus speed include:

• Skew time
• Propagation time
• Setup time
• Hold time
• Access / store times?

A fully interlocked asynchronous busses time is:
$T=4\cdot t_p+2\cdot t_{skew}+t_{access}+t_{setup}$
Therefore, this is slower than an optimized synchronous bus transfer since it requires double the propagation time but verifies that real values are being read and allows for a variety of response times

Async transfer treat data as persistent whereas Sync transfers treat data as transient

When is Async better

As average access time increases, the asynchronous option gets better and better and actually becomes better than a synchronous bus when the average access time is around 81% of the maximum access time

Section VIII: Parallel Interfacing

Parallel Interfacing

The point of PI is to provide a method to the processor (CPU) to R/W data to the bus in the time scale of the bus (the timing at which the bus operates) and synchronizes the device with the system

Parallel interfacing also connects the device and system busses

Looking at the design

• There are a bunch of different registers for…
  • Reading status from device
  • Data in, data out
  • Control
• These registers are in between the system bus data lines and the device

Therefore, data must pass through a register before getting to the device

System Bus Side

• Data is bi-directional between a device and the CPU
• Device selection is via a memory location
• Controls must be synchronized

Device Bus Side

• Uni directional lines can be implemented for simplicity / low cost
• Bi-directional lines are more versatile
• You can control direction during initialization or during operation
• Ways to implement a bus driver:
  • Tri-states
  • Passive PU PD

Data Characteristics

Two general techniques to pass data to and from entities

• In-band:
  • control information is send the same way data is
• Out-of-band
  • Control information is sent in a distinct way vs how data is transmitted

Persistant Data

When data lives on a line and doesn’t go away until it is either told to go away, or it lives for a really long time in comparison to other actions happening to the line

For persistent data, the producer should be notified to remove data, this isn’t the case with transient data

Debouncing

Mechanical switches are noisy due to bouncing signals, you can buy more expensive ones that don’t bounce

BUUUUT
You can take software and hardware approaches to solving this problem:
Software

• Wait a fixed amount of time using a delay loop
• Wait until the signal is stable before reading Hardware
• Wait a fixed amount of time using a counter or shift register
• Slow down the signal transitions using a capacitor
• Use that more expensive switch