freesurfer-rge/slothpu

Adventures in Electronics

slothpu's Issues

Future Thoughts

I'm beginning to wonder if this design is the right way to go. The design is gaining complexity because I am trying to force things into 8-bit buses when instructions and addressing are 16-bit.

A fully 8-bit design isn't really practical:

• Too small an address space
• Very hard to fit all the instructions in

The mixed design gets complicated because:

• The C bus is sometimes used for writing, sometimes for reading
• Have to combine registers to generate addresses
• PC needs a jump register
• Loading the next instruction takes two steps

In this specific design, I have also probably made the PC too complicated with lots of instructions.... in part because needing to combine registers to create addresses makes the effective register count lower.

I'm not sure that I have a good ALU design. I think there are too many bitwise operations and shifts. Also, the 'flag' line isn't really necessary. I think a more useful ALU (no separation into SALU and DALU) would be:

• Add
• Subtract
• Compare (using comparators, so 3-bits in the output)
• NAND
• LSHIFT0
• LBARREL

One final point: since I'm using SMD assembly for a lot of this, going to a fully 16-bit design wouldn't actually double the assembly work. This is because JLCPCB requires at least two boards be assembled each time. With both the ALU and the register file, it should be possible to design an 8-bit board which can be chained into a 16-bit one.

Assembler belongs in slothpu

Most of the assembler really belongs in the slothpu package. The current script should be a thin caller into the refactored code (as should the run_slothpu.py script).

[BUG] Fibonacci comments incorrect

The comments laying out the stack frame have F(n-1) twice, rather than F(n-2)

[PCB] *ALU output register

Both the SALU and the DALU have an output register, which is updated on 'Execute.' This is not actually necessary; the result could just go on the C bus, and be picked up by the register file on 'Commit.'

[PCB] SALU r1 Decode

Working through testing, find:

• 'NOT' and 'COPY' are swapped
• 'RBARREL' appears to be different

[PCB] Tester board bad voltage shifter

The voltage shifter (U202) for the IN_{DATA} line is connected incorrectly. All of the other 'A' side pins should be pulled low, not the 'B' side ones. This is causing the IC to run very hot.

Update Jumps and Branches

The current selection of PC changing instructions (BRANCH, BRANCHZERO and JSR) are proving rather limiting. One particular factor in this is particularly acute when doing 16-bit addressing with 8-bit registers: they all take an absolute address, consuming 2 registers each time. When doing a memory copy, two branches are needed (conditional at the beginning as the loop test, unconditional at the end to close the loop), plus two addresses for the copies, plus the loop counter itself. We run out of registers really quickly.

To address this, I propose the following:

• Establish a naming convention that BRANCH is for relative operations, and JUMP is for absolute ones
• Rename the existing BRANCH instructions to JUMP and JUMPZERO to match this. They will be otherwise unchanged
• Add four branching instructions

These four branching instructions will either add or subtract to the PC, and be unconditional or conditional on a zero. So:

• PC BRANCH RA unconditionally advances the PC by RA
• PC BRANCHBACK RA unconditionally reduces the PC by RA
• PC BRANCHZERO RA RB advances the PC by RA if RB is zero
• PC BRANCHBACKZERO RA RB reduces the PC by RA if RB is zero

Since we only use one register for the change, these can only jump by 127 instructions. However, that will cover a lot of loops. Note that setting RA to zero effectively turns this into a HALT instructions. Doing a branch back with RA equal to two will have a similar effect. It is slightly unfortunate that the BRANCH*ZERO instructions will test on RB but JUMPZERO will test on RC. However, that's an aspect of mixed bitness which we can't avoid.

Note that JSR and RET will not be affected. Nor will LOADJUMP0 and LOADJUMP1.

[PCB] Register File phases

The register file is updating the register values during the "Execute" phase rather than the "Commit" phase.

Should we have a jump register?

Should the ProgramCounter acquire a 16-bit jump register, along with instructions:

• JSR which would copy the current PC to the jump register, and copy A and B bus to the PC (and inhibit increment)
• RET which would copy the jump register to the PC (and not inhibit increment)
• LOADJUMP0/LOADJUMP1 which would put the low/high byte of the jump register onto C bus (for saving in Register C)
• STOREJUMP which would copy A and B bus to the jump register

These would eliminate the LOADPC command, which is the only one to write to Register B.... and complicates the RegisterFile implementation. Since the jump register wouldn't be continually changing, it is safe to have separate load instructions for the low and high bytes.

[BUG] Fibonacci has extra instruction

I believe that now the 2-byte adder subroutine in fibonacci.txt is using a BRANCHZERO and not a JUMPZERO, line 86 can be removed. Or rather, moved into the 'padding' instructions which we have between subroutines.

[PCB] DALU r1 Decode

The rev1 of the DALU board has the outputs from the instruction decoder connected backwards (i.e. 'ADD' is 111 rather than 000). This can be 'fixed' by adjusting the instructions stored, but should be corrected when the board is revised.