Minecraft name: KilledbytheTV
What’s a thing you have made which demonstrates sufficient engineering knowledge?: I have constructed the Black Box V2, a device of which is intended to be a 1.25 Hz pipelined computer processor with the purposes of being able to run advanced programs.
Black Box V2 specifications
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
- The CPU operates on an 8 tick clock, which is equivalent to 1.25 Hz. It has a 5 stage pipeline, 8 bit
data and 8 bit instruction length. Operation codes are 5 bit and operands are 3 bit, except for JMP
which has the 2 bit opcode 10 and a 6 bit operand as a jump address. 8 bit immediates are handled
through second bytes (Effectively the only 2 byte instruction in the whole ISA) - It has 9 ALU functions: increment, decrement, add, subtract, XOR, AND, OR, left shift and right shift,
giving you a wide variety of arithmetic and especially logic operations. - Harvard architecture with memory that consists of 9 registers, 64 bytes of RAM and 64 bytes of program ROM. To access RAM
it uses a pointer (value in register as address), which allows you to do numerous array operations,
ranging from simple lists to full blown sorting algorithms. While having direct jump addresses, it
includes an instruction to indirectly jump (using a pointer), which allows you to create subroutines to
call as functions. Currently I have not made a program that requires subroutines yet, but the option
remains. - There are three flags: !C (Not carry), Z (Zero) and C (Carry). They are used during a PRD (predicate)
instruction, and the flags can be ORed together to create more complex flags e.g. “!C or Z” making an
unsigned “less than or equal to zero” after subtracting two numbers. Although it lacks signed (MSB)
flags and odd/even (LSB) flags, the right shift and left shift operations always shift the LSB/MSB into
the carry flag. This enables you to use signed flags too, e.g. left shift, predicate if C (MSB shifted into
carry) or Z (zero) to make up a signed “less than or equal to zero” as an example. - Despite the limited program ROM, it would be viable to attach a page swapping instruction, turn the
ROM into cache, hook up a denser memory and support up to 512 bytes (or more, depends on your
modification) of ROM. - There are spaces for a few more operation codes which provide expandability, e.g. for user defined
operations or generally any modifications to the ISA.
What engineering work went into designing this device?:
Originally, I was fascinated at the redstone processors I had seen people make. I wanted to make a computer with good versatility and a moderately fast clock speed. It took me several attempts, building prototypes and abandoning them to build better ones. Eventually, I got there and ended up with a buggy, poorly timed but clunkily working Black Box V1 processor.
The Black Box V1 was very simply a super simple processor with just ROM, registers, a good few ALU functions and conditionals. It ran at a clock speed of 11 ticks… eerily a bit longer than 1 second per cycle… pretty much resembles how I feel on the last lesson on a Friday afternoon. The wiring was also a complete mess so the control unit wasn’t the prettiest sight ever. Pretty much all I could do on that CPU is basic programs like Fibonacci, repeated addition multiplication and repeated subtraction division. Considering the ROM though, it could have theoretically ran a few Black Box V2 programs if you were to map a few I/O ports to the registerfile, or actually add a proper I/O to the CPU.
Speaking of the Black Box V2, I wanted to expand on the V1, pretty much being backwards-compatible with it. Clearly as a V2 I would want it to do much more than just Fibonacci or simple multiplication or division algorithms, so I would have to make some improvements. Firstly I wanted all desync and timing bugs erased from the face of the earth in that CPU, so I went to every effort to synchronise and time everything perfectly. I also wanted something a bit faster than 11 ticks per cycle, so I thought 8 ticks would be the perfect option for a CPU like this. The predication in the ISA was inspired by LordDecapo (I discovered it initially from one of FireTner’s ISAs). I also changed up the flags a bit, since in the V1, the “underflow” flag was just coming from a right shift underflow. I realised since I updated flags every time the accumulator was updated, it would just be much more useful to just plug it into the carry flag. This allowed me to have both C (carry) and !C (not carry) flags when predicating. For the RAM, I went with 64 bytes because it would equal the program memory size, if I was to ever make a version of that computer with modified harvard architecture (which I have currently not done and have resorted to pure harvard). For addressing it, I could not do it directly because I would not have enough program space. However, after chatting with StackDoubleFlow about their StackPU, I thought it would be a good idea to just use the operand as a pointer register address. I also did this for indirect jumps, despite the fact I have never used it yet at the time of posting this application. Now of course I want the CPU to reliably communicate with the outside world, so I had to implement I/O in some way. After some moderate head scratching I managed to have a chat with Koyarno who helped me understand how the control logic should work, so great thanks to them. I found that to have reliable communication between two devices, it would be good to await inputs and to await a ready signal when storing to an output too, as you don’t know if the other end is ready to receive data. Okay, so to make the parts of the CPU more distinguished, I have colour coded each part in wool, making it easy to know which part corresponds to what function. Finally, I guess I’ve established that I’ve observed too many of sammyuri’s builds, and now it’s impossible for me to build anything without making every effort to keep it in a perfect cuboid shape, so it ended up looking very B O X ™.
Okay, so this overall gave me a pretty good CPU to play around with. Some notable programs I have made so far would be bubble sort, insertion sort and bresenhams line drawing. Not the most impressive things in the world but fairly advanced. I might have a go at making some more complex programs later (soon™), that could turn out pretty interesting. Although the Black Box V2 is a reliable, fast and neat CPU, it does have some downsides. First of all, due to the FDDEW nature of the 5 stage pipeline, predicates require two flag delay slots after an ALU operation rather than one. However, sometimes this can be circumvented by making placing part of the code within the delay slots. Also the RAM decoder is a bit large and a tiny bit laggy, something I am improving in the V3, but it’s not a big problem really. The dataloop lacks forwarding, but due to its accumulator architecture, there can be clever ways to circumvent data hazards, but generally I would consider implementing forwarding in the future. Last of all, the increments, decrements, left shifts and right shifts do not save to the source register, rather the accumulator. This can sometimes prove to be useful, and sometimes annoying. However, this can be altered easily simply by swapping a few torches in the control unit ROM, so not always a big deal.
Anyway, I hope you believe me that this CPU has great potential, and if the interview takes long enough to be organised, who knows, maybe I will have done even more with it!
Image/s and/or video/s of the device:
Black Box V2 with RAM screen attached (Setup for insertion sort)
Back view of the CPU
B O X ™
Black Box V2 running bubble sort on a reversed array
Black Box V2 has drawn a line! wow so awesome
Black Box V2 insertion sort in action (using MCHPRS)
It is of my wish that you declare this creation worthy of the Engineer rank. To accept or not to accept…?
~Comrade KilledbytheTV
