The document describes a project to design a microcontroller that supports the instruction set of the Motorola 68HC12 microcontroller using VHDL. Key aspects of the project include: - Implementing the 68HC12 instruction set and addressing modes on an FPGA. - Testing the design through simulation, synthesis, place and route, and finally programming the designed FPGA board. - Verifying the results by comparing the functionality to the original 68HC12 microcontroller board.

1. Presenting:
Yehezkel Padael & Netanel Levy
Instructor: Mr. Uri Stroh

2.  Designing a microcontroller which supports the
instruction set of 68HC12, using VHDL.
 Successfully implementing the design on Xilinx
FPGA .
 Testing of the design using simulations, before
and after place-and-route, and finally burning
and testing of the design on the FPGA. The
tests will be written in Assembly and then C.
 Matching the testing results from our design to
an original Motorola’s 68HC12 board.

3. CPU12 Features
 The CPU12 is a high-speed, 16-bit processing
unit.
 68HC11 source code is accepted by CPU12
assemblers with no changes.
 The CPU12 allows instructions with odd byte
counts, including single-byte instructions.
 The CPU12 offers an extensive set of indexed
addressing capabilities including:
 Using the SP as an index register in all indexed
operations.
 Using the PC as an index register in all but auto
inc/dec mode.
 In-detail about indexed addressing up ahead.

4. Instruction Set
 In 68HC12 family there are
206 different instructions.
 Many instructions have
different addressing modes.
Each addressing mode has a
unique opcode (all IDX has
one opcode). There are 309
opcodes overall.
 The instructions are consisted
of 1-6 bytes:
 1 or 2 bytes of opcode.
 The rest is data for a
specific operation.
 Maximum and
minimum.
 Jump and
subroutine.
 Branch.
 Index manipulation.
 Stacking.
 Condition code.
 Null.
 Interrupt.
 Fuzzy logic.
 Multiply and
accumulate.
 Table and
interpolation.
 Background, stop
and wait.
 Load and store.
 Transfer and
exchange.
 Move.
 Addition and
subtraction.
 BCD (Binary Coded
Decimal).
 Decrement and
increment.
 Compare and test.
 Boolean logic.
 Clear, complement and
negate.
 Multiplication and
division.
 Bit test and
manipulation.
 Shift and rotate.
 The CPU12 supports many
instructions:

6. There are six addressing modes all-in-all:
 Inherent (INH) – this addressing mode uses only CPU
registers, if any, as operands. No memory access is needed.
 Immediate (IMM) – operands are included in the instruction
stream. The data must be preceded by ‘#’ symbol, which
indicates explicit data for the assembler.
 Direct (DIR) – operand is the lower 8-bits of an address in
the range $0000-$00FF (‘$’ indicates an address).
 Extended (EXT) – operand is a 16-bit address.
 Relative (REL) – operand is an offset, relative to the PC
register. Can be either 8 or 16-bit. Used only for branch
instructions.
 Indexed (IDX) – explanation in detail follows…
Addressing Mode

7. Registers – An Overview
 All-in-all the CPU has seven registers:
 A, B, (D), X, Y, SP, PC and CCR.
 A and B 8-bit accumulators, are general purpose registers. They are
used for holding operands and results of operations. Some
instructions use the combination of the both as a 16-bit accumulator
D (A:B).
 X and Y are 16-bit registers. They are used for indexed addressing
mode operations.
 SP (Stack Pointer) is used to save system context during subroutine
calls. It can also be used as a temporary storage place. Initially SP
points to 0x0BFF.
 PC (Program Counter) is the register which holds the address for
the next instruction. It can be incremented by byte or two, or by
relative address.
 CCR (Condition Code Register) contains status bits. It is used
mostly for branch instructions, based on a previous operation.

8. Condition Code Register
 S – Stop disable bit. Setting S disables “STOP” instruction.
 X – XIRQ interrupt mask bit. Masks interrupt request from XIRQ pin
when set.
 H – Half carry flag. Used in BCD arithmetic operation. Set if a carry
is produced from bit 3.
 I – Interrupt mask bit. When set, disables maskable interrupt
sources.
 N – Negative flag. Set when result is less than 0.
 Z – Zero flag. Set when result is 0.
 V – Two’s complement overflow flag. Set when two’s complement
overflow occurs.
 C – Carry/Borrow flag. Set when an addition or subtraction
operation produces a carry or borrow.

9. Memories
 There are three memories in the designed
architecture:
 Program memory – used for program code
storage. located at $F000-$FFFF.
 Register memory. Registers located at $0000-
$01FF.
 General memory. RAM located at $0800-$0BFF.
Generated by Coregen.

10. Program Memory (PM)
 As mentioned before, the CPU is 16-bit
processing unit. Thus, the PM has to output
16-bits for each cycle.
 On the other side, it has to be able to handle
odd-bytes instructions – it must be capable of
stepping by one byte in many cases.
 Having this in mind, the architecture was
planned accordingly.

11. Register Memory
 Contains control registers
which define attributes and
functioning of the CPU.
 For example:
 DDRA ($0002) – sets pins of
port A as inputs or outputs.
 The majority of the registers
were not needed for our tests.
Therefore weren’t
implemented.
 If necessary, required
registers can easily be added
to our design.
 Each register is defined by
address and reset value of its
own. The implementation was
done with a generic
component.

13. Memories Control
 In order to be able to
use memory-
instructions well, it is
needed to be able to
refer to each memory
with no special
treatment.
 For that purpose a
comparator was built
which allows the
appropriate enable
pass according to a
received address.

14. Package
 Constants were defined.
 When reading a file, words are far more
understandable then numbers.
 Changes in vector size of signals used in various
locations are made only from the package.
 Procedures were defined for better
organization.
 Function for std_logic_vector-to-string[1].

15.  The control is built as Microcode.
 All-in-all there are 61 bits for each instruction in
the control’s ROM. The next address is
determined by 10 bits.
 The IDX component also has its own next
address pointer.
 Few bits determine where to take the next
address from (R, ROM, IDX).
 When an instruction uses IDX addressing mode,
the next address from the ROM is written to R
register. When the IDX instruction is finished, the
next address is fetched from R.
Control Unit

16. The ROM
 The ROM contains all the control bits, for
each instruction. First, the bits were set
separately and deliberately into an excel
sheet.
 From the excel, the file was saved in CSV
format.
 The CSV file is manipulated by a script, which
produces a text file that meets the restrictions
of Xilinx's Coregen.
 According to our settings and the produced
file, Coregen outputs the ROM’s VHDL file,
ready to be used.

17. About Programs –
Coregen
 This program is provided by Xilinx. It was
used for generating components. The three
components generated are:
 ROM for the control unit.
 RAM for general purpose memory.
 DIV components for divide operations.
 Coregen generates two important files:
 A VHDL file – used for simulation. The
synthesize program ignores this file (as
prompted in the file).
 A NGC (neglect) file – used for P & R.

18.  There are six different indexed addressing
modes:
 5-bit offset – 5-bit signed constant offset from
X, Y, SP or PC.
 Pre/Post increment/decrement.
 9/16 -bit offset.
 Indirect 16-bit offset – pointer to operand is
found at 16-bit constant offset from X, Y, SP or
PC.
 Accumulator offset using A, B or D.
 Indirect D accumulator offset – offset is found
in D.
IDX

19. Approaching –
Indexed Addressing Mode (IDX)
 When approaching IDX
addressing mode, we
encountered a problem.
Almost every instruction has
at least one IDX addressing
mode. Adding each IDX into
the excel seemed inefficient.
Furthermore, all IDX
operations share the same
opcode per instruction,
which makes the idea of
changing only the excel
almost impossible.
 Thus, the decision was to
make an independent
component for IDX. The
component detects the exact
kind of IDX to be executed.
 When an indexed addressing
mode instruction is initiated,
the IDX component “takes
control” while saving the
last address in R. Some of
the control bits, including
enable, select and the next
address, come from the IDX
rather than the ROM.
 At the last cycle of the IDX,
the effective address is
saved in a designated
register. The data stored in
the memory at the effective
address is also read out. This
was done in order to shorten
many instructions( by one
cycle).
 When the IDX part is done,
the last address is read from

20. Each address contains
different instruction code
and the next address.
Opcodes pass through some
logic, which leads to the right
address in the ROM
The next address is
fetched, either from the
ROM, R register or the
IDX component.
Each cycle, the
appropriate stream of bits
is sent out to the system.

21. Arithmetic Logic Unit (ALU)
 The ALU performs
arithmetic and logical
operations. It is the most
sophisticated computing
component in our design.
 The operation to be done is
chosen according to
ALU_op.
 Some operations affect the
CCR register.
 It also decides whether to
branch or not, according to

25. Windows && Linux
 The work was performed on two computers –
Windows (laptop) and Linux (project comp).
 Windows’s main advantage is its compatibility with
many programs that wouldn’t work on Linux such
as MiniIDE, ICCV7 and Office.
 In Linux was used for shell-script. Also, a remote
connection is possible, which allows us to work
from any place with internet connection. Programs
used: Putty, Xming and TightVNC Viewer.
 A connection was established between the two
using an SCP client (WinSCP). That way we could
work simultaneously on files located in Linux.

26. Backup
 In big projects, it is very important to backup all
our work, in case of data loss.
 For that purpose a net service was used,
provided by assembla[2].
 Each member of the project can update and
commit files of any kind to the project.
 All sub-versions (SVN) are saved and stored
in-site.
 All files can be easily compared to
previous versions in-site (diff).

27. Reference Board
 68HC812A4 microcontroller
 90 I/O lines
 8-channel, 8-bit analog-to-digital converter
 4K EEPROM and 1K RAM on-chip
 includes both RS232 and RS485
interfaces, usable simultaneously
 primary 50-pin connector for dedicated I/O
 secondary 50-pin connector for additional
I/O or expanded mode memory bus
 4-pin and universal 6-pin/10-pin BDM
connectors support BDM pods from
multiple vendors
 program in C, BASIC, or assembler
 256-byte firmware bootloader provides
convenient downloading via RS232 serial
port
 fully compatible with third-party
assemblers, compilers, and BDM pods

28. About Spartan 3E
 Xilinx Spartan-3E FPGA,
500K gate
 USB2 port providing board
power, device configuration,
and high-speed data transfers
 16MB fast Micron PSDRAM
 16MB Intel StrataFlash Flash
R
 Xilinx Platform Flash ROM
 50MHz oscillator
 75 FPGA I/O’s routed to
expansion connectors (one
high-speed Hirose FX2
connector with 43 signals and
four 2x6 Pmod connectors)
 On-board I/O includes eight
LEDs, four-digit seven-
segment display, four
pushbuttons, eight slide
switches

29. Scripts
 Scripts help us do
necessary work, that
would take a lot more
time without them.
 A well-done script saves
us many small mistakes.
 On a routine work, it is a
must. We couldn’t finish
the project without them.
 The scripts were done in
Python language, all
except one, which is
Linux shell-script.
 A script called “mani”, is
responsible for
manipulating the CSV file
mentioned above.
 First, it checks the file for
errors like missing bits,
then it produces a COE file
for Coregen.
 Next, it activates Coregen
and generates a ROM with
a pre-defined settings for
the design.
 It also copies all necessary
files to a specified location,
and updates few files with
the ROM properties.
 A script called
“PM_maker”, is
responsible for
manipulating S19 file of
a compiled program and
converts it to a Program
Memory VHDL file,
according to our design.
 A script called “test”, is
responsible for running
all the tests made on
Modelsim and checking
of the simulations
results.
 Besides the S19 file, the
C compiler also
produces a LST file,
which contains the
assembly commands.
 A script called “cover”, is
responsible for
counting the number
of unique instructions
used in each program.
 A script called “burn”, is
responsible for burning
the design of on the
FPGA.
 First, it run a synthesize
of the design and then
Place & Route. All the
setting are predefined.
 Finally, after a Bitstream
file is ready, it burns it
into our board,
assuming it is already
connected to the
computer.

30. The testing process –
the Program
 Two programs were used for compiling: MGTEK
MiniIDE – used for compiling assembly.
 ICCV7 for CPU12 – used for C programs.
 Each compiler produces a S19 file. S19 file
contains addresses and corresponding data.
 In some cases, programs debugging was done
using NoICE for 68HC12 debugger.
 A script was made (with python) in order to
manipulate the S19 file and make a fitting PM,
according to our design.

31. The testing process –
Simulation
 compilation and simulation
of VHDL files was done
using ModelSim.
 The majority of the
debugging was done
using this program.
 In order to quicken the
testing process, a DO file
was created for auto
compilation and waveform
configuration.
 ASSERT command was
used to report IDX
operations and also for
outputting PORTA’s value to
ModelSim’s transcript.
 For easier debugging we
used signal-spy to detect

32. The testing process –
Synthesize
 Done with Precision. It generates a netlist and
constraints files for P & R. It also produces
some important reports regarding our design.
 Two of the most important ones are timing and
area reports.

33. The testing process –
P & R, Simulation and Burn
 Next, settings and connections in Xilinx’s ISE are
defined. Place & Route is run on the design and a
last simulation is performed. Hopefully everything
is still working.
 Various reports are generated such as pad, timing
and area reports.
 In the process of synthesizing the design, a
Bitstream file is generated. This file has all the
data needed in order to burn-in the design.
 Finally the data is burned to our FPGA and
compare the results with the scope.

34. The testing process –
Summary
VHDL
Simulation
(Modelsim)
Synthesize
(Precision)
Netlist
Map, Place &
Route
(ISE)
Bitstream

35. About Programs –
MiniIDE
 This is a free program that allows one to write
programs in assembly for CPU12.
 It produces a S19 file that can be either
directly downloaded into the original CPU or
manipulated to a VHDL Program Memory file
for our design.
 Another useful file produced is a LST file. It
contains all the assembly instructions, along
with their addresses and opcodes.

36. About Programs –
ICCV7 for CPU12
 This program allows one to write programs in
C for CPU12.
 It also produces a S19 and LST files.
 This program is used for downloading the
program code (S19 file) into the original board.

37. About Programs –
NoICE for 68HC12
 This program is a debugger.
 The values of the CPU registers and memory
can be viewed with every step.
 Used for comparing between ModelSim
simulation and the behavior of the original
CPU.

38. Critical Path
 The actual used in the FPGA is 1.5625 MHz
(which is 50 MHz divided by 32). The
frequency is achieved by using the DCM.
 According to Precision’s timing report, the
maximum possible frequency is 4.81 MHz.
 According to ISE’s timing report, the maximum
possible frequency is 3.15 MHz.

39. The DCM
 In the process of
adding more
instructions, the need
for a slower clock has
risen.
 For that purpose, the
FPGA has a Digital
Clock Manager (DCM)
component. It can
multiply or divide an
incoming clock
frequency among other
functions.
 The component is
provided in Xilinx’s ISE
library.

40. Testing Programs –
Leds
 Two assembly
program were written,
both “play” with the
leds on our spartan-
3E.
 One toggle the leds,
forward and
backwards.
 The other counts from
00000000 to
11111111. A lit led is
‘1’ while turned-off led
is ‘0’.

41. UART
 The component was
taken from Digilent and
was implemented in our
design.
 Based on an example
file, an interface VHDL
file was made in order
to interact with our
design.
 Bitrate was set to 9600
bps.
 One start bit, one odd
parity bit and one stop
bit.

42. Testing Programs –
Calculator
 Offers the user to
choose from 5 different
operations:
 Add, subtract, multiply,
divide and modulo.
 Then the user chooses
operands, and receives
the result.
 All is done through the
UART.
 The program tests five
basic arithmetic
operations.

43. Testing Programs –
Fibonacci
 The user inputs the first
two elements and number
of elements to output via
UART.
 The CPU computes the
Fibonacci elements using
recursion.
 Each element is outputted
when ready, along with its
ordinal number.
 The output’s range is 0 to
4,294,967,295 (unsigned
long, which is quite
enough).
 The program also uses
built-in functions.

44. Testing Programs –
Tiny Encryption Algorithm (TEA)
 Receives a hex 8-byte
word for encryption.
 Receives a hex 16-byte
key-word.
 Offers to encrypt or
decrypt the given word
according to the key.
 All is done using the UART.
 No change was done to
the original algorithm[3].

45. Testing Programs –
RC4
 Receives an ascii
word for encryption.
 Receives an ascii key
word.
 Offers to encrypt or
decrypt the given
word according to the
key.
 All is done using the
UART.
 No change was done
to the original
algorithm[4].

46. Coverage
 93.5% of the opcodes are supported in our
design.
 Unimplemented instructions include:
 Interrupt.
 Fuzzy logic.
 Multiply and accumulate.
 Table and interpolation.
 Background, stop and wait.
 With our assembler and C programs, an
overall coverage of 50.5% was achieved.

47. Possible Usage
 The 68hc12 CPU core can be used as a
component inside a larger SoC (System on
Chip) design.
 Initial cost of a CPU core is estimated around
$40K.
 This design cannot be used for commercial
purposes due to University license
agreements related to the CAD/EDA tools
used in JCT.
 Nevertheless, the core can be used internally
in JCT for courses, labs and projects.

48. Thanks
 Many thanks to Mr. Uri Stroh for his
professional guidance, outstanding patience
and encouragement.
 Many thanks to Dr. Shimon Mizrahi for his
helpful advice.

49. Bibliography

[1] http://www.edaboard.com/thread9311.html

[2] http://www.assembla.com/

[3]
http://en.wikipedia.org/wiki/Tiny_Encryption_Algorithm

[4] http://www.cypherspace.org/rsa/rc4c.html

[5] HC12 CPU12 Reference Manual.

[6] Han-Way Huang, MC68HC12: An Introduction,
Software and Hardware Interfacing, Mankato:
Thomson Delmar Learning, 2003.

[7] Digilent Romania, RS232 Reference Component,
[Online], July 2008, [July 2011], Available at:
http://www.digilentinc.com/Data/Documents/Referenc
e%20Designs/RS232%20RefComp.zip [Online], pdf