Project Testing; Processor Examples

Project Testing --thorough, efficient, hierarchical --done by “independent tester” --well-documented, repeatable --3 levels: * system—derive tests from specifications * component integration--.vec files + integration plan * individual module--.vec files

individual module--.vec files typical modules may be: alu components registers multiplexors i/o components many of these (or slight variations) will have been created as answers to questions in homeworks 2 or 3; these should be reused in your project if possible Another module you will need is the control unit (fsm); this should be tested completely using a.vec file

component integration--.vec files + integration plan Once you have designed some components, you need to start putting them together to form your system You should have a PLAN for the order in which components will be integrated and a.vec file to test your developing system after the integration of each component Your integration plan should be part of the project description you include in your report

system—derive tests from specifications The top-level testing should be for your system. For this level, you have specifications, based on the game description you wrote. You need to turn these specifications into a set of test cases to show that your specifications are met. These test cases may consist of: --cases in which the system behaves appropriately for given input --performance tests (e.g., does the system react fast enough?) --user-friendliness, e.g., nice display, easy to do input

Processor Examples “Harvard architecture”: --PIC processor family “von Neumann architecture”: --simple processor (homework 1) --  P 3 processor (chapter 9) --MIPS processor (chapter 14) --NIOS II processor core (chapters 15-17) Control ALU Memory Data + Instruc. I/O Control ALUInstruc.I/OData

PIC processor family Reference: PIC: peripheral interface controller Originally (~1975) for offloading I/O functions from a CPU Harvard architecture: data and instructions (“code”) are stored separately—thus a data item and an instruction do not need to be the same length Newer versions have a stack One accumulator (referred to as W), but memory is usually referred to as a “register file” Some versions allow a type of indirect addressing Usually referred to as a RISC machine; may have up to 70 instructions May be able to access external memory (newer versions) Many development tools & languages available Data “Code” (Instructions)

simple processor (homework 1): Von Neumann architecture Only one general purpose register (accumulator) Supports direct, indirect, and indexed addressing Small instruction set, 2 formats ( or 111) Primitive I/O (via accumulator) No built-in stack / stack pointer No ability to do virtual storage

 P 3 processor (chapter 9) Similar to homework 1 processor—von Neumann architecture, 1 accumulator Implementation uses < 1% of Cyclone device logic Memory and I/O are now each components on the data bus; all info goes through MDR (fig. 9-1) 8-bit instructions, 8-bit data in 1 16-bit word, several formats Only direct addressing Only 5 instructions given (load, store, add, jump, jneg)—can these support general-purpose computing? (additional instructions given in the exercises) No stack pointer Can it do virtual storage?

MIPS processor (chapter 14) Widely-used RISC architecture, 1980’s 32-bit instructions, 3 formats 32 general-purpose registers 1-cycle fetch/decode/execute (employs pipelining)

NIOS II processor core (chapters 15-17) Hardware (IP) core—SOPC example; C/C++ compiler 32-bit datapath 1-6 pipeline stages 32 general purpose registers, 6 special-purpose Optiional instruction cache Optional multiply/divide instructions Hardware floating point unit can be added Hardware can be customized Development environment includes; --C/C++ compiler --Ability to customize library for the peripheral devices you need