8/8/2019 Project ENGN3213 2009

1/31

Department of Engineering

Australian National University

ENGN3213

Digital Systems & Microprocessors

Project

V1.0Copyright 2009 ANU Engineering

1

8/8/2019 Project ENGN3213 2009

2/31

Contents

1 Introduction 3

2 Reverse Polish Notation 4

2.1 History of Reverse Polish . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Reverse Polish Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.3 The Memory Device in Reverse Polish . . . . . . . . . . . . . . . . . . . . 6

2.4 The HP-35 Reversal Polish Algorithm . . . . . . . . . . . . . . . . . . . . . 8

3 RPC Design and Specification 11

3.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2 The PS/2 Keyboard Interface . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.3 The Seven Segment Display Interface . . . . . . . . . . . . . . . . . . . . . 13

3.4 RTL design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4 Project Details 15

4.1 Keyboard and Display Interfaces . . . . . . . . . . . . . . . . . . . . . . . 15

4.2 Implementation Levels of the RP Engine . . . . . . . . . . . . . . . . . . . 16

4.2.1 RP Engine Level I . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.2.2 RP Engine Level II . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.2.3 RP Engine Level III . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.2.4 PEGASUS Boad Peripherals . . . . . . . . . . . . . . . . . . . . . . 20

4.3 Project Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.4 Assessmnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

A Appendix: A Description of the MU0 Microprocessor 23

A.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

A.2 The Control Path Finite State Machine . . . . . . . . . . . . . . . . . . . . 25

A.3 MU0 in action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

A.4 Running a Program on MU0 . . . . . . . . . . . . . . . . . . . . . . . . . . 28

A.5 MU0 Assembly Language? . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2

8/8/2019 Project ENGN3213 2009

3/31

1 Introduction

In this course I have emphasised the Register Transfer Level (RTL) description of com-plex digital systems. An early example of the technique was demonstrated in the design

amd implementation of the MU0 microprocessor (described in detail in the appendix).By now you should be familiar with the details of the operation of MU0 and ready toapply the same approach to other designs. The design and operation of MU0 is the bestindicator so far of how you should approach the present project. In the labs, you havealso been learning many new things about the implementation of hardware in VERILOGthat can now be applied in a real design.

The project will give you the opportunity to use the RTL technique for the design of asystem of modest complexity: a reverse polish calculator with 4 significant decimaldigits. The project has various milestones among the specifications to allow you to do atop-down design and to tackle the project at various levels of complexity with plenty of

scope for individual creativity. A major aspect of the project will be to explore differentapproaches of developing the different hardware blocks taking special account of meetingspec and synthesis in hardware.

Additional information can be found on the course website:

http://engnet.anu.edu.au/DEcourses/engn3213/Documents/PROJECT

3

8/8/2019 Project ENGN3213 2009

4/31

2 Reverse Polish Notation

2.1 History of Reverse Polish

Reverse polish notation or RPN is an arithmetic notation introduced by the Polish math-emetician Jan Lukasiewicz in 1920. During the 1960s and 1970s, RPN had some currencyeven among the general public, as it was widely used in desktop calculators of the time.The Hewlett-Packard HP-35, shown in Figure 1 was the worlds first handheld scientificcalculator (1972) and was based on RPN ([1]).

Figure 1: The HP 35 calculator.

The arrival of the HP-35 was a significant event given the market dominance of slide rulesand mechanical calculators for engineering computations. The HP-35 used a traditionalfloating decimal display that automatically switched to scientific notation. The fifteendigit LED display was capable of displaying a 10 digit mantissa plus its sign and a dec-imal point and a two digit exponent plus its sign. The display was unique in that themultiplexing was designed to illuminate a single LED segment at a time, rather than asingle LED digit, because HP research had shown that this method was perceived by the

human eye as brighter for equivalent power.

Architecturally, the calculator was a bit-serial machine that processed 56-bit floating-pointnumbers, representing 14-digit BCD (Binary Coded Decimal) numbers. Figure 2 showsthe main board of the HP-35. As you can see, integrated dual in-line was the technologyof the day.

4

8/8/2019 Project ENGN3213 2009

5/31

Figure 2: The HP 35 main board.

2.2 Reverse Polish Notation

RPN is a simpler and more practical alternative to the conventional procedure for per-forming arithmetic calculations that we learned in school. The latter method is relianton the use of parentheses and equals signs and is sometimes referred to as infix notation.RPN is often referred to as postfix notation.

RPN is easiest to explain by example. Consider the following simple operation,

4 + 5 =

In RPN this expression is written,

5

8/8/2019 Project ENGN3213 2009

6/31

4 ENTER 5 +

There is just one operation key referred to as ENTER. Computations are performed

incrementally and results are stored in memory as we proceed. Here is a more complexexample,

(4 + 5 2) / 7 =

In RP we would do,

4 ENTER 5 ENTER 2

+ ENTER 7 /

Note the logical manner in which the calculation proceeds and how parentheses and equalssigns are eliminated. To do the project, you will need to familiarise yourself withReverse Polish notation.

2.3 The Memory Device in Reverse Polish

RP calculations require some form of limited memory to store variables and results. TheRP algorithm is suited to a special memory device referred to as a stack. A stack is acomputer term for a memory in which data is stored on a pile of registers. A stack isanalogous to a filing system in which the latest document to be filed is placed on top ofthe document pile.

A stack is a Last In First Out (LIFO) memory. When a variable is stored, it is pushedonto the stack. When a variable is to be retrieved, variables higher on the stack have tobe popped until we reach the desired variable. The stack does not need to be very deepi.e. have many memory locations. The HP 35 stack has only four levels.

To see how the stack would be used in RP, consider the following examples,Example 1

(4 + 2 5) / (1 + 2 3)

In RPN this is described by,

6

8/8/2019 Project ENGN3213 2009

7/31

8/8/2019 Project ENGN3213 2009

8/31

8/8/2019 Project ENGN3213 2009

9/31

Figure 3: The HP 35 instruction sticker.

As you can see the HP implementation differs in a couple of ways from the version pre-sented above. Firstly the KHR in a HP-35 is actually the input register to the stack,X (see Fig. 4) (the display being connected to this register). Secondly, after an op-eration is executed, results are pushed onto the stack without the need for an ENTERkey. Actually the HP-35 algorithm does allow the user to press the ENTER key after anoperator. However this has exactly the same effect as not pressing the ENTERN key: soit is probably ignored. The reason for this design decision appears to be to reduce thenumber of ENTER key strokes used in lengthy calculations. In my experience one of the

greatest weaknesses in the engineering of the HP RP calculators was the tendancy of keysto stick after extended use.

9

8/8/2019 Project ENGN3213 2009

10/31

Figure 4: The HP-35 RP implementation explained.

10

8/8/2019 Project ENGN3213 2009

11/31

3 RPC Design and Specification

3.1 General

The overall block diagram of the project is shown in Figure 5.

Figure 5:

In addition to the reverse polish calculator RTL system (RP engine), the project alsoinvolves interfacing to a PS/2 AT keyboard and a seven segment display. You shouldtreat the keyboard and seven segment interfaces as separate design projects from theRTL design of the RP engine itself. In designing these three subsystems you will have

to decide how they will interface to each other. How you present data to the RP enginefrom the keyboard affects the form and timing of the inputs to the RP engine. Similarlyhow you process data in the RP engine affects what type of decimal encoding has to bedone before the seven segment display.

3.2 The PS/2 Keyboard Interface

The keyboard is a simple FSM design involving a serial to parallel converter. A goodintroduction to the PS/2 AT keyboard and its communications protocol can be found at

http://www.beyondlogic.org/keyboard/keybrd.htm

As described in this article when a key is pressed, the keyboard sends data frames referredto as scan codes via an asynchronous serial protocol. As shown in Figs 7 and 6 thesescan codes are mostly 8 bit but in some cases (for e.g. the Del, Ins, / and ENTER keys)they are 16 bit. As we are using a subset of all available keys, you will need to designyour keyboard interface to deal with unused keys in a friendly way.

The PS/2 keyboard interface will involve two main parts.

11

8/8/2019 Project ENGN3213 2009

12/31

Figure 6: Keyboard showing the RP function keys.

Figure 7: Keyboard scan codes.

1. A serial to parallel converter FSM that handles the PS/2 protocol.

2. An output buffer to make KEY data available in a suitable format to the RP engine.

A sample serial protocol FSM is available on the project website. You may use this as

a starting point to develop code to receive data from the keyboard. This code followsWakerlys coding style for VERILOG coding of FSMs. You will have to adapt it to thespecific PS/2 keyboard protocol shown in Fig. 8.

The form in which you provide the keyboard output influences the design of the RP RTLcontroller. For example we will provide the key identity in a coded format, KEY, (if a keyis pressed) or as a NOKEY symbol (if no key or a wrong key is pressed) on the posedgeof the RP system CLOCK. Using this technique, unused scan codes can be replaced withthe NOKEY code.

12

8/8/2019 Project ENGN3213 2009

13/31

Question: Read through the above article and explain how the IDLE mode pull up to+5V is obtained.

Figure 8: Keyboard serial protocol.

3.3 The Seven Segment Display Interface

The seven segment display driver will also include two parts.

1. A BCD (binary coded decimal) or other encoder to convert the RP engines chosennumber format into a form suitable for driving the display.

2. A display driver that drives the anodes and cathodes of the seven segment displaygiven the decimal values of the digits to be displayed.

Dealing with the former issue is a big part of the project and the output format depends

on the implementation level you are trying to achieve. You should already be familiarwith code capable of implementing the display anode and cathode driver.

Further descriptions of the keyboard and seven segment displays can be found in thePEGASUS and BASYS manuals on the project website:

http://engnet.anu.edu.au/DEcourses/engn3213/Documents/PROJECT

3.4 RTL design

Given the implementation of the RP algorithm described above and following the RTLdescription of MU0 (the appendix), one may propose the RTL archotecture of the RPcalculator shown in Fig. 9.

In this figure, the control path is a FSM (at the left) which has two inputs: the keyIDcode and a reset. The keyID and reset are synchronised to the RP engine system clock.From the above example of the KHR, exactly one keyID appears per positive clock edgefor each valid key. Otherwise a NOKEY is produced. The reset must be provided viaa separate input such as a PEGASUS board pushbutton and not from the keyboard so

13

8/8/2019 Project ENGN3213 2009

14/31

Key Holding Register (KHR)

Arithmetic Logic Unit

Stack OutStack In

FSM

Input

Output

ResetkeyID from KB interface

Display

Output

Output

Input

interface

Figure 9: Simplified RPN RTL control and data paths.

that the calculator can be manually forced into the INIT state (commonly referred to asswitching on the calculator).

The keyID inputs are analogous to the commands stored in memory in MU0. Thesedetermine the state transitions of the RP controller FSM.

The outputs of the controller are a bunch of enable and reset switches that control thehardware blocks of the data path. As is the case for MU0, there should no need tosend the data buses through the controller FSM (see Fig. 9.)

In addition, the data path consists of well defined hardware blocks. In thepresent example these are the key holding register, an arithmetic logic unit and astack.

14

8/8/2019 Project ENGN3213 2009

15/31

4 Project Details

Now that we have an idea of what the project involves, lets see what you have to do.The project will consist of a design and implementation of various RP calculators for

the PEGASUS board with an XC2S50 FPGA (our target hardware). The aim will be todesign and implement a keyboard interface, a seven segment display interface and up to 3designs and implementations of increasing complexity and functionality of the RP engine.

4.1 Keyboard and Display Interfaces

These have to be fairly universal. The display interface must be capable of displayingdigits, decimal points and any other characters you think may be necessary at somelevel of RP engine implementation. The main requirement is that you meet the

precision standards specified so that the same outputs are produced for a givecombination of inputs to the calculator.

The keyboard interface should be capable of sending any key, but you will have to take careof filtering unwanted keys. Allow me to suggest the KEY/NOKEY system described aboveif you wish. This will allow a standardised input into all the RP calculators developed bythe class.

The KEY/NOKEY system is described in Fig. 10.

Keyboard interface

Keyboard data

Keyboard Clock

RP Sys Clk

KEY / NOKEY

NOKEYNOKEYKEY KEY

RP Sys Clk

Figure 10: Keyboard input and output formats. The timing diagram shows how thekeyboard interface outputs keys on the posedge of the RP system clock.

The following encodings may be used for the key IDs.

15

8/8/2019 Project ENGN3213 2009

16/31

KeyID Representation

ZERO 5h00ONE 5h01

TWO 5h02THREE 5h03FOUR 5h04FIVE 5h05SIX 5h06

SEVEN 5h07EIGHT 5h08NINE 5h09

ENTER 5h0ACHS 5h1ACLX 5h0BCLR 5h1B

PLUS 5h0CMINUS 5h1CTIMES 5h0D

DIV 5h1DDP 5h0E

NOKEY 5h1E

4.2 Implementation Levels of the RP EngineIn the following sections different levels or versions of the RP engine are described. Thelevels correspond to increasingly complex implementations and improvements in function-ality of the calculator. The changes mainly affect the design of the arithmetic logic unit.It is not compulsory to attempt to design and implement each of these in the project, butlevel I is compulsory and levels II and III do attract 12 additional marks out of 40.

Make sure that you implement either the direct or the HP Reverse Polishalgorithm previously described.

In short these levels are

1. A signed decimal integer calculator that does addition and subtraction.

2. A fixed point signed decimal calculator that also does multiplication and division.

3. A floating point signed decimal calculator that also does multiplication and division.

In order to obtain full marks in the project it will be necessary to completeboth of the more complex fixed and floating point implementations of the

16

8/8/2019 Project ENGN3213 2009

17/31

ALU. Much of this requires a good understanding of number systems andrepresentations. Those who have not done the COMP2300 course may findthe following lecture notes useful.

http://cs.anu.edu.au/student/comp2300/lectures/

4.2.1 RP Engine Level I

This is the simplest level. We confine ourselves to decimal integer addition and subtrac-tion. Key functions will be entered from the PS/2 keyboard and will be displayed onthe seven segment display. To illustrate the functionality at this level consider Figure 11showing the front panel of a HP-35 calculator. The relevant keys are shown inside theyellow squares.

Figure 11: HP-35 functionality for the level I system.

The large blue key on the top left is the ENTER key. The operator keys and + are inblue at the left. The CHS button changes the sign of the current number on the displayand CLX clears the display to a 0. The CLR key clears the stack. At this level we willnot implement the keys that have a red cross through them. These include, among many

17

8/8/2019 Project ENGN3213 2009

18/31

others, the EEX key which converts a number to scientific notation, the PI key whichstores the number and the decimal point key.

The following table shows the meaning and AT keyboard designations of the HP-35 keysof Figure 11.

RP FUNCTION KEYBOARD DESIGNATION Result

ENTER Enter Key Store on stack

Subtract

+ + Add

CHS Num Change sign of last number entered

CLX Del Clear the display to 0.

CLR Ins Clear all stack levels to 0.

At this level you develop your basic RTL design. This is the most important

project milestone. Try to make it extensible to the more complex designs.The precision is to be the full 4.0.

4.2.2 RP Engine Level II

The aim is to implement fixed point arithmetic with fractional decimals: a very commonfunctionality in digital systems such as data radios and MPEG codecs. Fig. 12 showsthe HP-35 keys.

At this level we include multiplication, division and a fixed decimal point inthe middle of the display. The precision is 2.2.

The following table shows the meaning and keyboard designations of the HP-35 keys ofFigure 12.

18

8/8/2019 Project ENGN3213 2009

19/31

Figure 12: HP-35 functionality for the level II and III systems.

RP FUNCTION KEYBOARD DESIGNATION Result

ENTER Enter Key Store on stack

Subtract

+ + Add

Multiply

/

/

Divide

. . Decimal point

CHS Num Change sign of last number entered

CLX Del Clear the display to 0.

CLR Ins Clear all stack levels to 0.

19

8/8/2019 Project ENGN3213 2009

20/31

4.2.3 RP Engine Level III

This is the most difficult level. We aim to implement floating point arithmetic (allbeitwithout scientific notation). The floating decimal point in the result adjusts itself to

the appropriate position on the display. Floating point will allow us to multiply decimalnumbers with larger dynamic range than fixed point.

The precision is 4 digits maximum before the decimal point and 3 digits max-imum after the decimal point.

Since we will not be trying to implement exponents, the HP-35 functionality is the sameas in Fig. 12 followed by the same table above showing the keyboard designations.

4.2.4 PEGASUS Boad Peripherals

Fig. 13 shows the PEGASUS board peripherals that will be used in the project.

Figure 13: PEGASUS board showing the peripherals.

You may also have noticed that it will not be possible to accurately representresults that include minus signs if we confine ourselves to the four digit sevensegment display. In this project we will use the four decimal digits of the

20

8/8/2019 Project ENGN3213 2009

21/31

display for numerical data and an illuminated LED for a negative result asshown in Fig. 13.

I will leave it to you to decide how to deal with overflows. For example you may decide todisplay a row of four minus signs. Interestingly the HP-35 fails to handle overflow properly.

The HP-35 rounds overflowing results down to the maximum number 9.9999999991099.Dividing any two numbers larger than this by each other produces a 1.

4.3 Project Rules

This project leaves plenty of scope for individual creativity. You do not have to followthe exact procedure described above for the RTL design. If you do choose to be creativein your coding style then I expect a solid justification in terms of theory and synthesisedhardware.

The following are the project rules.

1. You may work in groups of one or two (maximum). Let me know the group members.

2. You hand in one report per group.

3. The length of the report should be < 30 pages. There is no pressure to produce abig report and there will be no penalties for exceeding the limit.

4. Hand in the report in hardcopy and include the code and a softcopy of the reporton an attached CD.

5. You may not use any third party code. All VERILOG code is to be theoriginal work of the group save code offered for general use on the coursewebsite.

6. You must follow the design conventions introduced in this document.

7. The project is worth 40% of the final mark and must be handed in to meby C.O.B Friday June 5.

4.4 Assessmnet

Assessment will consist of the following tasks to be described in the report. The projectreport will be worth 30 marks in total. In addition there will be a hardware test lab atwhich marks will be awarded for successful implementations. The lab demonstrations willbe worth a maximum of 10 marks.

1. A short introduction to the project and the approach taken. A short description ofhow the labour was divided amongst team members (if relevant). 2 marks

21

8/8/2019 Project ENGN3213 2009

22/31

2. A description of the design of the keyboard and display interfaces. 4 marks

3. A description of the design of the RTL control path of the level I system includingnext state tables and/or state diagrams, Karnaugh maps and appropriate excerpts

from the VERILOG. 4 marks4. A description of the level I hardware blocks in the datapath. A description of the

arithmetic logic unit, how it does its calculations and what design trade-offs youhave had to make to meet timing constraints and space limitations. 4 marks

5. For the level I system provide test benches and simulation traces (e.g. GTKWAVEor ISE XST) demonstrating individual working hardware blocks and a completeworking system. 4 marks

6. A description of the level II and III hardware blocks in the datapath. A detaileddescription of the arithmetic logic unit, how it does its calculations and what designtrade-offs you have had to make to meet timing constraints and space limitations.3 further marks each

7. For each level you attempt, provide the FPGA resource consumption through theISE synthesis reports. Provide and discuss the floorplanner output(s). flat 3 markstotal

8. Overall VERILOG coding style - 3 marks

9. A hardware demonstration of levels I. Does the calculator work? Does the hardwaremeet spec? 4 marks

10. A hardware demonstration of levels II and III. Does the calculator work? Does thehardware meet spec? - 3 further marks each

Lab sessions to test hardware will be assigned closer to the final date.

22

8/8/2019 Project ENGN3213 2009

23/31

A Appendix: A Description of the MU0 Micropro-cessor

A.1 Introduction

The definition of the instruction set shown in Fig. 14 and the requirement of two clockcycles for an instruction forms the specification of MU0.

Figure 14: MU0 assembly language instructions

The first thing to do is to understand what goes on with these instructions. Note thesyntax of the commands. The symbol S refers to a memory address. The notation [S]refers to the contents of the memory location.

Consider the datapath of Fig. 15. It shows the following hardware systems,

1. A program counter register (PC) which stores the address in the memory of thecurrent instruction. Exactly what is the current instruction and what is the nextinstruction well see in a minute. The addresses count from 0 upwards and in anyprogram, the instructions are stored in the first contiguous memory locations whilethe data is store in the subsequent locations. This is the basis of the Von Neumannarchitecture wherein program and data are stored sequentially in memory.

23

8/8/2019 Project ENGN3213 2009

24/31

Figure 15: MU0 architecture.

2. An instruction register (IR) which contains the instruction while it is being exe-cuted.

3. An accumulator (ACC) which provides intermediate storage of data during in-struction execution. The ACC is sometimes referred to as the working register.

4. An Arithmetic Logic Unit (ALU)

5. Several multiplexers

In MU0 the data has 16 bits and the memory has storage locations that are 16 bits wide.The data in memory is stored at locations that can be located by their address. Theseaddresses are represented by words that are 12 bits wide. That is MU0s memory has 212

memory locations where data can be stored.

It is interesting and entirely pertinent to note that an instruction word consistsof 16 bits and can therefore be stored in memory. The most significant four bits([15:12] in VERILOG parlance) of the instruction word is referred to as the opcode. Thisis the machine language symbol that represents an instruction. This is the hex numberF in the left most column of Fig. 14. There are 16 possible opcodes but only 8 areimplemented in MU0. The meanings of the instructions are also described in Fig. 14.The remaining 12 bits in the instruction word is the address in memory of either theoperand that the instruction operates on (in the case of LDA, ADD and SUB) or the

24

8/8/2019 Project ENGN3213 2009

25/31

destination of the data in the ACC (STO) or the address of the next instruction in thecase of the JUMP commands (JMP, JGE, JNE).

Fig. 16 shows the instruction word format.

Figure 16: MU0 instruction format.

The program counter is incremented every instruction. It is only controlled by the activeedges of the clock. Consequently MU0 automatically runs sequentially through the ad-dresses in memory. Reading an instuction occurs when that instruction appears in the IRin the EXEC state.

The cunning in the design of the MU0 architecture is that each hardware block in thedatapath of Fig 15 is configured to execute these instructions by appropriate changes intheir control inputs. Examples of controls are PCen (enable PC), ACCen (enablethe ACC), Asel (choose the input that connects to the output of the addressMUX, a-mux), M (choose the function to be performed by the ALU), etc. Thebit values of these controls are the outputs of the control path FSM.

A.2 The Control Path Finite State Machine

The next state diagram of the controller in Fig. 17 describes how the FSM works.

The first column shows the states of which there are just two,

0 FETCH (fetch instruction and store instruction in IR) and,

1 EXEC (decode instruction in the IR and execute instruction).

The second column shows the opcode, F. The opcode is MU0s only input. MU0 obtainsthe opcode when the controller FSM reads bits [15:12] of the IR. The third column isthe next state that the controller jumps to. Note that the opcode is not needed in theFETCH state (0) because in this state the only steps are to mux the PC contents onto

the address bus through the a-mux and to set up the ALU input control, M, for a PCincrement. As a result, regardless of the F or opcode value, the next state is EXEC (1).This explains the dont cares, XXX in the F cell in the table.

If you look at the next-state diagram you should be able to confirm the interconnects ofMU0 in Fig. 18 for the FETCH state. The grey tracks indicate connected paths in thedatapath.

25

8/8/2019 Project ENGN3213 2009

26/31

Figure 17: MU0 next state diagram

A.3 MU0 in action

Try and follow the following verbal description. Remember that all registers (PC, IR andACC) and state transitions occur on the positive edge of the clock but memory read andwrites occur on negative clock transitions.

The sequence of events that occur in the FETCH state from the first postive transitionof the system clock are as follows.

1. The FETCH cycle occurs at the first positive edge of the clock.

2. In the FETCH state the a-mux input is connected to the PC output. The MUX isa combinational device and so the PC contents should already be pointing to theaddress of the next instruction in memory.

3. At tbe ensuing negative clock transition the memory transfers the contents of thelocation whose address is in the PC to the Dbus. The Dbus is the output data lineof the memory whereas the Xbus is the input data line.

26

8/8/2019 Project ENGN3213 2009

27/31

4. The contents of the Dbus are now present at the input to the IR.

5. In the FETCH state the PC contents are also pointing at the ALU input throughthe x-mux. The ALU M-value is set so that the ALU increments the value onthis input. Since both the x-mux and the ALU are combinational devices, the PCincremented contents are transferred instantaneously at the PC input. On the nextpositive clock transition the contents of the PC will be incremented ready for thenext time the FSM is in the FETCH state.

From the second positive clock transition we are in the EXEC state. The sequence ofevents that occur in the this state are as follows.

1. At this transition the PC increments its contents as discussed previously.

2. The IR registers the contents of the Dbus to its output.

3. The controller reads the [15:12] bits (the opcode) from the IR.

4. Depending on the opcode value, several function controls in the datapath may beenabled or disabled as follows.

If the opcode is LDA then the ACC is enabled and the y-mux is set so thatthe Dbus is connected to the ALU input on the Ybus. The ALU M value is setfor a through connnection on its Ybus input. At the positive edge of the nextclock transition into the FETCH state, the ACC output will store the contentsof the Dbus.

If the opcode is for ADD or SUB then the ACC is enabled and the Dbus isagain connected to the ALU via the Ybus through y-mux. The x-mux is set toallow the contents of the ACC onto the Xbus and the ACC M value is set forADD or SUB. On the subsequent negative clock transition the contents of thememory is transferred onto the Dbus. At the positive edge of the next clocktransition into the FETCH state, the ACC output will store the sum of itsprevious value and that in the memory location.

If the opcode is STO, the x-mux places the contents of the ACC on the inputto the Xbus which is also the memory input data line. The last 12 bits of thecontents of the IR are sent via the a-mux to the address bus of the memory.

On the next negative clock transition the memory stores the contents of theXbus (the contents of the ACC).

In the case of the JUMP instructions, the last 12 bits of the instruction registerare sent via the y-mux to the Ybus and the ALU. The ALU is set for straightthrough so that this new memory address is fed to the PC. At the ensuingposedge of clock (FETCH) the PC is changed to the address which is theoperand of the JUMP instruction.

27

8/8/2019 Project ENGN3213 2009

28/31

Figure 18: The MU0 datapath interconnects during FETCH and EXEC.

A.4 Running a Program on MU0

The following is a machine code listing of a MU0 program which adds the contents (000A)of memory location 4 to the contents (0001) of memory location 5. The first hex digit ineach command is the opcode. These are 0 (LDA), 2 (ADD), 1 (STO). The remaining 3hex digits are the address operands as discussed above.

0004 (load (LDA) the contents of memory adddress 4 into the ACC)

2005 (add (ADD) the contents of memory address 5 to that in the ACC)

1006 (store (STO) the contents of the ACC in memory location 6)

7000 (STOP)

000A (data stored in memory location 4)

0001 (data stored in memory location 5)

0000 (data stored in memory location 6)

Notice how execution occurs in purely sequential fashion. MU0 does not know which

memory addresses contain instructions and which data. Its proper operation dependsentirely on proper programming and the march of the PC contents. The STOP commandterminates execution and prevents the processor from trying to perform a false opcode inthe first hex digit of the data at memory location 4.

Fig 19 shows the complete GTKWAVE output from running MU0 with ICARUS VER-ILOG.

Fig. 20 expands the traces around the FETCH and EXEC states when the instruction2005 is being executed. For instruction 2005 the PC is pointing to address 1 in memory.

28

8/8/2019 Project ENGN3213 2009

29/31

Figure 19: GTKWAVE traces of the MU0 data during execution of the above program

During this instruction the contents of memory address 5 (0001) is added to the contentsof the accumulator which is by now 000A. Notice that the actual instruction 2005 doesnot appear in the IR until the EXEC state is reached and that the contents of the ACCdo not register the sum, 000B, until the FETCH cycle of the following instruction.

A.5 MU0 Assembly Language?

The lexical commands in Fig. 14, LDA, STO, etc are referred to as assembly languageinstructions. Normally when writing programs for a microprocessor one only has to usethese commands and some variables representing the data. This is clearly much easier toread than the column of numbers that form the machine code. However use of assemblylanguage presumes the existence of an assembly language compiler or assembler for shortwhich translates tbe assembly language into machine code. Unfortunately (to the bestof my knowledge) MU0 does not have an assembler written for it (though you may beattempted to write one in JAVA or C, I dont think it would be difficult). We have already

29

8/8/2019 Project ENGN3213 2009

30/31

PC

IR

ACC

CLOCK

0001

2005 20051004

0001 0001 0002 0002

0000 000A 000A 000A 000B000A

1004 1004

FETCH EXEC FETCH

2005

0002

Figure 20: Expected and GTKWAVE traces of MU0 ACC, IR and PC registers aroundthe execution of the 2005 instruction

seen a little assembly language with PICOBLAZE. and later in the course we will seesome more.

30

8/8/2019 Project ENGN3213 2009

31/31

References

[1] Thomas M. Whitney, France Rode and Chung C. Tung The Powerful Pocketful: anElectronic Calculator Challenges the Slide Rule Hewlett Packard Journal, 1972.

[2] David S. Cochran Algorithms and Accuracy in the HP-35 Hewlett Packard Journal,1972.

[3] M. Ercegovac, T. Lang, and J.H. Moreno Introduction to Digital Systems Wiley,1999.

[4] John F. Wakerly Digital Design: Principles and Practices Prenitce-Hall, 2000.

31