All Lectures Combined - Design Microprocessor Based Systems | EECS 373, Lab Reports of Electrical and Electronics Engineering

Material Type: Lab; Class: Des Microproc Syst; Subject: Electrical Engineering And Computer Science; University: University of Michigan - Ann Arbor; Term: Fall 2002;

Typology: Lab Reports

Pre 2010

Uploaded on 09/02/2009

koofers-user-jyd-1
koofers-user-jyd-1 🇺🇸

10 documents

1 / 24

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Course pack for
EECS 373: Design of Microprocessor Based Systems
Fall semester 2002
v0.2
EECS 373 course pack – mwb Page 1
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18

Partial preview of the text

Download All Lectures Combined - Design Microprocessor Based Systems | EECS 373 and more Lab Reports Electrical and Electronics Engineering in PDF only on Docsity!

Course pack for

EECS 373: Design of Microprocessor Based Systems

Fall semester 2002

v0.

Table of Contents

  • I.About this document..........................................................................................................
    • Disclaimer.......................................................................................................................
    • Purpose............................................................................................................................
    • Text.................................................................................................................................
  • II.Course Introduction..........................................................................................................
    • Embedded systems at the Univ. of Michigan..................................................................
    • Other Introductory issues................................................................................................
  • III.PowerPC Assembly and Architecture.............................................................................
    • Databook notation...........................................................................................................
    • PowerPC Assembly Example..........................................................................................
    • PowerPC instructions......................................................................................................
      • Loads and Stores.........................................................................................................
      • ALU instructions – not exactly orthogonal................................................................
      • Other instructions.....................................................................................................
    • PowerPC Architectural issues.......................................................................................
      • Special Purpose Registers.........................................................................................
    • Questions.......................................................................................................................
  • IV.Memory Mapped I/O – the basics.................................................................................
    • Simple memory-mapped I/O example..........................................................................
    • Questions.......................................................................................................................
  • V.Processor Bus Protocols
    • Memory mapped I/O – again.........................................................................................
  • VI.ABI and the Stack.........................................................................................................
  • VII.Interrupts......................................................................................................................
  • VIII.DMA – Direct Memory Access..................................................................................
  • IX.Counters and Timers.....................................................................................................
  • X.Analog and Digital Signal..............................................................................................
  • XI.Bonus Topics................................................................................................................
    • Memory types................................................................................................................
    • Error correction.............................................................................................................
      • Parity.........................................................................................................................
      • Error Correction Codes (ECC).................................................................................
      • Viterbi algorithm for error correction.......................................................................
    • Software engineering in embedded systems
  • XII.
  • XIII.

II.Course Introduction

EECS 373 is a class designed to teach you about embedded microprocessor systems. For a lot of you that doesn’ t clear up the issue too much. So let’ s start off by answering some fairly basic questions.

What is an Embedded System? [ABW]

  • Any device, or collection of devices, that contain one or more dedicated computers, microprocessors, or microcontrollers o Device(s) may be local - Printer, automobile, etc. o Devices may be distributed - Aircraft, ship, Internet appliance o A PC or workstation may contain one or more embedded systems.
  • Embedded computing devices have rigidly defined operational bounds. Not general purpose computers (PC, Unix workstation )

Who uses them?

  • The computer industry: Graphic cards, printers, network cards, scanners and routers.
  • The home: Home thermostats, microwaves, ovens and even refrigerators are likely to have one or more embedded processors.
  • In Michigan, the automotive industry is very active in the field of embedded systems. 2003 model cars can be expected to have 20-80 microprocessors controlling nearly everything (air/gas mixture in the engine, anti-lock breaks, air- bags, the CD player, and even the simple clock on the dashboard.)
  • Net effect: embedded systems are everywhere.

Why study embedded systems?

  • Since embedded systems are everywhere. That means there are a lot of jobs in the field.
  • As processing power increases, we’ ll be able to do incredible things that we haven’ t begun to imagine.
  • Because it sits on the hardware/software boarder you can write code and also play with hardware. Even if you think you enjoy one of those more than the other, it is nice to have that change of pace!
  • Basically, because it’ s fun and rewarding.

Embedded systems at the Univ. of Michigan

There are a number of classes closely related to EECS 373 at the University of Michigan.

At the start of this class you are assumed to be familiar with material from the required classes (270 and 370 are the official prerequists, but 280 is required for 370). In particular, logic design and assembly programming will be very important. Many architectual issues from 370 will also be used as will bits of C programming.

Other Introductory issues

In lab we will be loaning you a copy of the data book (usually called “the white book”) and making available a PowerPC assembly book (“the green book”). While this course pack, as well as the lectures, will discuss the MPC823 those books will be the primary source for learning about the chip and how to use it. In fact you will find the white book invaluable during lab and probably even during exams.

See the syllabus and/or web page for issues on grades, cheating, lab times, office hours, etc. This course pack doesn't cover that stuff...

EECS 270
  • Logic design
  • Xilinx tools
EECS 370
  • Assembly programming
  • Basic architecture
EECS 373
  • System architecture
  • Embedded programming
  • Hardware/software co- design
EECS 461
  • Embedded controls
  • HLL and embedded systems
EECS 280
  • HLL programming
  • Program design

would now hold 0x0012. The complete specification is found on page B-3 of the white book.

PowerPC Assembly Example

The best way to learn an assembly language is usually to dive right in. So let’s look at a simple PowerPC program. which converts an infinite uppercase ASCII string into

lbz r4, 0 (r3) l oads a b yte and z ero-extends it to 32 bits effective address is (r3) + 0 data book notation: U   0(0  U 

addi r4, r4, 0x add an i mmediate value r4 (r4) + 0x (0x20 is the decimal number 32 in hex. In ASCII the value for the upper and lower case of a given letter are exactly 32 apart. For example, ‘a’ – ‘A’ = 32.) stb r4, 0 (r3) st ores a b yte effective address is (r3) + 0 MEM( (r3) + 0 , 1)  r4[24-31]

The second addi has the same format as above, while b is an unconditional branch.

So the code in figure 1 simply loads a byte in from memory, adds 32 to the value and stores the newly incremented byte back out to the same location in memory. It then increments the register which points into memory by 1 and repeats the process forever. Obviously this is not most useful program in the world, but it does serve as a nice starting point for learning the assembly language.

PowerPC instructions

The PowerPC assembly language is fairly complex. In this section we introduce the assembly language more formally. This section does not take the place of the white and green books. Rather it is a simple overview of the language.

Figure 1. Simple PowerPC program

Loop: lbz r4, 0 (r3) addi r4, r4, 0x stb r4, 0 (r3) addi r3, r3, 1 b loop

Loads and Stores

Load/store opcodes start with l and st , respectively. The next character indicates the memory access size: b yte, h alfword, (2 bytes), or w ord (4 bytes). So lb is a load byte instruction. The effective address for the memory access can be computed in one of two ways. The most common is “ register indirect with immediate index” (also known as “ base + offset” or “ base + displacement” ). The format used in the assembly language for this addressing mode is “ d(ra)” which denotes an effective address of (ra) + d where d is a 16-bit signed value.

Another addressing mode in the PowerPC ISA is “ register indirect with index” , also known as “ inde x ed” or “ register + register”. If you want to use this addressing mode you need to append an x to the opcode. So stbx rS, rA, rB denotes that the effective address is (rA) + (rB). One interesting note, the PowerPC architecture sometimes treats r0 as a constant 0 but not always. One case of where it does is in the indexed version of the load and store if rA=r0 then r0 is treated as a 0 no matter what actual value is stored in r0.

BWhy do you think r0 is treated the way it is for indexed loads?

One other obvious issue exists for loads: what happens when you load 16 bits into a 32- bit register? Obviously the lower 16 bits of the register will be loaded with the 16 bits from memory, but that still leaves the other 16 bits. The PowerPC gives two options you can do an a rithmetic load or a z eroing load. In the case of the arithmetic load the upper 16 bits get the value of the most significant bit of the 16 bits that are loaded. This is a 2's complement sign extension. The zeroing load always puts zeros in those upper 16 bits. You might think that something similar would exist for loading a byte, but for whatever reason, only the zeroing option is allowed by byte loads (but see the extsb instruction).

Finally, the PowerPC supports an update feature for its loads and stores. A load with u pdate has the side effect of changing the register used in computing the effective address to the value of the effective address. For example if r3 is equal to 12 the instruction

lwzu r4, 12(r3) would load register four with the value stored in memory location 24 and would change register three to have the value 24.

The green and white books have many more details about loads and stores and about support for still different formats and options. In closing we list those load and store opcodes which were discussed or hinted at in this section.

Summary of load/store instructions seen so far:

lbz lhz lha lwz stb sth stw lbzx lhzx lhax lwzx stbx sthx stwx lbzu lhzu lhau lwzu stbu sthu stwu lbzux lhzux lhaux lwzux stbux sthux stwux

ALU instructions – not exactly orthogonal

When an ISA is described, one word that is often used to describe a “ pretty” ISA is that the ISA is orthogonal. This means that each opcode has all of the options of other,

( mullw ). Proper use of the overflow bit in the XER register (described below) can help to determine if the mulhw instruction is needed.

Compared to the rest of the basic arithmetic instructions, division is very straightforward. The two basic instructions are simply divw and divwu , for signed and unsigned division of words.

Other instructions

In addition to load/store and ALU instructions there are many other instructions. Obviously this includes branches. But it also includes comparison instructions and instructions that manipulate special purpose registers. For the most part, we will introduce these special purpose instructions as needed, but without the branching instructions we are hard pressed to write useful assembly programs, so we will discuss them here.

The basic instructions are the unconditional b ranch b , and the b ranch c onditional, bc. If you look in the green or white books (pages 8-23 and B-20 respectively) you will see that the unconditional branch is fairly complex. The branch offset is a 24-bit field. It can be treated as either a PC-relative address or an absolute address depending on a the value of a bit in the instruction encoding (the AA bit). Further, it can can save it’s current PC to a special purpose register (the Link Register, or LR). Having the old PC around is obviously useful when branching to a function.

The bc instruction is even more complex. When writing assembly code, the simplified mnemonics like blt and bne are used more often than the bc instruction itself. DUsing the white or green book, figure out what the 32-bit encoding would be for the instruction bne cr3, bob in the following code: bne cr3, bob nop nop bob: nop Use relative addressing. bne is defined on page B-22 of the white book. (Warning, this is quite hard and requires a bit of digging.)

PowerPC Architectural issues

Trying to summarize the PowerPC architecture in a few paragraphs is doomed to failure. The green book spends hundreds of pages trying to do just that. Rather we will only look at a few of the more important architectural issues at this time. Later in this course-pack various other architecture issues will be discussed as needed.

Special Purpose Registers

If you did the bne cr3, bob problem above, you’ve probably realized that there are a number of special registers in the PowerPC ISA. In fact, the MPC823 implementation

has a huge number of such registers. The number specified by the PowerPC ISA is only large. If you look on page Index-11 of the green book under “ registers” you will see this listing of registers. Of all these registers, we will only focus on a couple of the more basic.

The CR register, as you likely learned above, is the basis for deciding if a branch should be taken or not. In the LC computer seen in EECS 370 the branch format was something like

BEQ 1 3 joe

Meaning that if registers 1 and 3 were equal in value the branch would be taken to the label joe. In the PowerPC the same thing is accomplished by using a c o mp are instruction ( cmp ) and a bc instruction. The cmp instruction sets 4 bit of the 32-bit CR register. Normally speaking on the MPC823 you will only use the first 4 bits, called CR0. (See page 2-5 of the green book.) Those 4 bits are

z Negative (LT) – this bit is set when the result is negative.

z Positive (GT) – this bit is set when the result is positive (and not zero).

z Zero (EQ) – This be is set when the result is zero

z Summary overflow (SO) This indicates at an overflow occurred sometime since this be was explicitly cleared. See page 2-11 of the green book for details.

So to do the same thing as the LC instruction seen above you could do:

cmpw r1, r beq joe

This may seem like something of a waste, but keep in mind instructions like add may also affect the CR register (CR0 only though) and thus the compare is often unneeded.

Registers other than the CR also can be important. The XER, LR and CTR registers can be important. You might want to read pages 2-1 to 2-11 of the green book, skiping over the details about the FPSCR (which is for floating point numbers, something the MPC does not support.) You will find the LR very important later on, and the CTR, used correctly, can make certain “ for” loops much easier to write in assembly.

Questions

  1. Which of the following would be associated with the ISA and which with a specific implementation of the ISA? a) Size of the L1 cache b)Number of general purpose registers? c) Number of ALUs d)Maximum number of bytes of memory allowed (both!) e) Number of bits used for the immediate value in a load instruction

IV.Memory Mapped I/O – the basics

How does one access I/O devices though a programming language? You’ve learned at least one assembly language and I'll bet there wasn't a “ talk to disk drive” instruction. Instead of developing special instructions to talk to I/O devices, the vast majority (all?) microprocessor use memory mapped I/O. The idea is that load and store assembly instructions (or other instructions which can talk to memory on CISC machines) can be used to read and write messages to the devices.

Each device has one or more special purpose registers that are each mapped to some address in memory. For example, imagine a mouse that needs to be able to report where it has moved since that last time it was queried. Imagine that the mouse responded with a 16-bit field, and 8-bit two's complement number describing the amount moved in along the X-axis, and the other 8-bits would be the two's complement value of the amount moved along the Y-axis. So 0x0070 would imply the mouse was moved up along the Y- axis but not at all along the X-axis. We could design the device so that it supplied this information whenever memory address 0x0000E004 was loaded. That is, the data for that load would not come from the DRAM but rather from the mouse.

Continuing the mouse example, say a half-word load is performed from 0x0000E004 and the response was 0x0400. This might imply that the mouse has moved some positive distance along the X-axis since it was last queried. If another half-word load is performed immediately afterward, it may be that a 0x0000 would be returned as the mouse likely would not have moved enough to be noticeable in the few tens of nanoseconds between the two loads.

This example, while fairly simple, sheds light on a number of important issues regarding memory-mapped I/O devices. First of all, consider what would happen if the data from these requests were cached. Each time a read was performed the data would be the same as the last time the device were read rather than the data that was supposed to be read from the device. Obviously this is undesired behavior, and so we have to be sure that those addresses mapped to I/O devices are marked as being uncacheable.

Secondly, notice that performing a read can have side-effects. In our mouse example, the I/O device responds with the movement since the last time it was read from. This means that in addition to responding with the requested data the future behavior of reads from the device has been impacted. This is important because we now have to be careful about issuing loads speculatively (for example if a branch has been predicted taken, we now have to be sure that a load directed at an I/O device doesn't issue until the prediction has been verified, otherwise we might lose some data. By the same token, we have to worry about issuing loads of the proper size. If we load a word when we only need a half-word, it is possible that the extra bytes loaded are from an I/O device. Again, we might lose data from our mouse because of the extra read.

Lastly, and perhaps most obviously, memory is now volatile. Not volatile in the since that the data goes away without power (although that might be true also), but rather volatile in the since of the C-language keyword. Obviously this is closely related to being uncacheable.

Simple memory-mapped I/O example

Say we have two simple devices. One is a button, the other a light-emitting diode (LED). Associated with the button is an 8-bit register located at memory address 0xF0040004. That 8-bit register returns a 0x01 if the button is pushed, and 0x00 if the button is not currently pressed. Similarly, associated with the LED is an 8-bit register located at memory location 0x000000FF. If a zero is written to that memory location the light is turned off. Writing anything else to the register causes the light to come on (and stay on until turned off). Write a PowerPC assembly program that turns the light on when the button is pressed and turns it off when the button is not pressed. It should keep checking forever.

lis r3, 0xF ori r3, 0x li r4, 0x00FF loop: lbz r5, 0(r3) sb r5, 0(r4) b loop

ENow write the code so that the button acts as a toggle. Each time you press the button the light should change state. Start the light in the off state.

Questions

  1. Assume you have the following I/O devices
    • A button which is memory mapped into a single byte of memory at location 0x0000F000. That byte will be a 1 if the button is pressed, a zero otherwise.
    • A keyboard that is memory mapped into a halfword of memory at location 0xFFFF0000. That halfword will be all ones if nothing has been pressed since the last time a read was performed. Otherwise it will be the 8-bit ASCII value for the character pressed (the 8 most significant bits will be 0’s in that case.)
    • An array of 8 LEDs that are memory mapped into a single byte at memory location 0x0000F001. Each LED is mapped to 1 bit of that byte. If the corresponding bit for an LED is 1, it will be turned on. Otherwise it will be off. a) Write a program that will turn on all of the LEDs if the last key pressed was an X. (0x58). b)Write a program which lights all of the LEDs only if the key currently pressed is different than the key which was last pressed. c) Write a program which displays the most recently pressed character (in ASCII) on the LEDs only if the button is pressed. Otherwise all of the LEDs should be off.

Volatile (C-language definition): the variable may be affected/changed by outside influences.

V. Bus Protocols

When interconnecting different devices some type of protocol needs to be observed. Traditionally the protocol used in an embedded system is that of the processor’s memory bus. I/O devices are connected directly to the same interconnect that the memory system uses. Looking back the discussion about memory-mapped I/O in Chapter 4, having the I/O devices watching the memory bus makes sense. After all, the I/O devices are acting as if they were memory devices – you can read and write to them using loads and stores, just as is done with memory. So the I/O device can intercept loads and stores to those addresses to which they are mapped.

Over time, there have been many variations on this basic theme. One of the more interesting (and relevant) examples of such variation can be seen in desktop PC arena. When the 486

I/O I/O I/O I/O

Processor Processor

Memory & I/O

Chipset

L

Cache

L

Cache

The “ Big” Picture

Front Side Bus

(Processor bus)

PCI bus

(I/O bus)

Back Side bus

(No name?)

Memory

Memory mapped I/O – again

VI.ABI and the Stack

VII.Interrupts

Flip-Flops MUX SIMASK SIPEND SIVEC

CORE
SIEL

IRQ

IRQ#[0:7]
LVL[0:7] 8

XI.Bonus Topics

Memory types

Error correction

Parity

Error Correction Codes (ECC)

Viterbi algorithm for error correction

The basic idea: z With each data bit, send a parity bit along also. z The parity bit is the parity of all of the data sent so far. z Assume that there are few bit errors. If the parity doesn’ t work out, figure out the smallest number of bit flips which could have occurred to get to the current data.

Example: Say we want to send the data 10001. Using even parity we might actually send: Notice that all of the data bits thus far, plus the current parity results in an even number of ones. So at the first step we have 1 for data and 1 for parity. At the second step we have 10 for data and 1 for parity. At the 5th^ and final step we have 10001 for data and 0 for parity (still even number of ones).

Say that in transmission two errors occur and we get:

Notice that both the data and the parity bit of the 3rd^ step have been changed.

We want to try to recover the data. Notice that the parity bits for the 4th^ and 5th^ step are clearly wrong. Thus we know we had some error.

Topic shift

Lets consider writing the data and parity bits as a single decimal number with the data bit as the MSB. So the code that was sent was 31112 and the code received was 31212. Notice that in a legal encoding certain numbers cannot follow other numbers. For example a 0 (that is 0 data 0 parity) cannot be followed by a 2. If it were the parity bit of one of the two numbers must be wrong The basic reason is that if we have a 0, the parity up to that time must have been even and so we put in a zero parity bit. If the next data bit

is a 1 then the parity bit that goes with that data bit must also be a 1.. If you don’ t believe me try to find a case where a 2 can follow a 0.

In general 0 and 2 can be followed by 0 or 3 and 1 and 3 can be followed by a 1 or a 2.

We can draw a graph which shows the same thing as follows:

The numbers on the right indicate the starting point, the numbers on the left the finishing point. So 0 followed by a 3 is legal, but 3 followed by a 0 is not.

Now, let us return to the original problem. 31212 has a transition from 2 to1 which is clearly not allowed. So we have at least one error. Let us draw a graph for the entire problem.