This project was not initially meant to become a high-performance processor, but a generic tile, like the am2900 bitslice or the 74LS181 chips.

The difference, though, is that this slice is really one bit wide and each slice/module includes the necessary registers. Actually, it's an extension of the #SPDT16: 16-bits arithmetic unit with relays datapath, with logic functions added, and more registers.


The first implementation is with relays : #YGREC16 - YG's 16bits Relay Electronic Computer (moved to #YGREC-РЭС15-bis)

Faster versions with Germanium, Silicium and CMOS are in the works, and other technologies should appear later. For example, it's also a good candidate for an ASIC implementation :-)

A smaller core, the byte-wide #YGREC8 might even be the first to become operational in FPGA then with #Shared Silicon...

The "AMBAP" principles are the heart of the YGREC microcontroller family and the foundation for the redesign of #F-CPU. The #YASEP Yet Another Small Embedded Processor already pioneered many of these ideas.


This is the result of a thought experiment : as I wanted to design discrete computers with various technologies, it was hard to estimate how many gates, transistors, relays, or parts, would be required. How many elements should I buy to reach a given level of functionality ? If I can acquire X parts, what am I able to build and what will be the performance ? What will be the datapath width, instruction set and capacity ?

Dieter went through the same thought process before me: "Second: It turned out to be hard to estimate the size of the CPU (or the number of transistors)." so he built a TTL machine...

The solution I found is a set of recipes :

  1. Forget about the instruction set. It's a distraction. First, design the computing elements then wrap them around suitable control logic when the computational datapath is ready. Good old RISC principles will do the rest. Like, keep everything dumb, orthogonal and 1-cycle.
  2. Only include the vital circuits to perform Add/sub-related instructions, ROP2 and some shift. Keep the critical datapath short and simple. Multiplies, division, barrel shifter and anything else belong to external, slower units (with potential for pipelining).
  3. You basically need to care about the following fundamental circuits : MUX (MUX2, MUX4, MUX8), XOR, latch and/or DFF.
    Actually, once you have a MUX, you're almost done since you can do everything with a MUX !
  4. Focus on only one bit of computation and make it a tile that you can copy-paste at will. This way, you have a rough formula, depending on the number of registers and datapath width, that helps you tune your computer's size. It will appear quickly that 8 or 16 registers is a "sweet spot" but it can be changed at will.
  5. Register-mapped memory increases the number of necessary registers but saves a lot of complexity. It also makes the architecture more scalable and increases performance, with simultaneous accesses from separate arrays. I've solved the fundamental issues with the #YASEP Yet Another Small Embedded Processor so go for it. You can mix&match the configuration of the memory blocks according to your needs.
  6. PC as a general purpose register : usually required for general-purpose computing, you can keep it separate for special architectures (this saves one register, particularly if register addressing space is constrained). OTOH, a unified register file saves opcodes. So the rule of thumb is : PC is a user-visible register for 16 registers or more.
  7. Don't let yourself get caught in a nightmarish forest of control signals : it's nice to predecode as much as possible but high fanout signals can make the design impractical ! Find a compromise between local and global decoding. This varies from technology to technology...

Once you have good estimates of the complexity of each gate and circuit, you can estimate the cost/complexity/size of the bitslice and tune the parameters.


Logs:
1. SPDT version
2. Pre-Biased, or Hysteresis Relay Logic
3. My first Pre-Biased Relay Logic gates
4. A modest Globule proposal
5. Majority gate with PBRL
6. 8 registers
7. Register set update
8. Another register set version
9. Relay endurance, speed and reliability
10. A more reliable PBRL parameter
11. Bitslice architecture update
12. Memory arrays for relay toy^Wcomputer
13. Capacitively Coupled Pre-Biased Relay Logic
14. Diodes.
15. Read/Write circuit
16. Fanout and multi-rails power supply
17. Instruction ROM
18. Dual-voltage power supply
19. Pre-Biased xPDT relay configuration
20. Data retention with capacitors
21. Data RAM parity
22. New challenge : power-up sequencing
23. Refresh logic
24. Building a LFSR with relays
25. But what about the interfaces ?
26. I want to play Tetris on this relay computer
27. What about a Game of Life ?
28. How to drive many relays, new version
29. DRAM boards
30. Project split
31. How to balance a fanout tree
32. Backplane routing considerations
33. Tree balancing for IC
34. There is another system
35. Enabling discovery
36. Front panel...
37. ARM1 layout
38. Back in the days
.


Earlier thoughts:

I first selected 4 registers as a minimal yet convenient compromise (size/price/complexity/algorithmic flexibility), this could be changed as needed. Currently the relay implementation has 8 registers.

Originally the bitslice contained:

Some elements are very usual, some are less so... but work with any digital technology.

For example, I have factored the D-latch, the master is at the end of the datapath, one out of 4 slaves is selected for writing, which saves some circuits (3/8th).

The architecture is slowly evolving, under the pressure of each chosen technology and by integrating the lessons I learn at each step.


(obsolete)

Available functions :

  1. AND
  2. OR
  3. XOR
  4. ADD
  5. SHL
  6. SHR
  7. MOV
  8. ?

The first 4 can have the reg/mem operand negated to implement ANDN, ORN, XORN, SUB. In turn, SUB can be used as CMP.

This must be handled by the decode and sequence logic... This leaves some flexibility for the instruction set.

Word width can be anything, from 2 to whatever...