I made some more progress now that I think it's a good time to share.

The "Sequencer" in logisim is linked below as a readable pdf.

With relay logic, implementing edge-trigger mechanisms is not possible or reliable, thus a "sequencer" is required instead. I must say that I hate this name for the specific use that the circuit will have, but the term seems to be pretty common on relay based computers, and I didn't figure out a better name.

Anyway, the sequencer produces "clock phases" and "clear signals" that are used for the data path. This is required among others, to store data into registers. As an example, the status register below can store 3 bits corresponding to the C, Z, and T flags (for convenience reasons Z is stored negated (NZ), but that does not change the concept)



(The boxes with that 'square' on their top-right edge represent relays with one output connected to their bobin input, i.e. holding-relays. The logisim model for relays (not discused here) is a bit different than the one that I showed before because I found many problems in logisim if the relay holding line was placed outside the relay subcircuit box, rather than directly in it)

To store a value in a register, we start by first setting IE and CLR. With both IE and CLR high, the register follows the inputs (NZ, C, T) as they get directly connected to the register bobbins. CLR acts as a 'hold' line for the register values: this means that when CLR is on, the hold line is released so the register just follows its inputs; when CLR is off, the hold line is enabled, so the register will keep the values of the inputs after IE goes off. In order to prevent register relay bounces (quickly going to off, then to on) the CLR input is ignored unless the IE is on.

Next, we set CLR to off, while still keeping IE on for some time so that the hold line gets energised and the register will keep the values of the inputs. Finally, IE is set to off and the register keeps the values.

The sequencer provides these signals in two clock phases. Two phases are required because it is not possible store a register value to itself after a change. Even incrementing the Program Counter requires an auxiliary register, the 'incrementer' just to increment it.

The following figure represents the signals generated by the sequencer:



Signals PH0, PH1 and CLR1, belong to Phase1, and are used for instruction decoding and execution.
Signals PH2, CLR2 belong to Phase2, are used for register/memory write back, and next instruction fetching.

All instructions are executed in one single execution cycle consisting in two phases, which use 4 raw clock cycles. Signals from Phase 1 are deliberately longer than Phase 2 to optimise total execution time and enable higher clock frequencies. I think it can't really be made faster than that.

As I made evident before, the Risc Relay cpu made by member Roelh, is my primary reference. It uses a similar overall approach except that the required delays on the enable signals after the clear is done, is achieved by means of capacitors. It helps to save a bunch of relays, but I am not comfortable with this approach because it occurs to me that this ties the maximum clock frequency to the actual delays produced by these capacitors. It's a compromise to get the proper value for these capacitors. On the contrary, I think that the 'sequencer' approach should allow for pushing the system at higher frequencies in an easier way. I also think that as the relays get older and the effective switching times and contact resistances get higher, the clock rate can just be lowered to get the computer working again free of glitches (before relays acting weird get replaced)

I forgot to mention that I have created a github entry for this project. The link is this:

https://github.com/John-Lluch/G6A-RISC

There's more stuff there than what's discussed here, but it's mostly work in progress that I will eventually disclose as things get to a stable state.

Great - thanks for sharing. The multi-phase clock construction reminded me a bit of my time in the death-march T9000 transputer project: four phases were produced at the PLL, and then local subsystems used constructed clocks, such as 1 and 3 for strictly non-overlapping, and 1 and 34 for semi-non-overlapping. I was new to these things and just did as I was told. Flops were built explicitly from two transparent latches, and the question was how to clock the master and the slave. This was NMOS technology.

Hi Ed,
About multi-phase clocks for relay computers, the "Relay Computer UK" that I referred on the opening post, uses no less than 24 states to make several constructed clocks (https://relaycomputer.co.uk/2019/11/sequencer-design-24-cycle-fsm (12 full clock cycles). It's fairly well explained in the linked page. This large 'sequencer' is allegedly required for the "goto" instruction, although it can be reset to a shorter sequence for other instructions requiring less steps. That relay computer (in construction) is one of the 'clasic' set that borrow the architecture of the "Harry Porter" one, as far as I can tell.

Interesting - that seems to be a compound function which combines what I'd think of as a clock generator and what I might think of as a T-state sequencer. (The 6502 internally produces a two-phase non-overlapping clock, which could just about be regarded as a clock generator.)

I updated the "G6A-RISC" document with an updated version of the Instruction set and more detailed description. https://github.com/John-Lluch/G6A-RISC/blob/master/Docs/g6a-risc.pdf

The relevant table is this one:



The interesting part is that to make decoding easier, I removed all the special instructions for the PC. The PC has always been part of the general register set and therefore it can be used in all instructions and addressing modes. So instead, I added general encodings with some interesting effects. The blue columns on the right are just renames of the instructions in the rest of the table, but no different encodings or functionality exists for these instructions.

Move and link. The 'mvl' instruction is a special 'mov' instruction that will store the address of the following instruction into register R6 (or A3) before executing the move. So when used with the PC, it is effectively a Jump and Link instruction for subroutines. Given the availability of this instruction for all registers, it can be used in advanced ways, for example to save program addresses during the flow of execution, where we want to jump back later.

Conditional Arithmetic. The instructions 'adt', 'adf', 'sbt', sbf', (add, sub if true, false) perform conditional binary add and sub based on the T flag. So when used with the PC, they are just conditional relative branches. With these instructions now available, the multiplication algorithm can be performed with one less instruction in the loop, so 16 instruction cycles are saved, with the core multiplication representing a 16.7% speed improvement over the version that I posted before for the supposed stack based calculator



(There's more detail on the document linked above)

The decoding of the new set is easier because it's all fully orthogonal, and the ALU had everything already in place to execute that. The prefix instruction is now encoded as a general one as well. It does not depend on particular operands as before, but just on the instruction opcode, so it's decoded as part of the general procedure.

I have now to refine the logisim model (there's a couple of weird behaviours that I do not yet understand) and then start working on the assembler, which will be just a modified version of the one I already implemented for the CPU74.

Hi Joan, its a good move to treat PC same as the other registers, so that you now have conditional add/sub for all registers.

The RISC cpu once also had the same construction, but lateron it was dropped because there was not enough opcode space, and that was caused by the wish to have 8 bit immediates in each instruction.

I suppose there are many ways to define an instruction set depending on what it is intended for.

My CPU74 set for example, has up to 4 different widths for immediates depending on the type of instruction. This particular architecture was designed to be very compiler friendly and produce really compact compiled code. The instruction encodings are very dense with few unused slots and careful choice of the missing instructions. The widths of immediate fields for every instruction class is chosen accordingly. Some instructions treat their immediate field as a singed value an others as an unsigned. Overall, it's a similar approach than the ARM Thumb processor. In particular, the CPU74 ISA defines the following:

- Jump instructions and Frame pointer adjustment instructions have 9 bit signed immediates.
- ALU ops have 8 bit unsigned immediates, except the mov which is 8 bit signed.
- Zero page addressing mode, and SP indexed mode have unsigned 8 bit immediates.
- Register indexed memory accesses have 5 bit unsigned immediates.
- And there's the prefix instruction with an 11 bit immediate, which extends any of the above to 16 bits by just prepending an instruction.

Decoding of immediate fields is relatively easy because identifying their width and sign-extension is easy based on a few opcode bits, and the remaining decoding is supposed to be ROM based, which will run in parallel with the decoding of immediates. Also, the Harvard architecture enables fetching/pre-decoding to be performed in parallel with the execution of the previous instruction, reducing total cycle time. Finally, it's a pure load/store architecture which strictly avoids using the ALU during memory access cycles, so it's either the ALU or the memory, which should reduce the instruction execution time to just slightly above the time taken by either of the two, enabling much faster theoretical clock rates than most homebrew computers (although the latter is still to be proven, of course).

For the G6A-RISC, on the contrary, I took advantage of the peculiarities of sequential relay logic, which made possible to have ALU operations directly on memory, both for loads and stores. It's almost an opposed approach to the CPU74. The required relay two-phase clock means that there's little or no performance penalty by having this, with the added benefit of more computing done with less code. As a consequence, the encoding space for immediates is reduced.

To summarise, I prioritised a more extensive instruction set over having large immediate fields on the G6A-RISC because I believe that the kind of code that will be executed on a relay computer should not generally require long jumps or long indirect accesses. The availabily of the 'prefix' instruction already covers these cases when needed by adding an instruction cycle to the regular instruction. I think that the penalty of the occasional prefix instruction should be greatly compensated by the availability of more instructions and ALU operations on memory.

I completed the logisim model of the cpu and successfully ran a few instructions. I also changed some instruction encodings to make decoding easier, and added the 'hlt (halt) instruction and the 'lp' (Load from Program Memory) instruction.

This is the updated encodings table:



All the relevant documents, in readable pdf format, are in the "Docs" directory of my Github Repo https://github.com/John-Lluch/G6A-RISC. The staring point is the "GA6-Risc.pdf" document.

I also took some time to convert all Logisim diagrams to 'pdf', so they are easier to review. I placed them in the "Docs/LogisimDocs" directory, and also attach a couple of interesting ones below.

- The ALU is essentially the same as before, but now it incorporates logic to handle condition codes, the 'cmp' instruction, as well as the conditional instructions (including branches).

Possibly the most interesting diagrams are "Main", which is the top level one showing all the elements of the cpu, and the "InstDecoder". (For some reason the forums didn't want to upload the latter, but the file is in the github directory anyway)

There's still a couple of missing things, such as the implementation of the 'halt' instruction and the I/O (Numeric keypad and BCD display), but otherwise it should be almost it.

- According to Logisim, the design uses 904 relays, which is almost 50% more than my initial estimation of 600-650 relays. It's a big number, but in practice this will be reduced slightly (by about 26 relays) because I will only implement a 12 bits Program Counter. The Harry Porter "classic" relay computer has 415 FPDT (4 pole) relays, despite it has only a 8 bit data bus and the instruction set is not orthogonal at all, so I think that having around 900 DPDT (2 pole) relays for this one is more than fair.

I have put special effort to reduce the critical path for as much as possible. Relays take zero time to propagate signals through their contacts. This property can be used to optimise total propagation time. For example, a binary decoder uses only ONE single propagation step regardless of how wide it is. Using this property and a convenient choice of instruction encodings, I managed to get all control signals with only one single step for instruction decoding. However, it's difficult to get the ALU any faster.

The architecture is very simple:

Phase 0:
The Instruction Register is updated with the already fetched contents of program memory, and decoded immediatelly.
This uses 2 propagation steps:
1 - Enable IR
2 - Decode

Phase 1:
Control signals are instantly available when Phase 1 arrives. Operands are fed to the ALU and the ALU results (including status flags) are stored in the ALU Register
The ALU worse case is BCD arithmetic. It uses up to 6 propagation steps
1 - Select Inputs, Enable ALU register
2 - BCD adjust +6
3 - ALU inputs multiplexer
4 - ALU add (Note that the carry chain is free thanks to the Dieter Muller ALU design)
5.0 - BCD adjust -6 (if necessary)
5.1 - T flag setting (this happens simultaneously with 5.0)
6 - ALU Register update

Phase 2:
1 - Enable Destination
2- Destination Update

Simultaneously with the above, the following happens:

Phase 1:
1.0 - Increment Register Enable
1.1 - PC Increment
2 - Increment Register Update

Phase 2:
1 - Enable PC for increment
2- PC Update

Looking at the Sequencer Signals diagram that I posted before, I allocated half clock cycle for phase 0, one clock cycle for phase 1, and half clock cycle for phase 2, so there's double time allocated for phase 1 than for phase 2 or 0. I think this is ok as I rather never have the critical path happening in phase 2.

The Relay manufacturer says maximum switching times of 5 ms. Let's take 10 ms for safety (factor of safety = 2). So phase 1 takes 60 ms, and that's 1/4 of the total instruction cycle. So the cycle is 240 ms, or 4 instructions per second at a maximum clock frequency of 16 Hz with a factor of safety of 2

The Architecture supports the execution of all instructions but one in one single instruction cycle, including jumps (regardless of taken or not taken) as well as the jump and link instruction 'jl'.
The only instruction requiring 2 cycles is the load program memory 'lp' instruction.

Hi Joan,

I see your ALU section takes 6 propagation steps, I think that can be improved.

The Risc Relay CPU uses only 2 propagation steps for the ALU:
- load the two input registers of the ALU
- Carry relays, logic-result relays and a few other relays respond to the new input register contents
At this moment the output of the ALU is available to be stored in a destination register.

While diode logic is used in my design, I think the same propagation can be realized with relay-only logic.

My ALU handles the +6 and -6 functions for decimal calculations with just 4 extra relays per nibble, without adding time. Did you study it ?
I can of course answer questions that you might have about that.

I see your multiply algorithm uses 5 instructions per multiply cycle, that could be reduced to 3 cycles if you unroll the loop. Will the
same sequence work for decimal multiplication ? I think there might be a problem here.

FYI I use relays Fujitsu FTR-B4CA012Z, they specify 3 msec operating time. Expensive at Mouser, but 62ct at soselectronic.com (qty 350).
With these relays I once operated the ALU-register combination at around 130 instructions per second.

Hi Roelh, thanks for your input.

Well, I certainly "studied" your design, in fact your work is my main reference! (although this does not mean that I understand every single detail of it). However, we must take into account the differences to make a proper judgement. The comparison you made above is not totally fair because your assign the time to load your alu input registers, and to perform the +6 adjustment, to a previous phase, not to the ALU phase. If I discounted that time, my time would be 3 propagation steps. My cpu has one extra propagation step because the T flag must be generated out of the Z, C, V, S flags. I think the total time can't be reduced, but I am of course open to suggestions. A fairer comparison would be the number of steps (excluding inter-phase times) taken to complete an instruction.

For the +6 circuit I use 3 relays per nibble, so that's one more. For the -6 circuit however, I am currently using 6 relays per nibble, including the by-pass circuit (depending on Carry). You can look at the ALUAdd6 and ALUSub6 files. On the -6 circuit there's a carry negation relay that uses 1 propagation step, but this is simultaneous to the T flag update, so it does not hurt in this case. That could be improved by generating the negated carry signal directly from the ALU, simultaneously with the normal carry.

I'm aware that I can unroll the multiplication for performance reasons, I will probably do that in the final implementation. About decimal multiplication, you are right that the 'adt' (conditional add) can't be used, however, my earlier example using the 'set' instruction (conditional select) is still valid. This uses 6 instructions per multiply cycle. Said that, I have still a couple of unused instruction slots that could be used to incorporate a 'conditional decimal add instruction'. The ALU has it all to compute it without any changes, by just setting the right control signals, so it's really easy to eventually incorporate such instruction. The instruction encoding slots are now fixed, but the choice of actual instructions is still subjected to change. I think my multiplication procedure should beat your implementation, but it's too early to know for sure.

The relays you propose are an excellent choice. They are fast and very compact. I ultimately chose the Omron G6A instead, despite being bigger, because of their stated electrical durability of 500,000 switch operations at max switching load (2A resistive). I did not find any relay as durable as that (excluding reed relays). I suspect the fact they are almost twice as big as the Fujitsu ones is not particularly relevant because most PCB space is used for traces anyway, so this means that the Omron relays can be arranged in the PCB more closely than the smaller Fujitsu ones.

About switching speed, looking at the specs, the main difference is on the 'release' times: Average is 3 ms for Omron and 1 ms for Fujitsu. The 'operate' times however are not that different, 1.2 ms for the Omron and about 1 ms for the Fujitsu. For my design, the 'operate' times are more important than the 'release' times because most relays get released during the inter-phase times, so critical paths are defined by relays being operated in cascade.

(I hope the above makes sense)

I'm happy to post that I completed the assembler and had my Relay computer running its first complete program, in Logisim, anyway.

This the assembly source code of the test program:
G6A-Risc


The program performs the addition of memory location 'a' with memory location 'b' and stores the result in memory location 'result'. Both 'a' and 'b' are defined as initialised variables. 'result' is an uninitialised var.

The assembler is a modified version of the one I already had for the CPU74, it automatically calculates offsets, inserts or removes prefixes, and produces forward/backward jump instructions as needed. The log file generated by the Assembler:



The assembler also automatically inserts setup code to copy all program constants and initialised variables to Data Memory. The program starts by jumping to the setup code. The assembler places the setup code immediately after the user code, this way the 'zero page' program addresses are fully available for the user program. After setup has completed, execution jumps to the main user program, which in this case performs the addition of two variables described above.

The program has been loaded in the logisim simulator ROM, and after solving a couple of bugs (incidentally on the assembler, not on logisim), I ran the program successfully !! I suppose this can be considered one milestone reached.

The next step will be making a software simulator, so that more complex programs can be tested. Since I already have the logisim model, I will not attempt to create a simulation at the control signals level, but only something simpler that just decodes instruction opcodes and executes them.

A major step!

Very good. Are setupAddr, dataAddr and wordLength special constants?

Well, yes and not. They are hard-coded symbols that I insert to the assembler symbol table, respectively with the address where constant data starts in program memory (setupAddress), the address where that data must be copied in data memory (dataAddr) (currently always 0), and the number of words to copy (wordLengh).

The 'start' and 'setup' assembly code is just text inserted before and after the user code, (same as if it was on a source file), so the assembler just assembles it altogether along with the user code. Since the symbols in the 'setup' source are available in the symbol table, the assembler just replaces them by their values as part of the normal procedure that already works for the user code. This makes things easier and scalable in case I eventually need to extend the setup code with some additional functionality.