Most of the parts have arrived. I am close to being able to begin construction on my ALU. I've received my XOR, OR, AND, and 4 to 1 ICs. I've got some boards I will do my prototyping on, I've had them for a while aready. These Boards from sure electronics are my preferred prototyping boards. They are vectored with support for more than one power buss, and you can solder on ether side of the board (Very convenient if you want to stack boards). I decided later on in the project that I wanted to socket the ICs (the fact that I went CMOS had something to do with this), so I'm currently waiting on a shipment of sockets.
As I draw closer to my first prototype of the ALU I'm again revisiting the scale of these. Originally I wanted to do a 32bit data bus. The math on this just doesn't work on the prototyping boards I want to use. This would mean 64 Inputs, 32 ANDd, 32, ORed, 32 XORed, and a few combinations that will have to pass between boards, along with the control signals. I've only got about 128 lines I can pass between these boards, so 16 bit is looking more likely. I've even considered dropping back to 8.
Another limiting factor I hadn't planed on was the board size limitation on eagalecad. Its A bit more spendy that I would like to license, as I am just starting to learn how to use it. The size limitation has lead to some rather densely populated boards, that become difficult or impossible to route. I had fantasised about having boards made as this would save lots of labor, and would be reproducible.
I'm planning on finalizing my a few design pieces of the ALU this weekend. I'm in the process of determining the fewest number of control signals necessary to control it. That shouldn't take to long, then I'll try look at how many ICs I can comfortably fit on a board and decide 16bit or 8 bit. I'll probably do 16bit if at all possible.
The ALU is the only part that really will be affected adversely by the larger bus size. The sequencer/controller will ultimately end up simpler if the data bus is wide enough I won't need to decode any instructions, rather the instructions can decode themselves. Thus the state machine can run off an instruction register directly without having to do combinational decoding. I'm envisioning a single bit in the instructions that repents what the function is being preformed. So imagine a bit that indicates a task will be sent to the ALU. That's all the state machine needs to do. Other bits will tell witch register should jump on the bust to the ALU inputs. The ALU can look at the bits on the instruction register to figure out what function it is preforming. And another couple of bits will tell a witch register should store the result. Instructions that require 2 or 3 cycles can have bits that affect program flow right from the instruction register.
So that's the plan now. Make the data bus as big as possible, Optimises the instructions to simplify the sequencer/controller, build it, program it, and enjoy.
As I draw closer to my first prototype of the ALU I'm again revisiting the scale of these. Originally I wanted to do a 32bit data bus. The math on this just doesn't work on the prototyping boards I want to use. This would mean 64 Inputs, 32 ANDd, 32, ORed, 32 XORed, and a few combinations that will have to pass between boards, along with the control signals. I've only got about 128 lines I can pass between these boards, so 16 bit is looking more likely. I've even considered dropping back to 8.
Another limiting factor I hadn't planed on was the board size limitation on eagalecad. Its A bit more spendy that I would like to license, as I am just starting to learn how to use it. The size limitation has lead to some rather densely populated boards, that become difficult or impossible to route. I had fantasised about having boards made as this would save lots of labor, and would be reproducible.
I'm planning on finalizing my a few design pieces of the ALU this weekend. I'm in the process of determining the fewest number of control signals necessary to control it. That shouldn't take to long, then I'll try look at how many ICs I can comfortably fit on a board and decide 16bit or 8 bit. I'll probably do 16bit if at all possible.
The ALU is the only part that really will be affected adversely by the larger bus size. The sequencer/controller will ultimately end up simpler if the data bus is wide enough I won't need to decode any instructions, rather the instructions can decode themselves. Thus the state machine can run off an instruction register directly without having to do combinational decoding. I'm envisioning a single bit in the instructions that repents what the function is being preformed. So imagine a bit that indicates a task will be sent to the ALU. That's all the state machine needs to do. Other bits will tell witch register should jump on the bust to the ALU inputs. The ALU can look at the bits on the instruction register to figure out what function it is preforming. And another couple of bits will tell a witch register should store the result. Instructions that require 2 or 3 cycles can have bits that affect program flow right from the instruction register.
So that's the plan now. Make the data bus as big as possible, Optimises the instructions to simplify the sequencer/controller, build it, program it, and enjoy.
