Honor’s Thesis:

Asynchronous Implementation of 8051 Microcontroller

By: Ryan Mabry

Advisor: Dr. Hao Zheng

 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
 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
 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
 Chapter 1: Motivation
Overview

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

California’s 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
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
 Chapter 2: Overview and Design
Synchronous 8051 Architecture
Clock

rst

td
Op-code
addr
I8051_DEC I8051_ROM
ip
data

I8051_CTR
Src-1 td
Src-2 wr
I8051_ALU Src-3 addr
Carry-in 1 & 2 Is-bit-addr I8051_RAM
des data
Data-bit
Carry-out 1 & 2
Overflow
ALU-Op-code

(Rd, wr, addr, data_out, data_in) Ports

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
microprocessor, the I8051_CTR and I8051_RAM modules feature ports that can

interface with the device.

8
Asynchronous 8051 Architecture

rst

td
Op-code
addr
I8051_DEC I8051_ROM
ip
data

I8051_CTR
Src-1 td
Src-2 wr
I8051_ALU Src-3 addr
Carry-in 1 & 2 Is-bit-addr I8051_RAM
des data
Data-bit
Carry-out 1 & 2
Overflow
ALU-Op-code

req
ALU CTR
Wrapper ack Wrapper

Clock Clocking
(Rd, wr, addr, data_out, data_in) Ports
Element

In the case of designing the asynchronous 8051 microcontroller, handshaking

between the ALU and controller is implemented along with a stoppable clock; while the

controller waits for the ALU to complete an operation, the clock is stopped.

In the synchronous version of the 8051 microcontroller, the ALU is the major

source of delay within the chip. RAM reads and writes and controller state transitions

occur much faster than an ALU division operation. The clock period in the synchronous

8051 microcontroller must be longer than the worst-case delay, which is the time needed

to execute ALU division. While most instructions take less time to execute than a

division instruction, the clock period must be long enough in every cycle to ensure that

no data or timing errors occur whenever a division instruction is executed. In the

asynchronous version of the chip, the clock period is dependent on the executed

instruction. For example, the clock period required for an add instruction is much less

9
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
 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
 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
 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
be tested since the university does not have a post-synthesis timing simulator installed on

its servers.

14
 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 controller’s 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.

Req+
Stop Clock

Ack+
Ack-
Start Clock

Req-

15
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
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

Req
ALU
Opcode Select
Logical Add
Logic Multiply Divide
O perations Subtract

S2 S1 S0
0 0 0
2to1 2to1 2to1 Ack
1 Mux Mux Mux
1 1
S0 S1 S2

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
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 won’t 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
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.8
Multiplication 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
Logical Operations 90

19
 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 Buffers

Division 163
Multiplication 30
Add & Subtract 38
Logical Operations 90

Controller Wrapper Design

ALU Op-code
CTR Req
Ack Wrapper

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
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
when ES_0 =>
GET_RAM_ADDR_1(v8);
START_RD_RAM(v8);
exe_state <= ES_1;
when ES_1 =>
exe_state <= ES_2;
when ES_2 =>
alu_op_code <= ALU_OPC_ADD;
alu_src_1 <= reg_acc;
alu_src_2 <= ram_in_data;
alu_src_cy <= reg_cy;
exe_state <= ES_3;
when ES_3 =>
ram_out_data <= alu_des_1;
case exe_state is
when ES_0 =>
GET_RAM_ADDR_1(v8);
START_RD_RAM(v8);
exe_state <= ES_1;
when ES_1 =>
exe_state <= ES_2;
when ES_2 =>
alu_op_code <= ALU_OPC_ADD;
alu_src_1 <= reg_acc;
alu_src_2 <= ram_in_data;
alu_src_cy <= reg_cy;
exe_state <= ES_3;
when ES_3 =>
ram_out_data <= alu_des_1;

21
 START_WR_RAM(R_ACC); START_WR_RAM(R_ACC);
reg_cy <= alu_des_cy; reg_cy <= alu_des_cy;
reg_ac <= alu_des_ac; reg_ac <= alu_des_ac;
reg_ov <= alu_des_ov; reg_ov <= alu_des_ov;
exe_state <= ES_4; exe_state <= ES_4;
when ES_4 => when ES_4 =>
GET_PSW(v8); GET_PSW(v8);
ram_out_data <= v8; ram_out_data <= v8;
START_WR_RAM(R_PSW); START_WR_RAM(R_PSW);
exe_state <= ES_7; exe_state <= ES_5;
when ES_7 => when ES_5 =>
SHUT_DOWN_ALU; exe_state <= ES_6;
cpu_state <= CS_1; when ES_6 =>
exe_state <= ES_0; exe_state <= ES_7;
when others => when ES_7 =>
null; SHUT_DOWN_ALU;
end case; cpu_state <= CS_1;
exe_state <= ES_0;
end case;
RAM reads take 2 clock cycles and RAM writes take 1 clock cycle in both

synchronous and asynchronous controller versions.

Clocking Unit
req
ack
Clock
...
Inverter Chain

A diagram for the clocking unit design is shown above. Unlike the synchronous

8051 chip, the asynchronous 8051 chip must have its clock generated onboard because

the clock must be stopped and started by the handshaking signals from the ALU and

controller wrappers. The clocking element takes the request and acknowledge lines from

the two wrappers as inputs. The clock is stopped when signal req is 1 and signal ack is 0.

Signal req is asserted when the controller is waiting for the ALU to complete an

operation, and signal ack is asserted when the ALU has completed the requested

operation. Whenever the request and acknowledge lines are not one and zero at the same

time, the clock operates as any synchronous clock would. The purpose of the inverter

22
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
 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 for and wait until statements. 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
 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
 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,” in

Proceedings of the IEEE, Vol. 83, No. 1, pp. 69-93, January, 1995.

26
Appendix A – Executed divmul Instructions
ADD A, direct
ADDC A, Rn
CJNE RN, #data, rel
CLR A
DIV AB
DNJZ Rn, rel
INC Rn
JNZ rel
LCALL addr16
LJMP addr16
MOV A, Rn
MOV A, direct
MOV Rn, A
MOV Rn, direct
MOV Rn, #data
MOV direct, Rn
MOV direct, direct
MOV direct, #data
MOV @Ri, A
MUL AB
ORL A, Rn
RET
SJMP rel
XCH A, Rn
XCH A, direct
XRL A, #data

27
Appendix B – Controller, RAM, and Trace.out Contents

Characters after “--“ are just comments

Controller register contents at end of simulation:

00000 -- reg_pc_15_11
000 -- reg_pc_10_8
01110011 -- reg_pc_7_0
00101110 -- reg_op1
11111110 -- reg_op2
11111110 -- reg_op3
00000000 -- reg_acc
0 -- reg_cy
0 -- reg_ac
0 -- reg_f0
0 -- reg_rs1
0 -- reg_rs0
0 -- reg_ov
0 -- reg_nu
0 -- reg_p

28
RAM contents at end of simulation:

00000000 -- sfr_b
00000000 -- sfr_acc
00000000 -- sfr_psw
00000000 -- sfr_ie
00000000 -- sfr_ip
00001111 -- sfr_sp
00000000 -- sfr_dpl
00000000 -- sfr_dph
00000000 -- sfr_scon
00000000 -- sfr_sbuf
00000000 -- sfr_tcon
00000000 -- sfr_tmod
00000000 -- sfr_tl0
00000000 -- sfr_th0
00000000 -- sfr_tl1
00000000 -- sfr_th1
00001010 -- RAM byte 0
00000000 -- RAM byte 1
00000000 -- RAM byte 2
00001101 -- RAM byte 3
00000000 -- RAM byte 4
00001101 -- RAM byte 5
00000000 -- RAM byte 6
10000010 -- RAM byte 7
00000000 -- RAM byte 8
10000110 -- RAM byte 9
00000000 -- RAM byte 10
00001010 -- RAM byte 11
00000000 -- RAM byte 12
00000100 -- RAM byte 13
01001001 -- RAM byte 14
00000000 -- RAM byte 15
00000000 -- RAM byte 16
00000000 -- RAM byte 17
00000000 -- RAM byte 18
00000000 -- RAM byte 19
00000000 -- RAM byte 20
00000000 -- RAM byte 21
00000000 -- RAM byte 22
00000000 -- RAM byte 23
00000000 -- RAM byte 24
00000000 -- RAM byte 25
00000000 -- RAM byte 26

29
00000000 -- RAM byte 27
00000000 -- RAM byte 28
00000000 -- RAM byte 29
00000000 -- RAM byte 30
00000000 -- RAM byte 31
00000000 -- RAM byte 32
00000000 -- RAM byte 33
00000000 -- RAM byte 34
00000000 -- RAM byte 35
00000000 -- RAM byte 36
00000000 -- RAM byte 37
00000000 -- RAM byte 38
00000000 -- RAM byte 39
00000000 -- RAM byte 40
00000000 -- RAM byte 41
00000000 -- RAM byte 42
00000000 -- RAM byte 43
00000000 -- RAM byte 44
00000000 -- RAM byte 45
00000000 -- RAM byte 46
00000000 -- RAM byte 47
00000000 -- RAM byte 48
00000000 -- RAM byte 49
00000000 -- RAM byte 50
00000000 -- RAM byte 51
00000000 -- RAM byte 52
00000000 -- RAM byte 53
00000000 -- RAM byte 54
00000000 -- RAM byte 55
00000000 -- RAM byte 56
00000000 -- RAM byte 57
00000000 -- RAM byte 58
00000000 -- RAM byte 59
00000000 -- RAM byte 60
00000000 -- RAM byte 61
00000000 -- RAM byte 62
00000000 -- RAM byte 63
00000000 -- RAM byte 64
00000000 -- RAM byte 65
00000000 -- RAM byte 66
00000000 -- RAM byte 67
00000000 -- RAM byte 68
00000000 -- RAM byte 69
00000000 -- RAM byte 70
00000000 -- RAM byte 71
00000000 -- RAM byte 72

30
00000000 -- RAM byte 73
00000000 -- RAM byte 74
00000000 -- RAM byte 75
00000000 -- RAM byte 76
00000000 -- RAM byte 77
00000000 -- RAM byte 78
00000000 -- RAM byte 79
00000000 -- RAM byte 80
00000000 -- RAM byte 81
00000000 -- RAM byte 82
00000000 -- RAM byte 83
00000000 -- RAM byte 84
00000000 -- RAM byte 85
00000000 -- RAM byte 86
00000000 -- RAM byte 87
00000000 -- RAM byte 88
00000000 -- RAM byte 89
00000000 -- RAM byte 90
00000000 -- RAM byte 91
00000000 -- RAM byte 92
00000000 -- RAM byte 93
00000000 -- RAM byte 94
00000000 -- RAM byte 95
00000000 -- RAM byte 96
00000000 -- RAM byte 97
00000000 -- RAM byte 98
00000000 -- RAM byte 99
00000000 -- RAM byte 100
00000000 -- RAM byte 101
00000000 -- RAM byte 102
00000000 -- RAM byte 103
00000000 -- RAM byte 104
00000000 -- RAM byte 105
00000000 -- RAM byte 106
00000000 -- RAM byte 107
00000000 -- RAM byte 108
00000000 -- RAM byte 109
00000000 -- RAM byte 110
00000000 -- RAM byte 111
00000000 -- RAM byte 112
00000000 -- RAM byte 113
00000000 -- RAM byte 114
00000000 -- RAM byte 115
00000000 -- RAM byte 116
00000000 -- RAM byte 117
00000000 -- RAM byte 118

31
00000000 -- RAM byte 119
00000000 -- RAM byte 120
00000000 -- RAM byte 121
00000000 -- RAM byte 122
00000000 -- RAM byte 123
00000000 -- RAM byte 124
00000000 -- RAM byte 125
00000000 -- RAM byte 126
00000000 -- RAM byte 127

32
Trace.out contents at end of simulation

NOP
LJMP
MOV 7
CLR 1
MOV 13
DJNZ 1
MOV 13
DJNZ 1
MOV 13
DJNZ 1
MOV 13
DJNZ 1
MOV 13
DJNZ 1
MOV 13
DJNZ 1
MOV 13
DJNZ 1
MOV 13
DJNZ 1
MOV 13
DJNZ 1
MOV 13
DJNZ 1
MOV 13
DJNZ 1
MOV 13
DJNZ 1
MOV 13
DJNZ 1
MOV 13
DJNZ 1
MOV 13
DJNZ 1
MOV 13
DJNZ 1
MOV 13
DJNZ 1
MOV 13
DJNZ 1
MOV 13
DJNZ 1
MOV 13

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

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

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

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

37
DJNZ 1
MOV 13
DJNZ 1
MOV 13
DJNZ 1
MOV 13
DJNZ 1
MOV 13
DJNZ 1
MOV 13
DJNZ 1
MOV 13
DJNZ 1
MOV 13
DJNZ 1
MOV 13
DJNZ 1
MOV 13
DJNZ 1
MOV 13
DJNZ 1
MOV 13
DJNZ 1
MOV 13
DJNZ 1
MOV 13
DJNZ 1
MOV 13
DJNZ 1
MOV 13
DJNZ 1
MOV 12
LJMP
MOV 12
MOV 7
CLR 1
MOV 5
INC 2
CJNE 3
INC 2
CJNE 3
MOV 1
XRL 4
ORL 1
JNZ
INC 2

38
CJNE 3
INC 2
CJNE 3
MOV 1
XRL 4
ORL 1
JNZ
INC 2
CJNE 3
INC 2
CJNE 3
MOV 1
XRL 4
ORL 1
JNZ
INC 2
CJNE 3
INC 2
CJNE 3
MOV 1
XRL 4
ORL 1
JNZ
INC 2
CJNE 3
INC 2
CJNE 3
MOV 1
XRL 4
ORL 1
JNZ
INC 2
CJNE 3
INC 2
CJNE 3
MOV 1
XRL 4
ORL 1
JNZ
INC 2
CJNE 3
INC 2
CJNE 3
MOV 1
XRL 4
ORL 1

39
JNZ
INC 2
CJNE 3
INC 2
CJNE 3
MOV 1
XRL 4
ORL 1
JNZ
INC 2
CJNE 3
INC 2
CJNE 3
MOV 1
XRL 4
ORL 1
JNZ
INC 2
CJNE 3
INC 2
CJNE 3
MOV 1
XRL 4
ORL 1
JNZ
INC 2
CJNE 3
INC 2
CJNE 3
MOV 1
XRL 4
ORL 1
JNZ
INC 2
CJNE 3
INC 2
CJNE 3
MOV 1
XRL 4
ORL 1
JNZ
MOV 6
LCALL
CJNE 3
MOV 1
MOV 9

40
DIV
MOV 5
MOV 6
RET
MOV 9
MOV 6
LCALL
CJNE 3
MOV 1
MOV 9
DIV
MOV 5
MOV 6
RET
MOV 9
MOV 6
LCALL
MOV 1
MOV 5
MOV 9
MUL
MOV 5
MOV 1
XCH 2
XCH 1
MUL
ADD 1

41
Appendix C – Sample Primetime and Buildgates script files

Synchronous Controller Buildgates tcl script file:

read_tlf vtvtlib25.tlf
read_lef vtvtlib25.lef
read_vhdl i8051_lib.vhd i8051_ctr.vhd
do_build_generic
set_current_module I8051_CTR
do_optimize
write_Verilog -hier synch_controller_netlist.v
exit

Synchronous Controller Primetime tcl script file:

read_Verilog synch_controller_netlist.v
read_db vtvtlib25.db
set link_path "* vtvtlib25.db"
link_design
create_clock -name clk -period 2 -waveform {0 1} [get_ports clk]
set nonclock_inputs [remove_from_collection [all_inputs] [get_ports clk]]
set_input_delay 1 -clock clk $nonclock_inputs
set_output_delay 1 -clock clk [all_outputs]
set_driving_cell -lib_cell inv_1 [all_inputs]
set_load -pin_load 1 [all_outputs]
read_parasitics -format SPEF \ I8051_CTR.spef
report_timing > timing.txt

42
ALU Division Buildgates tcl script file:

read_tlf vtvtlib25.tlf
read_lef vtvtlib25.lef
read_vhdl i8051_lib.vhd i8051_alu.vhd
do_build_generic
set_current_module I8051_ALU
do_optimize
write_Verilog -hier i8051_ALU_division.v
exit

ALU Division Primetime tcl script file:

read_Verilog i8051_ALU_division.v
read_db vtvtlib25.db
set link_path "* vtvtlib25.db"
link_design
create_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.spef
report_timing > timing.txt

43
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 is
port(
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 IS
WHEN ALU_OPC_NONE =>
select0 <= '1';
select1 <= '1';
select2 <= '1';
WHEN ALU_OPC_ADD =>
select0 <= '0';
select1 <= '1';
select2 <= '1';
WHEN ALU_OPC_SUB =>
select0 <= '0';
select1 <= '1';
select2 <= '1';
WHEN ALU_OPC_MUL =>
select0 <= '0';
select1 <= '0';
select2 <= '1';
WHEN ALU_OPC_DIV =>
select0 <= '0';
select1 <= '0';
select2 <= '0';
WHEN ALU_OPC_DA =>
select0 <= '0';
select1 <= '1';
select2 <= '1';
WHEN ALU_OPC_NOT =>
select0 <= '1';
select1 <= '1';
select2 <= '1';
WHEN ALU_OPC_AND =>
select0 <= '1';
select1 <= '1';
select2 <= '1';

44
 WHEN ALU_OPC_XOR =>
select0 <= '1';
select1 <= '1';
select2 <= '1';
WHEN ALU_OPC_OR =>
select0 <= '1';
select1 <= '1';
select2 <= '1';
WHEN ALU_OPC_RL =>
select0 <= '1';
select1 <= '1';
select2 <= '1';
WHEN ALU_OPC_RLC =>
select0 <= '1';
select1 <= '1';
select2 <= '1';
WHEN ALU_OPC_RR =>
select0 <= '1';
select1 <= '1';
select2 <= '1';
WHEN ALU_OPC_RRC =>
select0 <= '1';
select1 <= '1';
select2 <= '1';
WHEN ALU_OPC_PCSADD =>
select0 <= '0';
select1 <= '1';
select2 <= '1';
WHEN ALU_OPC_PCUADD =>
select0 <= '0';
select1 <= '1';
select2 <= '1';
WHEN others =>
select0 <= '1';
select1 <= '1';
select2 <= '1';
END CASE;
END PROCESS;
END BEHAVIORAL;

45
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 is
port(
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

begin
process(alu_op_code, ack)
begin
if ack = '1' then
req <= '0';
else
CASE alu_op_code IS
WHEN ALU_OPC_NONE =>
req <= '0';
WHEN ALU_OPC_ADD =>
req <= '1';
WHEN ALU_OPC_SUB =>
req <= '1';
WHEN ALU_OPC_MUL =>
req <= '1';
WHEN ALU_OPC_DIV =>
req <= '1';
WHEN ALU_OPC_DA =>
req <= '1';
WHEN ALU_OPC_NOT =>
req <= '1';
WHEN ALU_OPC_AND =>
req <= '1';
WHEN ALU_OPC_XOR =>
req <= '1';
WHEN ALU_OPC_OR =>
req <= '1';
WHEN ALU_OPC_RL =>
req <= '1';
WHEN ALU_OPC_RLC =>
req <= '1';
WHEN ALU_OPC_RR =>
req <= '1';
WHEN ALU_OPC_RRC =>
req <= '1';
WHEN ALU_OPC_PCSADD =>
req <= '1';
WHEN ALU_OPC_PCUADD =>
req <= '1';
WHEN others =>
req <= '0';

46
 END CASE;
END IF;
END PROCESS;
END BEHAVIORAL;

47