I have updated the state diagram, below.  When I started out on this project I had in mind a goal of operating this machine with a 100 MHz clock.  I soon discover that it was not something that was easily accomplished, so I dialed the clock down.  Originally I had 4 states in a machine cycle and each of the machine cycles were identical to that on an original PDP8e.  Once I had thae machine running I realized that the slowest path was reading from memory.  This was caused by the multiplexer at the output of the ram blocks used to select the proper word for reading.  So I added some pipeline  and sped the clock up.  The clock is now running at 73.5 MHz.  If you look at the state diagram you will note there are branches off of state F1, this was added when EAE was added.  Immediate operands for EAE ops are fetched in states F1 and F2(A or B). effectively shortening those operation.  As well when a deferred operation occurs which is not indexed the deferred cycle is only 3 clocks long.   There are other possible changes to the state machine that will increase the speed.  

 

 I took a little side trip...  I have Doug Ingraham's console serial device (CSD) running.  My PDP8 is now running OS8.  This has been one of my goals for a number of years now, ever since I had the basic PDP8 running.

I am running the console device at 115200 baud and the machine is about 16 time faster than a PDP8e.  So response times to a command are not bad.

Doug has been very helpful in debugging problems with getting this going,  Thanks Doug.

 Wow, 2 years since I posted!  I have not stopped working on this but sometimes there is very little time spent on it.

However I will report on some of the happenings.  

Just before my last blog post I had started thinking about  mass storage.   An SD card seemed to be the thing to use.  I found that the smallest micro SD card that I had would very easily store 4 platters worth of the RK05  - in fact about 1000...  So no problem with size. 

I constructed an adapter card from an SD to microSD adapter and connected it to the FPGA board.

I first thought about using buffer memories to store data that goes and comes from the SD card.  Eventually I decided to go with the data break operation that DEC implemented.  We now call that DMA!  The state machine was enhanced to allow data break.

The next problem was getting or writing the HDL to control the SD card.  After a search, I settled on using code that Rob Doyle had posted on the opencores site.  I had previously looked at using the PDP8 code from that same package but was unable to make it fit into any of the FPGAs I had access to.  The code is written in VHDL.  I have been using Verilog.  

The open source tool chain I have been using is yosys.  It expects verilog as an input.  I looked at translation tools and found nothing that worked.  I then hand translated the VHDL to SystemVerilog.  From there I used the tool sv2v that takes systemverilog as an input and outputs verilog.  This tool is highly recommended.  If I were starting over I would probably write the whole thing in systemverilog then convert to verilog before feeding it to yosys.

I also used iverilog with the g2012 flag that signifies that the source is system verilog.  Two other tools are worth mentioning here:  verilator and verible-verilog.  Verilator  is primarily a simulator but it also does an excellent job of linting the source.  Verible-verilog-format  does a nice job of formatting the code.

I was able to boot OS8 in simulation up to the "." dot prompt.  However when trying to do the same thing on hardware it failed.   I had read on the cave pearl project that some sd cards take large amounts of current during boot up.  So I added a 5 volt to 3.3 volt regulator.  I then used that to source the current for the LEDs and to provide the power and ground for the sd card.  This was still a failure.

I used a program called dumprk05 to try and dump the sd card through the pdp8.  I was able to get the first sector to read and dump properly.  However the second sector was corrupted.  When the second sector is being read, the first sector is being output on the serial port.

So my current ideas are that I still have a power supply problem, signal integrity problems, or a bad instruction execution..  This whole thing is running from a USB port of a computer, it is still entirely possible that the power supply is drooping.  The second idea is that I have signal integrity problems.  I have no test equipment to trouble shoot this.

It is possible that I have an instruction  that is misbehaving on hardware.  I previously found an instruction that was misbehaving on both the simulator and hardware but the DEC diagnostics did not find.   I also found that accessing memory within one clock cycle would simulate correctly but would not work on hardware.

I have made changes to the state_machine to reduce the number of places where I repeat code just in case I have missed some, this will be the subject of another blog post in the near future.  This also did not result in the SD card working properly.

So I am going to leave the code in the git repository and explore using spiflash, probably as a read only file system.

 I just committed working code for the EAE implementation.  This includes both the A and B modes of operation.

 

The logic utilization is:

 ICESTORM_LC:   2258/ 7680    29%
 ICESTORM_RAM:    24/   32    75%
                SB_IO:    60/  256    23%
                SB_GB:     6/    8    75%
ICESTORM_PLL:     1/    2    50%
SB_WARMBOOT:     0/    1     0%

There is still significant room for more!

The division algorithm uses is actually a restoring version rather than the non-restoring version that the original PDP8e used.  

When executing the EAE diagnostics the process was timed, it is currently 19 times faster than the original.  This of course uses a mix of instructions, not just the EAE instructions.  There is probably opportunity to speed up the shift instructions to use a cascade of shifters, 5 in total, rather than up to 23 cycles.    

The ac module has grown significantly during this process.  It is much larger that I would like, but I don't see and easy way to split it up.

 I just committed code that passes al of the hardware tests on hardware.  EXCEPT the EAE tests.

I can now start debugging them.  I would have like to debug in simulations but my computer is not up to it.  It takes too long and I run out of memory.

Some notes on the state machine:

Inputs to the state machine are: 

    instruction

    EAE mode bit

    EAE_loop

    halt

    single step

    continue

    trigger from the front panel

outputs are: 

    current state

The EAE loop signal controls the exit from state EAE1.  The number of times EAE1 loops on itself is a function of the instruction (MUL), sometimes the word following the  instruction, (SHL, ASR, LSR), contents of AC (NMI)

 I have update the code yet again.  The state machine including the EAE is in pretty much its final form.