4

 

Testing

 

4.1 Testing Strategy

The processor needs to be tested thoroughly in order to ensure that it is functionally identical to the original. The aim of the testing is to run real code from the start of testing. The same tests are carried out at each stage in the design. This ensured that there was no change in the functionality during the progression from one state to another.

Since the PDP-8 is already a commercial processor there were two ways to ensure the code ran correctly. Either find a real PDP-8 or use a simulator. PDP-8s are now hard to find but many simulators exist. A fully functional PDP-8/I simulator is available for download from http://www.cs.uiowa.edu/~jones/pdp8/

An assembler is required to take the assembler code (called PAL) and convert it to machine code. Again this can be downloaded from the Internet at ftp://ftp.cs.uiowa.edu/pub/jones/pdp8/pal.c.Z Having gathered the tools together it was now possible to write code to run on a PDP-8 and then test it for correctness before running it on the new version of the PDP-8.

Although the assembler will output original PDP-8 binary files, these are not in the correct format to be used on the Xilinx device available to the project. When there are address gaps in programs, e.g. code at line 1008 and then more at line 2008 there were no intermediate lines on the output. The PDP-8 loader padded out the program as it was loaded from paper tape. The solution was a C program which took the assembler output, padded out and modified the format to create a .mem file which can be loaded into the Xilinx board. Source code for the converter is available in Appendix C.

 

 

4.2 First Test Program

The first program written was to load a value and then store it back to memory. The source code is show below

/ ================================================

/ Test Program – Initial Test Script (simple.pal)

/ Written by Jon Andrews 01/12/1999

/ ================================================

/ This program is intended to test the most

/ basic features of the PDP-8-FPGA. This program

/ will load a value from a memory location and the store

/ the value in another location. This tests

/ the memory interface, ALU, AC and Halt instruction.

/ ================================================

 

*0001 / page zero

K, 0010 / data value 0010

K1, 0000 / result location

*0200 / start of page 1

CLA / Clear AC

TAD K / load the value K

DCA K1 / store AC to location K1

HLT / halt the processor

Simulations of the processor was carried out using the Powerview simulator called ViewSim(Fusion). It was not be feasible to control the simulator each time with a clock pulse, so the simulator provides a clock signal. There is also a model of the memory must be loaded with the contents of a .mem file. The following simulator directives set-up and run the simulator of the above code.

restart

loadm memory\ram < /home/S97/andrewj7/powerview/pdp8/tests/simple.mem

clock clk 0 1

h GSR

vector PC PROC\PC_OUT[11:0]

vector IR PROC\IR_CTRL[11:0]

vector ACC PROC\ACC[11:0]

vector CA PROC\CA[11:0]

vector DIN PROC\DATAIN[15:0]

vector RES PROC\ALU_RES[11:0]

vector AMUX PROC\ALUMUX_SEL[1:0]

sim

sim

l GSR

sim

break IR F02\H do (echo HLT instruction reached)

c 300

The first line restarts the simulator, then the memory is loaded from the .mem file. Then the clock must be set. The following line sets a signal GSR to be high. This signal is a simulated part of the Xilinx FPGA, Global Set and Reset. GSR is required to ensure all registers start at 0. The following lines set up the busses so they can be examined in the simulator at a later point.

The simulation will run until the IR register contains the value F02 that is a halt instruction. If the last two lines were removed then it is possible to step manually through the simulation. This is especially useful when debugging the processor.

The contents of memory must now be examined in order to ensure the correct value has been written back to memory. The command dumpm memory\ram (0:10) will print the contents of memory locations 010 through to 1010. The running of this first test was successful and the value 0010 was written back to memory location 0000.

These kinds of tests were run at the 3 stages of development; VHDL description, gate level description and one the Xilinx FPGA. Keeping the tests the same ensures that there are no changes in the functionality of the design during conversion from one description to another.

Later testing uncovered a number of problems, mainly with timing of registers latching data. For example the address of the memory location referred to in the instruction was not arriving until the clock edge when the value from memory should be written into the CA register(see Fig 3.13). This problem was resolved by making some of the control combinatorical logic, effectively decoupling it from the clock. Following these initial tests a number of test programs where written:

 

4.3 Detailed Testing

Test Code

Tested

tests_constants.pal

Loading of values using on micro coded instructions

tests_pages.pal

Tests loading from page 0, current page, off page mem locations

tests_jumps.pal

Tests jumps around the program code

tests_skips.pal

Tests skips on all conditions (doesn’t include micro coded skips)

tests_memcopy.pal

Tests copying a block of memory to subsequent block of memory

tests_jumpsubs.pal

Tests jumping into nested subroutines and return correctly

tests_microcoded.pal

Tests all micro coded instructions (including skips)

tests_immediate.pal

Tests loading of immediate values using assembler directives

Fig 4.1 Test Program Description

These tests proved sufficiently that the processor was working to the required specification. Full listings of test programs can be found in Appendix D. In order to show that the processor was able to do something other than test scripts, which could have been designed to work well on the new processor another program must be written. A common favourite amongst developers is a bubble sort.

The bubble sort is not a very complex program, with only an accumulator, efficient use of micro coded instructions and temporary memory locations is required.

The full code for the bubble sort can be found in Appendix E. The program sorts an array of numbers, stored on page zero, into descending order.

 

4.4 Xilinx FPGA Testing

Once the design had been thoroughly tested in and the download steps completed as explained in the previous section. An error was discovered on the processor when it was downloaded onto the FPGA. The reset component was not included in the design, which had been downloaded, and therefore the design did not reset on start-up. The reset problem was quickly solved, by moving the component to a different level in the schematic. . The same tests were performed on the FPGA as in the simulator. The bubble sort program was downloaded and tested along with all other test programs.

There are a number of speeds at which the processor could be run on the FPGA. Initially it was run at a conservative 1.25MHz. When all tests had completed the design was re-tested at 2.5 and 5MHz (the board limit). It is unknown if the design would work at faster speeds.

 

 

4.5 Performance Increase, Power Decrease

Based on information from Fig 1.1 which states that the original PDP-8 could perform 330,000 adds per second and the new design running at 5MHz the following is possible.

Original 330,000 adds/s

New (5x106)/3 = 1,666,667 (3 cycles per add)

A 405% increase is about what was expected from the new design. However, these figure only taking into account additions. The performance figures for the entire instruction set would be much higher, especially on a program that makes use of groups of micro coded instructions.

Performance is not the only improvement, the original PDP-8 used 500W of power. A Xilinx 4000, as used, uses less than 1W. The exact power used depends on the configuration of the FPGA, it was not possible to measure this. These figures give:

A 99% decrease in power is considerable, however it is safe to assume that the figure of 500W is also to power all the external devices (e.g. Tape Reader) which were not used on the FPGA.