Mabry UG Thesis

8/8/2019 Mabry UG Thesis

1/47

Honors Thesis:

Asynchronous Implementation of 8051 Microcontroller

By: Ryan Mabry

Advisor: Dr. Hao Zheng


2/47

Abstract

The synchronous 8051 microcontroller is a common processor found in many

embedded systems. By using asynchronous design techniques, the performance of the

8051 microcontroller is increased. Through simulation and the use of existing

synchronous design tools in the asynchronous design flow, a four-phase handshaking

approach with a stoppable clock is simulated and then implemented. The asynchronous

architecture added to the existing synchronous architecture includes an ALU wrapper, a

controller wrapper, and a clocking element. The asynchronous design flow consists of

functional simulation, synthesis of synchronous blocks, timing analysis, asynchronous

wrapper design, and timing simulation. After implementation analysis, the asynchronous

8051 is 28.7% faster then the synchronous 8051 while only using 10% more area.

2


3/47

Acknowledgements

I would like to thank Narender Hanchate for devoting a significant amount of his

time in teaching me many of the tools that I used for this project.

I would also like to thank Dr. Hao Zheng for providing me with a thesis

opportunity that allowed me to exercise my hardware engineering design skills.

3


4/47

Table of Contents

Chapter 1: Motivation 5

Chapter 2: Overview and Design 7

Chapter 3:Design Flow 12

Chapter 4:Design Implementation and Results 15

Chapter 5: Challenges and Conclusion 25

Appendix A:Divmul Instructions 27

Appendix B: Controller, RAM, and Trace.out Contents 28

Appendix C:Primetime and Buildgates Script Files 42

Appendix D:ALU and Controller VHDL Code 44

4


5/47

Chapter 1: MotivationOverview

The 8051 microcontroller is a device found in many embedded systems. It can be

found as a component in many analog to digital converters, pulse-width modulators, and

bus interfaces.

The 8051 microcontroller this project uses comes from the University of

Californias Dalton Project.1 The microcontroller design found on the Dalton Project

website is fully synchronous. The goal of this project is to develop an asynchronous

version of the 8051 microcontroller and use synchronous design tools in the process. The

divmul program from the Dalton Project website is used as a benchmark comparison

between the synchronous and asynchronous controllers, and it is also used in verifying

the asynchronous simulation results. The instructions executed by the divmul program

are listed in Appendix A.

Asynchronous Advantages

There are many reasons to implement a design using asynchronous techniques.

Asynchronous designs have the advantages over traditional synchronous designs of lower

power consumption, no clock skew, better technology migration, and less global timing

issues.2 There are numerous ways to implement an asynchronous circuit; these include

fundamental mode Huffman circuits, burst-mode circuits, and Muller circuits.

Asynchronous Disadvantages

While asynchronous circuits may be faster and are not subject to some of the

problems that synchronous circuits suffer from, they are much harder to design. While

there are many tools for synchronous design out on the market, there are no complete

design solution tools for asynchronous circuits. Since there is no global clock in

5


6/47

asynchronous designs, communication must be done through handshaking or other

means. Since there are no tools that automatically implement handshaking protocol

between communicating modules, if an asynchronous circuit makes extensive use of

handshaking or other asynchronous logic, great care must be taken to ensure timing and

data integrity.

Asynchronous Design Flow with Synchronous Tools

Even though complete asynchronous design solutions do not exist, one can make

use of existing synchronous design tools in the asynchronous design flow. In this flow,

each design is partitioned into blocks, and each block is controlled by a local clock or

handshaking protocol. Simulation tools like Modelsim can be used to simulate the

functionality of the asynchronous design. Once the design has been functionally

simulated, it must now be implemented. While an entire asynchronous circuit cannot be

designed in synchronous tools, individual logic blocks can. During the design of the

asynchronous 8051 chip, VHDL was used to generate certain blocks of the ALU and

controller wrappers. While timing analyzers like Primetime are used in the synchronous

design flow to look for timing and critical path violations, they can be used in the

asynchronous design flow to get delay numbers. With delay numbers from leading

commercial timing analyzers, delay elements or a local clock can be implemented.

6


7/47

Chapter 2: Overview and Design

Synchronous 8051 Architecture

I8051_CTR

I8051_DEC

I8051_ALU

I8051_ROM

I8051_RAM

Op-code

ip

Src-1Src-2Src-3

Carry-in 1 & 2

desCarry-out 1 & 2

Overflow

ALU-Op-code

td

addr

data

tdwr

addrIs-bit-addr

dataData-bit

Ports

rst

(Rd, wr, addr, data_out, data_in)

Clock

A block diagram of the synchronous 8051 architecture is shown above. The

controller retrieves data from the I8051_ROM module and sends this data to the

I8051_DEC module, where the data is decoded into an appropriate op-code for the

controller to execute. Depending on the decoded instruction, the I8051_CTR module will

assert and deassert the proper control signals to the I8051_ALU and I8051_RAM

module. During the execution phase of a particular instruction, the I8051_CTR module

will usually read data from the I8051_RAM module, send the fetched data to the

I8051_ALU module for an appropriate logical or arithmetic operation, then write the

results of the ALU operation back into the I8051_RAM module. If the 8051 needs to be

accessed by an external hardware device, such as a memory bus or another

7


8/47

microprocessor, the I8051_CTR and I8051_RAM modules feature ports that can

interface with the device.

8


9/47


10/47

than the required clock period for a division instruction. This functionality is

implemented through handshaking and a stoppable clock.

A block diagram of the asynchronous 8051 architecture is shown on the previous

page. The operation of the asynchronous microcontroller is similar to that of the

synchronous microcontroller, but with a few key differences. Unlike the synchronous

version, the clock is stopped while the I8051_CTR module waits for the I8051_ALU

module to execute a given operation; this is done through handshaking signals generated

by the ALU and Controller wrappers. Second, since the clock is stopped while the

controller waits for data from the ALU, excess cycles that were in the synchronous

version were eliminated in the asynchronous version; excess cycles are defined as clock

cycles where the controller is waiting for the ALU to complete an operation. Third, since

the clock is stopped while the controller waits for a given operation from the ALU to

complete, the clock must be generated onboard the chip, however, in the synchronous

design, the clock is generated off the chip.

The controller wrapper generates a request signal when the controller requests an

operation from the ALU. Upon receiving an acknowledge signal from the ALU wrapper,

the request signal is deasserted by the controller.

The ALU wrapper generates an acknowledge signal to signify that the ALU has

completed the operation requested by the controller. The delay between the time the

ALU wrapper receives the request signal from the controller wrapper and the time the

ALU wrapper acknowledges by asserting the acknowledge signal is dependent upon the

operation requested. The requested operation is determined by the ALU Op-Code.

10


11/47

The clocking unit is used to generate an onboard clock signal for the

asynchronous design. The behavior of the onboard clock is the same as an ordinary

clock, except that the clock is stopped whenever the request line is asserted and the

acknowledge line is deasserted. During this time, the controller is waiting for the ALU to

complete an operation. Once the ALU operation is complete and the ALU wrapper

asserts the acknowledge signal, the clock will resume normal operation.

11


12/47

Chapter 3: Design Flow

Asynchronous Design Flow

Functional Simulation

Synthesis of

Synchronous Blocks

Timing

Analysis

Asynchronous Wrapper

Design

Timing Simulation

One of the objectives of this project is to develop an asynchronous design flow

that utilizes synchronous tools. An overview of each design flow stage and how

synchronous tools are used follows.

The first step in the asynchronous design flow is functional simulation. Modelsim

is used to simulate the asynchronous design. Standard VHDL compilers, like Xilinx ISE,

Altera Quartus II, and NC VHDL, cannot synthesize VHDL code that implements

asynchronous logic. The wrappers for the ALU and controller were written in VHDL

and interfaced with the reduced controller. These wrappers use wait statements to

produce the handshaking logic that is necessary to stop the clock while the ALU

completes a given operation. Verification of the asynchronous controller was done

against the reduced synchronous controller by performing a memory dump at the end of

simulation. The contents of the RAM memory and controller registers were compared

and verified to be the same.

12


13/47

The second step in the asynchronous design flow is the synthesis of synchronous

blocks. In this stage, the synchronous 8051 microcontroller and synchronous elements of

the asynchronous 8051 microcontroller are synthesized and turned into Verilog netlists

by Ambit Buildgates. These netlists are used in later stages of the design flow.

The third step in the asynchronous design flow is timing analysis. In this stage,

Cadence Encounter and Synopsys Primetime are used. Cadence Encounter is used for the

generation of the Resistance-Capacitance model of a circuit. Synopsys Primetime is used

for static timing and critical path analysis. As successive elements of the ALU are

removed to determine the critical path delay for division, multiplication, addition,

subtraction, and logical operations, the RC network model for each case is generated in

Encounter and imported into Primetime to enhance timing accuracy. Critical path

numbers are also generated for the RAM, ROM, decoder, synchronous controller, and

asynchronous controller modules in this stage.

The fourth step in the asynchronous design flow is the design of the asynchronous

wrappers. Since the required delay numbers are obtained in stage four of the design flow

process, the correct number of delay elements can now be implemented in designing the

wrappers. The combinational logic elements of the wrappers are designed in

synthesizable VHDL code that is importable into a schematic, while the delay elements in

the ALU wrapper are laid out by hand in a schematic editor. The schematic editor used

during this project is Cadence Composer.

The fifth step in the asynchronous design flow is timing simulation.

Unfortunately, the asynchronous implementation of the 8051 microcontroller is unable to

13


14/47

be tested since the university does not have a post-synthesis timing simulator installed on

its servers.

14


15/47

Chapter 4: Design Implementation and Results

Handshaking

In the asynchronous implementation of the 8051 microcontroller, the

synchronization between the ALU and controller is implemented through four-phase

handshaking by the use of request and acknowledge signals. When the controller needs

an ALU operation to be done, the request signal is asserted. The acknowledge signal

from the ALU wrapper is then asserted after a given delay period, depending on the ALU

operation requested by the controller. During the period that the request signal is asserted

and the acknowledge signal is deasserted, the clock is stopped. The controllers state

should remain the same as the ALU completes the requested operation. After the

acknowledge signal from the ALU wrapper is asserted, the request signal is deasserted by

the controller wrapper, then a short time later, the acknowledge signal from the ALU

wrapper is also deasserted. A figure showing how such handshaking and clocking works

is given below.

Ack-

Req+Stop Clock

Ack+

Start Clock

Req-

15


16/47

Functional Simulation

The first step towards simulating an asynchronous microcontroller is to

implement its design in VHDL code. The controller is reduced so that it only implements

the instructions executed by the divmul program; the asynchronous controller is further

reduced by removing excess cycles. For example, in the reduced synchronous controller

the NOP instruction takes 7 clock cycles; in the reduced asynchronous controller, the

NOP instruction takes 3 clock cycles.

Wrappers for the ALU and controller are implemented in VHDL to be interfaced

with the asynchronous reduced controller. The controller wrapper consists of VHDL

code that generates a request signal for an appropriate ALU op-code. The ALU wrapper

consists of VHDL code that delays the generation of the acknowledge signal according to

the ALU operation.

Simulation verification in Modelsim consists of two phases. The first phase

compares the memory, registers, and trace.out of the fully synchronous 8051 model and

the asynchronous 8051 model that does not have any excess cycles removed, but does

have ALU and controller wrapper logic inserted. The trace.out file is a recording of each

instruction executed by the controller. As the simulation of both progresses, what is

written to and read from the 8051 RAM module in each clock cycle is dumped into a text

file. After these are verified to be the same, the controller register contents of both

designs are also confirmed to be correct. The trace.out file executed during simulation is

also the same.

The second phase consists of removing excess cycles from the asynchronous 8051

model that had ALU and controller wrapper logic inserted. Instead of comparing what

16


17/47

was written to and read from the 8051 RAM module in each cycle during simulation, a

dump of the RAM contents at the end of simulation is performed. VHDL code is

implemented to perform a dump of controller register contents at the end of simulation.

As excess cycles are removed from the asynchronous controller in each instruction case,

the contents of the RAM, controller registers, and trace.out are verified to be correct.

Appendix B gives the final correct controller register, ALU, and trace.out contents.

ALU Wrapper Design

SelectLogic

ALU

Opcode

2to1

Mux

Logical

Operations

2to1

Mux

Add

Subtract

2to1

Mux

Multiply Divide

S0S1S20 0 0

S0

11 1

S1 S2

Req

Ack

A block diagram showing the ALU wrapper design is given above. The ALU

wrapper operates by selecting an appropriate delay element for a given ALU Op-code.

Signal req to ack connection is delayed for the amount of time it takes for the ALU to

complete the appropriate operation. The select logic takes the ALU Op-code as input and

generates appropriate signals for the select lines that control the multiplexers. The delay

elements for logical operations, addition and subtraction, multiply, and divide are

designed in such a way that the delay of one element builds upon the delay of the

previous element. For example, say logical operations have a delay of 9ns and addition

and subtraction operations have a delay of 12.8ns. The wrapper is designed so that

addition and subtraction delay has to pass through the 9ns delay element of logical

operations; thus, only an additional 3.8ns delay needs to be built into the addition and

subtraction delay element in order to meet the overall delay requirement for addition and

17


18/47

subtraction operations. This same design idea holds for the multiplication and divide

elements. The select logic VHDL code for the ALU wrapper is given in Appendix D.

Primetime is used to calculate the critical path through the ALU. In the

ALU, a virtual clock was created to drive all the inputs; this was necessary since

Primetime wont generate critical path delay numbers without a defined clock. The RC

model for each particular ALU was extracted from Encounter and applied to Primetime

to enhance timing result accuracy.

In calculating ALU delay, successive operations are removed. For example, in

order to calculate multiplication delay, the division case from the ALU VHDL code is

removed, and the critical path delay is assumed to be that of multiplication. This process

continues until delay numbers for logical operations are achieved. Besides the explicit

divide, multiply, add, subtract, and logical operations, there are several ALU operations

that are placed into add or logical operations category based on the function they

performed. For example, the PCSADD ALU op-code is used in calculating address

offsets in jump instructions executed by the controller, and the PCUADD ALU op-code

is used in incrementing the program counter inside the controller; since both op-codes

make use of the addition function, these ALU operations are assumed to be part of the

addition delay.

Initial delay results from Primetime are given below. Since area is also a factor in

delay, the delay must be increased; the ALU decreased in size dramatically from division

to logical operations. In the entire ALU, logical operations may take significantly longer

then 6046ps; the added area from the division and multiplication functionality results in

an increased wire length between the input and output ports. Depending on how the

18


19/47

design is physically implemented on chip, the routing of the wires may impart more delay

then the rise and fall times of the transistors used in the actual logical operations.

ALU Ops Delay(ps)

Division 24675.8Multiplication 10486.1

Subtraction 8579.21

Addition 6310.83

Logical Operations 6046.16

In order to provide a safety margin to account for real world operating conditions

like voltage and temperature fluctuations, 50% of the initial delay is added to the initial

delay numbers. The correct numbers are given below. Since addition and subtraction

account for one delay element in the ALU wrapper, they are lumped together in the table

below.

ALU Ops Delay(ps)

Division 37000

Multiplication 15800

Add & Subtract 12800

Logical Operations 9000

Now that the delay for each stage is set, an appropriate number of buffers had to

be placed in each stage in order to implement the required delay. The buffer unit is found

to have a delay of 110.28ps by itself after Primetime analysis. In order to simplify delay

element design, the buffer was rounded down to a delay of 100ps. The number of buffers

required for each delay element is given below; note that each successive delay element

builds upon the delay of the previous element.

ALU Ops Buffers

Division 213

Multiplication 30

Add & Subtract 38


19


20/47

After implementing the delay elements for division, multiplication, add &

subtract, and logical operations, they are wired together with the select logic block and

multiplexers. The wrapper is then exported into a Verilog netlist and imported into

Primetime to make sure the critical path delay in the wrapper is equal to the delay

required by division. Upon finishing Primetime analysis on the wrapper, it is found the

critical path had a delay of 42688.85ps. The difference in the expected and actual critical

path delay comes from the fact that the average delay of each buffer changed from

110.28ps to 114.28ps, and the buffer delay is simplified to 100ps during the design of the

wrapper. In order to bring the critical path delay closer to required specifications, 50

buffer elements are removed from the division delay element. After removing 50 buffers

from the division delay element, the critical path delay in the ALU wrapper is found to be

36975.75ps, which meets the required specifications. The final number of buffers in each

delay element is given below.

ALU Ops BuffersDivision 163

Multiplication 30

Add & Subtract 38


Controller Wrapper Design

CTR

Wrapper

ALU Op-code

Ack

Req

The design of the controller wrapper is much simpler then the ALU wrapper

design. All the controller wrapper does is assert a request signal while the controller is

20


21/47

waiting for data from an ALU operation; the request signal is deasserted once an

acknowledge signal from the ALU wrapper is received. The controller wrapper is

designed in VHDL code. The code for the controller wrapper can be seen in Appendix D.

Controller Modifications

In the case of the synchronous 8051 controller, the controller must wait an

appropriate number of clock cycles for a given instruction while a given ALU operation

is carried out. However, in the case of the asynchronous controller, these excess cycles

can be removed since the clock is stopped while the ALU is carrying out a requested

operation. For example, the ADDC_1 instruction executed by the controller takes 8

clock cycles in the synchronous version and 6 clock cycles in the asynchronous version.

The VHDL code for the ADDC_1 instruction in the asynchronous 8051 controller is on

the left, and the VHDL code for the ADDC_1 instruction in the synchronous 8051

controller is on the right. In the synchronous version, execute states ES_5 and ES_6 are

excess cycles since the controller is doing nothing while waiting for the ALU to complete

the add operation. In the asynchronous version, the excess cycles ES_5 and ES_6 can be

eliminated since the clock is stopped while the ALU completes the add operation.

when OPC_ADDC_1 => when OPC_ADDC_1 => case exe_state is case exe_state is

when ES_0 => when ES_0 => GET_RAM_ADDR_1(v8); GET_RAM_ADDR_1(v8);

START_RD_RAM(v8); START_RD_RAM(v8);

exe_state

exe_state

alu_op_code


22/47

START_WR_RAM(R_ACC); START_WR_RAM(R_ACC);

reg_cy


23/47

chain in the clocking unit is to modulate the clock period of the design. The inverter gate

at the lower input node to the AND gate in the clocking unit acts to change the clock

from zero to one and vice-versa during normal operation. The delay of this change to the

output clock port is dependant on the inverter chain. The delay in the inverter chain must

be longer than the longest critical path in the RAM, ROM, asynchronous controller, and

decoder modules to avoid timing violations. Since the length of the inverter chain

determines how often the clock will change from zero to one and vice-versa during

normal operation, it is equal to half the period of the clock.

After doing Primetime analysis, the module with the longest critical path in the

asynchronous 8051 is the RAM with a critical path of 20.6ns. Applying a 50% safety

margin to the critical path, a critical path delay of 30.9ns is obtained. Since an inverter

has a delay of 49.96ps, 682 inverters are necessary to create the inverter chain.

Targeted Technology

The asynchronous microcontroller design is targeted towards the standard cell

library developed by the Virginia Tech VLSI for Telecommunications. The VTVT

library is based on the TSMC 0.25u CMOS fabrication process.

Area and Speed

Area numbers were generated by pks_shell and delay numbers are generated in

Primetime. The area of the synchronous version is smaller then the asynchronous version

since the synchronous version does not have an onboard clock generator, ALU wrapper,

or Controller wrapper. The delay is the same in both versions since the RAM module

forms the longest critical path.

23


24/47

The cell area of the synchronous 8051 chip is 65662; the cell area of the

asynchronous chip is approximately 72400. The RAM module dominates the area of

both asynchronous and synchronous chips; this can be expected since the 128 bytes of

memory the 8051 has requires a large number of flip-flops.

The RAM module dominates the critical path delay in the asynchronous and

synchronous 8051 versions with a delay of 20.6ns. Applying a 50% safety margin to this

number, one obtains a critical path delay of approximately 30.9ns. This translates to a

clock period of 30.9ns and an operating frequency of 32.3 MHz for the synchronous and

asynchronous chip during normal operation when the clock is not stopped.

Even though the university lacks a post-synthesis timing simulator, one can gain a

rough estimate of performance by implementing the delay elements in behavioral VHDL

code in Modelsim. While the timing characteristics of each gate are not reflected in

Modelsim, it can model the behavior of the delay elements and asynchronous

handshaking logic through wait forand wait untilstatements. During simulation in

Modelsim, the divmul program took 221,390ns to execute on the synchronous 8051 and

172,030ns to execute on the asynchronous 8051. The asynchronous 8051 is 28.7% faster

than the synchronous 8051 in executing the divmul program.

24


25/47

Chapter 5: Challenges and Conclusion

Challenges

There were several difficulties encountered while designing the

asynchronous 8051 microcontroller. The most significant difficulty came in learning the

different tools that were used in the asynchronous design flow. While learning tools like

Cadence Encounter and Ambit Buildgates, technical assistance from people familiar with

the tools is readily available, however, while learning tools like Synopsys Primetime, the

sole resources available are the Internet and user manuals. By establishing what tools are

necessary for each stage in the asynchronous design flow, a great amount of time could

be saved. During the timing analysis stage of the design flow, Synopsys Primetime,

Design Analyzer, and Timemill are examined, and a large amount of time is spent

learning each tool. Ultimately, only Primetime proves useful in the search for accurate

delay numbers. The time spent learning Design Analyzer and Timemill is better utilized

in the later stages of the asynchronous design flow.

Conclusion

Even though the idea behind handshaking is very simple, it takes a lot of work to

change an existing synchronous design to an asynchronous design. The use of common

synchronous design tools in the asynchronous design flow makes the design of the

asynchronous 8051 microcontroller much easier.

While the asynchronous version is implemented in schematic form, it is

impossible to verify its correctness; no suitable post-synthesis timing simulators are

installed on university servers.

25


26/47

Works Cited

1. Dalton Project. http://www.cs.ucr.edu/~dalton/8051/. University of California,Department of Computer Science, Riverside, CA 92521. 7 April 2005.

2. Scott Hauk, Asynchronous Design Methodologies: An Overview, inProceedings of the IEEE, Vol. 83, No. 1, pp. 69-93, January, 1995.

26
http://www.cs.ucr.edu/~dalton/8051/http://www.cs.ucr.edu/~dalton/8051/


27/47

Appendix A Executed divmul Instructions

ADD A, directADDC A, RnCJNE RN, #data, rel

CLR ADIV ABDNJZ Rn, relINC RnJNZ relLCALL addr16LJMP addr16MOV A, RnMOV A, directMOV Rn, AMOV Rn, direct

MOV Rn, #dataMOV direct, RnMOV direct, directMOV direct, #dataMOV @Ri, AMUL ABORL A, RnRETSJMP relXCH A, RnXCH A, directXRL A, #data

27


28/47

Appendix B Controller, RAM, and Trace.out Contents

Characters after -- are just comments

Controller register contents at end of simulation:

00000 -- reg_pc_15_11000 -- reg_pc_10_801110011 -- reg_pc_7_000101110 -- reg_op111111110 -- reg_op211111110 -- reg_op300000000 -- reg_acc0 -- reg_cy0 -- reg_ac

0 -- reg_f00 -- reg_rs10 -- reg_rs00 -- reg_ov0 -- reg_nu0 -- reg_p

28


29/47

RAM contents at end of simulation:

00000000 -- sfr_b00000000 -- sfr_acc

00000000 -- sfr_psw00000000 -- sfr_ie00000000 -- sfr_ip00001111 -- sfr_sp00000000 -- sfr_dpl00000000 -- sfr_dph00000000 -- sfr_scon00000000 -- sfr_sbuf00000000 -- sfr_tcon00000000 -- sfr_tmod00000000 -- sfr_tl0

00000000 -- sfr_th000000000 -- sfr_tl100000000 -- sfr_th100001010 -- RAM byte 000000000 -- RAM byte 100000000 -- RAM byte 200001101 -- RAM byte 300000000 -- RAM byte 400001101 -- RAM byte 500000000 -- RAM byte 610000010 -- RAM byte 700000000 -- RAM byte 810000110 -- RAM byte 900000000 -- RAM byte 1000001010 -- RAM byte 1100000000 -- RAM byte 1200000100 -- RAM byte 1301001001 -- RAM byte 1400000000 -- RAM byte 1500000000 -- RAM byte 1600000000 -- RAM byte 1700000000 -- RAM byte 1800000000 -- RAM byte 1900000000 -- RAM byte 2000000000 -- RAM byte 2100000000 -- RAM byte 2200000000 -- RAM byte 2300000000 -- RAM byte 2400000000 -- RAM byte 2500000000 -- RAM byte 26

29


30/47

00000000 -- RAM byte 2700000000 -- RAM byte 2800000000 -- RAM byte 2900000000 -- RAM byte 3000000000 -- RAM byte 31

00000000 -- RAM byte 3200000000 -- RAM byte 3300000000 -- RAM byte 3400000000 -- RAM byte 3500000000 -- RAM byte 3600000000 -- RAM byte 3700000000 -- RAM byte 3800000000 -- RAM byte 3900000000 -- RAM byte 4000000000 -- RAM byte 4100000000 -- RAM byte 42

00000000 -- RAM byte 4300000000 -- RAM byte 4400000000 -- RAM byte 4500000000 -- RAM byte 4600000000 -- RAM byte 4700000000 -- RAM byte 4800000000 -- RAM byte 4900000000 -- RAM byte 5000000000 -- RAM byte 5100000000 -- RAM byte 5200000000 -- RAM byte 5300000000 -- RAM byte 5400000000 -- RAM byte 5500000000 -- RAM byte 5600000000 -- RAM byte 5700000000 -- RAM byte 5800000000 -- RAM byte 5900000000 -- RAM byte 6000000000 -- RAM byte 6100000000 -- RAM byte 6200000000 -- RAM byte 6300000000 -- RAM byte 6400000000 -- RAM byte 6500000000 -- RAM byte 6600000000 -- RAM byte 6700000000 -- RAM byte 6800000000 -- RAM byte 6900000000 -- RAM byte 7000000000 -- RAM byte 7100000000 -- RAM byte 72

30


31/47


00000000 -- RAM byte 7800000000 -- RAM byte 7900000000 -- RAM byte 8000000000 -- RAM byte 8100000000 -- RAM byte 8200000000 -- RAM byte 8300000000 -- RAM byte 8400000000 -- RAM byte 8500000000 -- RAM byte 8600000000 -- RAM byte 8700000000 -- RAM byte 88

00000000 -- RAM byte 8900000000 -- RAM byte 9000000000 -- RAM byte 9100000000 -- RAM byte 9200000000 -- RAM byte 9300000000 -- RAM byte 9400000000 -- RAM byte 9500000000 -- RAM byte 9600000000 -- RAM byte 9700000000 -- RAM byte 9800000000 -- RAM byte 9900000000 -- RAM byte 10000000000 -- RAM byte 10100000000 -- RAM byte 10200000000 -- RAM byte 10300000000 -- RAM byte 10400000000 -- RAM byte 10500000000 -- RAM byte 10600000000 -- RAM byte 10700000000 -- RAM byte 10800000000 -- RAM byte 10900000000 -- RAM byte 11000000000 -- RAM byte 11100000000 -- RAM byte 11200000000 -- RAM byte 11300000000 -- RAM byte 11400000000 -- RAM byte 11500000000 -- RAM byte 11600000000 -- RAM byte 11700000000 -- RAM byte 118

31


32/47


00000000 -- RAM byte 12400000000 -- RAM byte 12500000000 -- RAM byte 12600000000 -- RAM byte 127

32


33/47

Trace.out contents at end of simulation

NOPLJMP

MOV 7CLR 1MOV 13DJNZ 1MOV 13DJNZ 1MOV 13DJNZ 1MOV 13DJNZ 1MOV 13

DJNZ 1MOV 13DJNZ 1MOV 13DJNZ 1MOV 13DJNZ 1MOV 13DJNZ 1MOV 13DJNZ 1MOV 13DJNZ 1MOV 13DJNZ 1MOV 13DJNZ 1MOV 13DJNZ 1MOV 13DJNZ 1MOV 13DJNZ 1MOV 13DJNZ 1MOV 13DJNZ 1MOV 13DJNZ 1MOV 13

33


34/47

DJNZ 1MOV 13DJNZ 1MOV 13DJNZ 1

MOV 13DJNZ 1MOV 13DJNZ 1MOV 13DJNZ 1MOV 13DJNZ 1MOV 13DJNZ 1MOV 13


34


35/47




35


36/47




36


37/47




37


38/47



DJNZ 1MOV 13DJNZ 1MOV 13DJNZ 1MOV 13DJNZ 1MOV 13DJNZ 1MOV 13DJNZ 1MOV 13DJNZ 1MOV 13DJNZ 1MOV 12LJMPMOV 12MOV 7CLR 1MOV 5INC 2CJNE 3INC 2CJNE 3MOV 1XRL 4ORL 1JNZINC 2

38


39/47

CJNE 3INC 2CJNE 3MOV 1XRL 4

ORL 1JNZINC 2CJNE 3INC 2CJNE 3MOV 1XRL 4ORL 1JNZINC 2

CJNE 3INC 2CJNE 3MOV 1XRL 4ORL 1JNZINC 2CJNE 3INC 2CJNE 3MOV 1XRL 4ORL 1JNZINC 2CJNE 3INC 2CJNE 3MOV 1XRL 4ORL 1JNZINC 2CJNE 3INC 2CJNE 3MOV 1XRL 4ORL 1

39


40/47

JNZINC 2CJNE 3INC 2CJNE 3

MOV 1XRL 4ORL 1JNZINC 2CJNE 3INC 2CJNE 3MOV 1XRL 4ORL 1

JNZINC 2CJNE 3INC 2CJNE 3MOV 1XRL 4ORL 1JNZINC 2CJNE 3INC 2CJNE 3MOV 1XRL 4ORL 1JNZINC 2CJNE 3INC 2CJNE 3MOV 1XRL 4ORL 1JNZMOV 6LCALLCJNE 3MOV 1MOV 9

40


41/47

DIVMOV 5MOV 6RETMOV 9

MOV 6LCALLCJNE 3MOV 1MOV 9DIVMOV 5MOV 6RETMOV 9MOV 6

LCALLMOV 1MOV 5MOV 9MULMOV 5MOV 1XCH 2XCH 1MULADD 1

41


42/47


43/47

ALU Division Buildgates tcl script file:

read_tlf vtvtlib25.tlfread_lef vtvtlib25.lef

read_vhdl i8051_lib.vhd i8051_alu.vhddo_build_genericset_current_module I8051_ALUdo_optimizewrite_Verilog -hier i8051_ALU_division.vexit

ALU Division Primetime tcl script file:

read_Verilog i8051_ALU_division.vread_db vtvtlib25.db

set link_path "* vtvtlib25.db"link_designcreate_clock -name vclk -period 2 -waveform {0 1}set_input_delay 1 -clock vclk [all_inputs]set_output_delay 1 -clock vclk [all_outputs]set_driving_cell -lib_cell inv_1 [all_inputs]set_load -pin_load 1 [all_outputs]read_parasitics -format SPEF \ I8051_ALU.spefreport_timing > timing.txt

43


44/47

Appendix D ALU and Controller VHDL Code

ALU wrapper select logic VHDL code:

library IEEE;

use IEEE.STD_LOGIC_1164.all;

use IEEE.STD_LOGIC_ARITH.all;use WORK.I8051_LIB.all;

entity ALU_wrapper isport(

alu_op_code : in UNSIGNED(3 downto 0)select0 : out std_logic;

select1 : out std_logic;select2 : out std_logic; );

end ALU_wrapper;

architecture BEHAVIORAL of ALU_wrapper is

begin

process(alu_op_code)begin

CASE alu_op_code ISWHEN ALU_OPC_NONE =>

select0


45/47

WHEN ALU_OPC_XOR =>

select0


46/47

Controller Wrapper VHDL Code:

library IEEE;

use IEEE.STD_LOGIC_1164.all;use IEEE.STD_LOGIC_ARITH.all;

use WORK.I8051_LIB.all;

entity CTR_wrapper isport(

alu_op_code : in UNSIGNED(3 downto 0);

ack : in std_logic;

req : out std_logic);end CTR_wrapper;

architecture BEHAVIORAL of CTR_wrapper is

beginprocess(alu_op_code, ack)

beginif ack = '1' then

req

req

req

req

req

req

req

req

req

req

req

req

req req

req

req

req

req


47/47

END CASE;

END IF;

END PROCESS;END BEHAVIORAL;

Date post:	10-Apr-2018
Category:	Documents
Upload:	deepak-mishra
View:	219 times
Download:	0 times

Mabry UG Thesis

Documents