# Computer Architecture Lab/Summer2006/PitterDeinhart/TCMP2.0
## The Concept

The design is based on a 16bit load/store architecture. All instructions need two bytes space. A rather unusal (but already existing in some chips) idea is, that every opcode can be flagged as conditional.

### Memory

Instruction and data memory are separated. Instructions are read from ROM data can be read and written to the RAM.
Since all instructions consist of 2 bytes the ROM can adress 128 kilobytes. The instruction pointer counts words. Constants can be loaded from ROM using the LDI* opcodes (see below).
Since RAM can be accessed byte per byte it can store only 64 kilobytes of data.

### Registers

There are 16 general purpose registers. Their size is 16 bits and they are called ax, bx, cx, .. px.
Additionally there exists the 1 bit sized conditional flag (CF).

## Instruction Set
### Instruction Set Description
#### Conditionals

A conditional bit is added to each instruction. If this bit is 1, then the instruction is considered conditional and is only executed if conditional flag is set. The conditional flag can be modified by CMP* or by calling clear conditional flag (CCF). Those can be conditional instructions, too.

#### Load & Store

MS: you will need an indierct load and store (LD (ax), ST (AX)). Without those instructions you will be VERY limited. Then you will think again about a register size which is less than the address size - one of the big issues in the 8086..80286 (the segementation was a real pain) ;-)
The heart of our load/store architecture are these two commands. Actually one could argue that they are 32 commands, because they have the register number hardcoded into the opcode.

#### Comparison

All comparison instructions set the conditional flag as a result.
Is there any way to set the conditional flag when register 1 <= register 2 ? Or do we need a CMPLE ?
Is there any difference at all between GMPGT R1, R2 or GMPLT R2, R1 ?

#### Others
### Instruction Set Encoding
##### ALU ops
## The Assembler and Simulator

The assembler/simulator package can be downloaded from http://www.nix.at/sw/tcmp/
Note that only versions >= 0.1 only support TCMP2.0 while versions 0.0.* only support TCMP1. The version that represents the state at the end of the computer architecture course is 0.2.4.
The pacakge consists of the assembler and 3 different simulator programs, which are all described below. Read the INSTALL file in the package for installation hints/requirements.
The package is written in Objective Caml, wich is a really greate computer language. It will generate byte code and object code executables (if supported on your architecture). So if you find an executable called e.g. asm.opt you may call it instead of just asm and it will do the same, but a lot faster.

### The assembler: tcmp/asm

The assembler can output text (to verify parser and some calculations), binary output (mainly used for simulation) and vhdl code (can be used as or in a ROM implementation).
When u call it with no arguments or with -h it will give you instruction how to use it:

#### Line Layout

The assembler layout is similar to nasm, its lines consist of up to three parts:
All three components are optional. Operands are separated by a ','.
The main difference is that there is an optional '?' that can be written directly before the instruction. That marks the instruction to be a conditional one.

#### Mnemonics

The mnemonics are lower case variants of the instructions.
There are some macro like mnemonics that will expand to several instructions when used:

#### Example Program 1: Blinking around

This little example program blinks with the boards LED.

#### Example Program 2: Blinking around with changing frequency

This is a modification to the previous example, with variable frequency.

#### Example Program 3: Instruction tester

Not really useful, but it covers all instructions.

### The simulator: tcmp/sim

This simulator takes an assembler program and simulates it instruction by instruction. You can optionally specify how much cycles it will simluate. It has its own little help screen, too:
If you simulate the first instruction of blink.asm you will get this output:
Please note that you won't see any hazards here, as this simulator knows nothing about pipelining at all. This can be useful to verify the correctness of the pipeline engine (or the builtin hazard prevention freature of the assembler).

### The pipelined simulator: tcmp/psim

This is another simulator, which is completly different from the previous one. While it should give the same results it simulates the complete TCMP pipeline. So it will corrupt registers or RAM if there are hazards. In short: It will (try to) act like the processor in hardware.
While its internals are completly different, the usage is equal to the non pipelined simulator:
If we simlate 5 clock cycles of blink.asm we get:
ox=0000
px=0000
ox=0000
px=0000
ox=0000
px=0000
ox=0000
px=0000
ox=0000
px=0000
ox=0000
px=0000
RST and CLK are the reset and the clock signal.

### The graphical pipelined simulator: tcmp/gpsim

This is a graphical frontend to the pipelined simulator (psim). It accepts no option, instead it will show you a file dialog to choose some binary code to load.
The interface is quite simple and self explaining. Just take a look at this screenshot:

## Pipeline Architecture

The TCMP2.0 pipeline consists of 4 stages:
* Instruction fetch
* Instruction decode
* Execute
* Write back
If you have not by now, please take a look at the picture in the gpsim section to get an overview. The line colors are showing from which stage the signals are coming (Cyan, Bue, Red, Green).
At this time there is no processor builtin hazard prevention, but a smart nop generateion at assembler level. Due to our not too unclever design, there is no need to delay the processor for more than one nop at once. Of course one could implement e.g. bypassing but to our luck that was not in the mandatory scope of computer architecture.
But maybe by the time you read this, it is already implemented in the simulator or even at vhdl level. So be sure to check the download packages!

## VHDL Implementation

The VHDL implementation was generated by first creating the black boxes like ALU and register file. Then we basically translated the code from the pipelined simulator (can be found in pipeline.ml) into VHDL. Once that seemed to be complete we simulated the whole thing in Modelsim.
After a few fixes, mainly dangling signals, we downloaded the processor to the FPGA. To our suprise it nearly instantly worked. Maybe it was a good idea to simulate a lot with tcmp/*sim and Modelsim. On the other side, maybe we just had lots of luck :)
The full vhdl files can be downloaded here: [http://www.nix.at/tcmp2/vhdl.zip vhdl.zip].
Additionally a couple of testbenches were created to simulate some building blocks of the processor in ModelSim. The following screenshot describes a simulation of the processor running the blink2.asm program.