I didn't feel like cleaning off and organizing my workbench today, so I spent time noodling in KiCad, and sketched out one four-bit slice of the ALU for a RiSC-16 TTL build.
Here's a link to my Git Hub repo: https://github.com/Martin-H1/KiCad/tree/main/RiSC-16 I also attached an image as well.

Conceptually it's simple enough, but there's just a lot of chips and connections in the full 16-bit ALU. My thinking is that you load the A and B inputs sequentially via the data bus and output the results in a third step. An alternative would be connecting the data bus to the A input and the address bus to the B input and load them in a single step. However, that requires the ability for the register file to simultaneously address two registers. That's something register file chips like the 74172 are capable of, but they're out of production.

I have been noodling with a few ideas for the register file and it's going to be a tricky beast. Ideally a register file has three sets of address lines (source 1, source 2, and destination), two outputs, and one input. Unless I'm missing something that would require 32 8 to 1 multiplexers and 16 octal D flip flops just to get the two addressable outputs.

I've a feeling you might be seeing a real architectural tradeoff here. It's very easy, on paper or in an emulator, to declare that you'd like to send two registers into your ALU. But in actual hardware there is an implementation cost, according to how many ports your register file needs to have. That cost might be in transistors, wires, picoseconds or megahertz, picojoules or milliwatts, square microns or square milimetres. Or indeed, units of currency! Or indeed, time spent designing, time spent debugging, time in production test, or time spent soldering!

It's always interesting to see engineering tradeoffs. They don't always appear at the higher levels of abstraction.

In this view, the questions might be, what are your priorities and what costs are you prepared to accept? (For example, in some nearby parts of design space, you can replicate the register file, so that writes go to all copies but several independent reads can happed in the same cycle.)

Another way to look at it: with the cheapest register file you could build, what would the effect be on the ISA, or on the cycle counts?

Yes, the tradeoff is introducing separate read, read, and write cycles. Besides being slower the sequencer and microcode will be more complicated. The PISC architecture avoids having a sequencer and microcode because of the 74172.

I found out the 74LS670 is still in production for a reasonable price. It's a 4x4 register file that supports one concurrent read and write. Reading the data sheet it's insides are exactly what I was thinking about. It has an address decoder to select the write target D flip flops, and a four channel demultiplexer in the output stage. With two of those and two 74LS257's to drive the address and data busses you would have a two-port register file. It would still require two read cycles, but the ALU write back could happen concurrently with the last read cycle.

My thoughts on a register file. The 74LS670 is still in production and has a capacity of four four-bit registers. Two 74LS670's plus a 74LS257 multiplexer add an extra address line and doubles the capacity to eight. But use two 74LS257's to create two output ports, one on the data bus and the other on the address bus. The allows registers to be used for addressing or data.

I also changed the ALU to get one input from the address bus and the other from the data bus. So, here's the sequence to load the ALU and perform a write back for an RRR-type instruction.

The first register address from the decoded instruction is sent to the read address port on the register file.
The RDout control signal is asserted.
The ALU's Ain control signal is asserted.
The RDout and Ain control signals are de-asserted.
The second register address from the decoded instruction is sent to the read address port on the register file.
The RAout control signal is asserted.
The ALU's Bin control signal is asserted (this and the second 74LS175 might be unnecessary).
The AND/NAND bit from the decoded instruction is asserted.
The ALUout signal is asserted, and the results are on the data bus.
The target register address from the decoded instruction is sent to the write address port on the register file.
The RWin signal is asserted to allow the write back to the register file from the data bus.
These signals are de-asserted in this sequence: RWin, ALUout, RAout, the register addresses, and AND/NAND.

That's roughly the microcode for two instructions.

Update: I just remembered that a read of R0 is always supposed to return 0. That's going to need some extra logic.

A prerequisite to cleaning off my workbench is finishing a storage cabinet. So, yesterday I made and installed one drawer. Three more, plus drawer fronts to go.

While the glue was drying, I read this document https://user.eng.umd.edu/~blj/RiSC/RiSC-seq.pdf by Prof. Bruce Jacobs. It describes a RiSC-16 sequential implementation but leaves enough open details for students to learn as they implement it. My guess on an FPGA, not TTL because there's no ALU IC in production that matches the functions he describes. My guess is he intended his students to implement their own ALU or reuse an existing FPGA based design.

But it left me with a few thoughts about what I'm doing:

* The LUI instruction passes the output of the immediate value through the ALU for the register write back. This implies either an extra ALU function or an ADD with the always zero R0.

* The LW and SW instructions add an immediate offset to the address register, but there's no write back to that register. Rather the ALU outputs the sum directly to the address bus. My original design only allowed the ALU to output to the data bus. This can be fixed with an extra latch but increases the part count and control signals.

* The BEQ instruction requires an EQ ALU operation! This should have been obvious, but I wasn't thinking ahead. At this point I'm thinking of swallowing my pride and using a 74LS181. I know they're obsolete and no longer in production, but I have five in my parts drawer for just such an emergency. There's also a ton available on the used and NOS markets because the minicomputer manufactures used them in the 70's to mid-80's.

* The reference design uses a separate adder to modify the PC register in the BEQ instruction. This avoids two trips through the ALU (EQ test followed by ADD), at the cost of increased parts count and complexity in the control unit. However, this isn't strictly required, and the ALU could be used for both at the cost of some performance.

* Conversely the JALR instruction uses the ALU to load the PC. I originally thought the PC would be loaded via the data bus after an ALU operation, so that matches my thinking.

* Prof. Jacobs helpfully enumerates the list of control signals his design uses. I intend to adopt his nomenclature going forward.

Probably the next thing for me to think about is designing the control unit. There's a lot of complexity there, probably more than I have currently encountered. This complexity helped me understand why symmetric ISA's are more complicated than accumulator machines. The NAND game ISA is a two-accumulator design and was much simpler.

Interesting project. I used the 181 ALU on my first homebrew computer, the TTL-Retro. The data sheet for that device can be pretty confusing! Just thought I would mention that there is a 74F181 version of the device that is in the 0.300 inch DIP package. In my case that saved some real estate, as the TTL-Retro was a 12 bit machine and required 3 of the IC's. Here is a photo of my ALU board.

Also, here is a link to that early project on my website. Good luck with your project and welcome to the forum! Michael

https://www.mtmscientific.com/stack.html

I wish I knew about the 74F181 before I bought five 74LS181s. It's a better form factor, especially since four are needed in a 16-bit machine. I agree the data sheet for those ICs is confusing; I think I understand it well enough that with some experimentation I can use it.

Thanks for the link to your project and the Richard R. Eckert web page. It was interesting to read more about how hardwired control units work. If I actually build this, I would go with EEPROMs and microcode because I've seen enough of those in other projects that I understand them.

The 74xx181 does make the data path simpler but you still need a PC, a Accumulator and Memory address register
and data register for a simple computer. The 2901 throws in a free register file. The data path is easy but messy with
lots of MSI chips.

I find bypass caps take up most of my PCB board space now that I have gone to 4 layer thru the hole boards,
My latest 16 bit computer has a bus with space for VCC and GND after every 8 data and address bits.A 2 x 32 connector
works nicely. 22v10's are a nice glue chip for undefined logic at PCB lay out time, like clock timing logic.

Core memory works better with state machine decoding as you had only 3 memory cycles at most for a instruction
fetch,defer,execute. Micro code is for machines with solid state memory. Simple ROM/PAL decoding is in the middle.

My problem with designing is I never include test logic in a project, a bad habit have.

@oldben, I have never heard of the AM2901 so I just did a search for the data sheet. They're also available for about $15.00 each on eBay. That's also a viable option.

In any case, I reworked the ALU to use the 74LS181 with the selectors and control signals from page 10 of "RiSC-16 Sequential Implementation". Prof. Jacob's design is relatively economical on control signals and instead requires a wide control bus with many data lines. I'm guessing the control bus could easily be 100 lines.

I have some concerns about the '181's A=B function which sounds like it might not a test of A=B, but A=B=1111. That sounds useless if true.

The 74181 was designed to use active low logic for A=B.
With active high logic skip type testing, if a =. 0 then skip complimenting for the alu test
was not really a problem. Remember the carry is inverted.
The 2901 also has 16 bit version, in 64 pin dip.

@oldben, thanks for the clarification.

Here's a Program Counter slice with logic to initialize on reset, increment after fetch, set the value from a JALR, or relative branch from BEQ.

Here's the Instruction Register with decoders to break out the control signals from the instruction. Some of these signals feed directly to other system components (e.g. ALU, register file), while others (e.g. OP) are fed into the sequencer to select the relevant section of microcode.

I'm not happy with the ALU function decoding as it's a hack. A better system feeds the ALU function from the instruction into the sequencer, and the microcode determines the ALU bits. That way the ISA remains independent from the implementation (e.g. 74LS181). I plan to revisit that when I design the sequencer as I know I need additional states (e.g. reset, fetch). When I design the state machine, I might be able to incorporate the ALU function bits from the instruction into the state machine to generate the ALU signals.

Also missing from the control unit is a carry/link register bit. The original ISA doesn't include that, but it's something that could be added in the future with just a slight redesign.

Unfortunately, I think the register file needs a redesign because of the need for R0 to always be zero. Plus, two read ports would be super handy. I've also noticed that the diagram I am working from overloads SRC1 and SRC2. In some cases, they're the signals to control the register, and in other cases they're the data lines from the selected register. I plan to revisit and clean this up after the first draft of the sequencer.

I took a little detour back to the register file. The current design has a problem because R0 is always supposed to return 0. It has a smaller problem that it doesn't support two concurrent read ports. The latter increases the complexity of the sequencer and microcode. Basically, there's a good reason why the 74LS172 has two read ports.

There are a few ways to address this:

* Use four 74LS670's per four-bit slice. Pair them so their write ports are connected to create two read ports per register. Use the existing decoder logic to allow for addressing eight registers. Add an output mux and detect when R0 is read and connect to ground. This would cost about $80 in IC's!

* Admit defeat and buy eight 74LS172's off eBay. Add an output mux and detect when R0 is read and connect to ground instead of the register file. This would also cost around $80!

* Go nuts with the design below. It uses fourteen D Flip Flop IC as registers. Thirty-two 8 to 1 decoders to create two read ports. One 74LS138 to address the write port. R0 is wired to ground. Ironically this would be the cheaper option, although actually building it would be a challenge.

They have a 2901 as 74Fxxx chip, so you still could call it TTL.
The 74LS219 or 74F219 are nice single port rams. The register file is what made RISC RISC
but they never made it out as TTL part sadly. The AM29705 dual port register file can still be found
on ebay. It may meet your needs.
With ebay I find parts cheap with $100 shipping or $100 parts with cheap shipping for the same product.May you have
better luck than me.

The AM29705 seems like a possible option. It would require four of them and looking at eBay, it would be around $28.00 all in. The R0 problem might be solvable through microcode. It has the A-LOB pin which forces port A's output to zero. I'll need a conditional branch in the sequencer for BEQ. Something similar might be possible with attempts to use R0.

Using the AM29705 with the 74LS181 would mean I am moving closer to Andrew Holme's Mark 2 Forth computer: http://www.aholme.co.uk/Mk2/Architecture.htm

It's basically a derivative of the PISC design but greatly enhanced due to the larger register file and programable logic he uses.