When I started this project a couple of years ago, my goal was to implement the i4004 CPU in an FPGA. What blocked that was my lack of experience with FPGAs, and the techniques that could be used to translate a slow, dynamic-logic design into a high-speed, static-logic implementation. The goal eventually morphed into building the CPU out of discrete components, but I'm still using the FPGA reference board I bought for the project to drive the test jig.
One of the questions floating around in my head was how to properly test each board or sets of boards. I gave thought to using a PicoBlaze soft microcontroller core in the FPGA, and I also considered building a simple state machine that would just drive defined signal patterns. These may yet become reality, but to test anything complex would require a really detailed analysis of the signal patterns found in a real i4004 CPU.
Having now found a solid solution to my FPGA implementation problem, another means for testing the discrete logic version presents itself: implement the CPU in the FPGA, broken into modules the same way the discrete implementation is broken into boards. This way I can mix and match soft implementations and hard, subject only to the limitations imposed by the available I/O pins on the FPGA. Which may, unfortunately, preclude testing the Instruction Decoder or ALU except as a pair.
Thus far I have a large portion of the Instruction Decoder board coded. It's amazing how large arrays of transistors collapse into a single line of behavioral Verilog. I have several versions of the DRAM arrays prototyped from previous experiments, and though most are structural implementations I wouldn't expect those to take very long to recode. Figuring out how the ALU works in detail may take some time, but it's something I need to do anyway, and it's something I can do in bed with my laptop propped up on my lap rather than in the lab.
Very cool project! I have no experience with electronics but want to implement 4004 via software simulation
ReplyDelete