Відео

That's an excellent point! I like the idea of giving special meaning to labels starting with a `.` and treating them as relative/scoped to the previous label that did not have a leading `.`. Very elegant.

Excellent point! 👍 I'll fix that 🙂

Thank you very much! 😃 I use Manim by the fantastic Grant Sanderson @3blue1brown

Oh, that's cool! I've seen his videos, I should have recognized the style 😊

@dmoisset 😃 It has a very distinct way of animating things. I love the style of his videos and how much effort and attention to detail he puts into it. And the fact that it's a programmatic way of animating helps a lot with the more systematic animations, like showing the CPU's internal state.

😃 I'll definitely go and fix the syntax highlighting at some point!

Haha, that's definitely a good approach! 😃 How come you had bits to spare?

@@fabianschuiki my very first softcore processor was a 16 bit address and data multi cycle. Many instructions took trailing 16 bit immediates, including branching. Was quite pleased with it (got as far as programming Snake (video on my channel if you are interested), but in retrospect it wasn’t great. Latest 32 bit core is a mostly RISC like 2 stage pipeline with embedded immediates. It’s not quite as friendly on the assembly programmer, but more interesting technically. I’ve implemented Boulderdash on that. Yes I build processors to play 80s computer games! 🤣

@lawrencemanning That's really nice 😃🤓!

None that I am aware of 😃. Usually you would just load a base address into a register and add the offset onto that yourself. But since this is an 8 bit machine I thought it might come in handy. And it was basically free hardware-wise. Immediates and the rs2 operand are on the same wires 🙂

I haven't done any tests yet. It might be worth to statically compute the timing of the CPU and then compare it to the actual hardware, and then figure out where to place registers to cut the long paths.

It would be fantastic to have components on the back 🥳! I haven't figured out how to make that reliable during soldering though. You probably have to go solder the caps manually afterwards because the hot air would heat the PCB to a point where the front parts would fall off again 🤔 Not sure how this is done industrially. I've seen glue being used to hold components in place occasionally -- not sure if that's the answer though.

@@fabianschuiki I’ve never had a problem with caps falling off. I usually solder the caps etc on the back with hand placed paste, then flip the board over and solder the front parts the same way. I used PCB posts on all corners on both the front and back by screwing posts into posts in a stack. That way the board is always flat on desk. I do not usually solder a whole board in one sitting with a stencil as my boards are bigger, but I have done it before. I don’t believe enough heat will travel through the board to make components fall off, but don’t hold me to it. I have been doing that for a few years now though with my projects and never had a problem. Also, your caps are disproportionately small compared to the SOIC? 50mil packages. In my opinion anyway. 1206 or 0805 would probably be the size I’d go for.

It's pretty much down to limitations in EasyEDA. The neat thing about it was that it's incredibly easy to get going, you can do all the PCB ordering right in the program, and it has pretty much every LCSC part already in the library. KiCAD will definitely be my tool of choice for future projects 🙂

@@fabianschuiki I’m glad you are going to be looking at KiCAD soon. You’ll like it. The workflow for getting a board made is really not that scary: export as gerbers (defaults are almost certainly sufficient), export the drill file, zip it up in a directory and upload it to wherever you like. I actually use JLC at the moment, and they will decode the zip, work out what layer is which for you, figure out what layers are internal, silkscreen, mask etc, and tell you how much it costs. It’s pretty simple. I wouldn’t be surprised if someone has written a KiCAD plugin to make it even easier actually. FYI the pathological example of logical vs physical symbols is the use of individual gates, which become nearly indecipherable when a physical representation of the package is used, compared to it its logical symbol. Consider also the realistic possibility that you might decide you only need one NAND gate on a board and could swap out that quad ‘00 for a single gate package. Check out some old computer schematics for a nice illustration of what to aim for. Someone “digitised” the Amiga schematics and they are like art. 😊

Seems to me he’s going for a more RISC style instruction set, which lends itself to a more hardwired instruction opcode decoding. I too was wondering about the timing issues - surely, toggling the latch enable at the same time as the address LSB will cause something of a race. I was a bit surprised that it seems to work so well! (Actually, he does explain why it works further down this thread - it seems the ROM is way slower than the latch, so the latch has effectively stored the old value before the ROM’s data lines being to transition to the new value. Cool.)

I wanted a setting where instructions have a fixed length and somewhat rigid layout. For operation at 1 or 2 instructions per cycle, you need to be able to decode the instruction in a single cycle, including all operands. Variable length encoding makes this much more annoying, especially when you decode two instructions in parallel. (Although it's a very attractive thing in "subscalar" designs where you have multiple clock cycles available per instruction.) The wide instruction word is just to have enough registers and opcode space. If I had only four registers, I could have at most 16 different two-operand 8 bit instructions. With eight registers it would be down to 4 instructions. So the 16 bits were a necessity.

@simontillson482 The timing feels pretty wonky at first 😃. In synchronous digital design you want to have all your signal toggles launched exactly at the clock though. This works here as well since the hold time of the latch (time after the clock that the data needs so stay stable) is around 1-2ns, but the contamination delay of the ROM (time between changing an input and seeing first changes at an output) is somewhere around 40-70ns. I've seen a little bit of instability in the ALU though that is likely related to the latch not holding its data for long enough after it becomes transparent (propagation delay faster than the hold time in the ALU flags register).

😃

Thanks! 😃 Basic pipelining will definitely come into the picture.

That's a great idea! I've been toying with the thought of taking the assembler and building out a simple IR and register allocation, to conceptually explore what LLVM and other compiler backends do. Adapting LLVM for my CPU would be a very nice thing to do 😃

Absolutely! Once the assembler supports expression evaluation, a lot of cool other features get unlocked in a sense. I like the idea of having segments like `text` and `data`, and allowing the user to lay those out in memory. Also, having the ability to plop down data and strings would be really handy.

Thanks! 🙂 `:=` assigns the value on the right to the variable on the left, and also returns the value on the right. It's a nice way to check if a value is not none in an if, and then have the value available in a variable inside the if block.

It's called the walrus operator. Which is kinda cute.

@DavidLatham-productiondave Haha, I love that name 😂

I haven't really played around with it. The prospect of writing an assembler totally from scratch was too exciting 😅

@@fabianschuikiyes indeed! I will probably look at it eventually. One of the thing CustomASM can’t do (AFAIK) is generate linkable objects, so you end up with includes to bring in your “modules”. It works, but it’s not nice. I shall have a look at your other videos later; I’ve never been brave enough to build a processor on breadboard and have massive respect for folks who take this on!

Thanks! 😃 Trying to be a bit more on-point 😉

That is a fantastic suggestion, thanks a lot! Will definitely add those 🙂👍

I also use unnamed labels in ca65. An unnamed label is a : by itself. Then you can branch to a count of unnamed labels in forwards or backwards direction. Unnamed labels are scoped from the previous normal label until immediately before the next normal label. Eg.(6502) ``` count_to_65536: ; here unnamed labels are scoped to count_to_65536 ldx 0 : ldy 0 : iny beq :- inx beq :-- next_lable: ; here unnamed labels are scoped to next_label ```

@DavidLatham-productiondave That's a pretty neat approach! I like how this doesn't clutter the text at all. The relative labels I have implemented tend to be just `1:` and `2:` in practice... Makes sense to leverage that and provide more compact syntax! 👍

Yeah, it was about time to add those 😁

Thanks! 🙂 It comes in pretty handy for testing more complicated behaviors of your PCBs.

Yes, at a later point I'll start adding pipeline stages in the places where they make sense. It's a good idea though to quickly sketch out on paper what kinds of chips you have feeding into each other, and then sum up the propagation delay along those paths. The adder is pretty fast, probably 1/4th of the time a ROM-based decoder would take to produce an output. AND/OR/XOR and multiplexers are going to be even faster. So you can probably rack up quite a few adders or logic chips in your ALU before they start making your CPU slower (because they overtake the decoder as criticial path). Keeping the ALU paths separate for the different functions is a nice idea! That would likely take quite a few additional chips because you have to replicate some work (XOR for subtraction in parallel to logic ops, maybe some redundancy in the logic ops?) but you should be able to get a bit more speed out of it 👍

Hey, thanks for the kind words! 😃 The font is Iosevka.

Thank you for the kind words! 🙂 You can definitely replace the ICs with through-hole variants on the PCB. Thinga are going to be a whole lot bigger, which may become a nuisance later on. Especially with superscalar execution things like the registers are going to require quite a few additional chips. You could completely change the buildup and swith to a backplane into which you plug the PCBs with a card edge style connector. That could be really cool, and it buys you a lot of space for through-hole ICs 😃🥳

As someone who stuck rigidly to throughhole for probably a decade, I can strongly recommend you give SMT a crack. It is not nearly as hard as it looks, nor is it expensive in terms of equipment. A hot air station and basic standalone microscope is all you need to learn. Stick to 50mil SO and SOIC parts, with 1206 resistors and you are good. You will not regret it. I laughed at one of Fabian’s comments when he said that he really hoped the orientation on some parts was correct in a build; swapping say an LED is a 10 second job vs many minutes, if you are fortunate and own all the tools, on a throughhole LED.

Thanks! 😃

Thanks for the kind words! 🙂 Lots of PCB work incoming to make room for more pipeline fun 👍

@@fabianschuiki I genuinely can't wait, I've seen several circuit board processors but they all tend to be simple. I wrote a Gameboy emulator in C++ and while the simple/early processors can help you understand the basics of modern ones, it doesn't give you a real feel for how modern out-of-order superscalar processors actually got this fast, so seeing someone actually implement some of these features could be really useful, for me and for anyone else interested in CPU design or low-level programming :)

😃 That is my hope for this project. There are a lot of pitfalls and ways for the complexity with discrete ICs to get out of hand though. It's quite a balancing act.

🙂Thanks!

You're totally right, that's a great point! 👍 Without the explicit check for KeyboardInterrupt I'm silently stopping on any kind of exception, with no useful error message. Thanks! 🙂

I would even leave out the 'except'. This is a good use case for 'finally' which is used to clean up regardless of whether an exception was raised or caught.

@dzhong111 Ah that's a great point! Thanks 👍

😃

Thanks! 🙂 Yeah I also can't wait to see that. Finally some order to the chaos. 😅

​@@fabianschuikiI hope you won't need bog-wires... 😮😅

First time right? Fingers crossed 😃

They are considered good practice on the supply rails because of how digital circuits operate: when the clock signal goes from 0 to 1, all chips start to toggle and change at the same time, until all values have been computed and the changes have died down. Each of these chips toggling require energy that they draw form the power rail. So when the clock happens and the activity starts, there's a sudden huge rush of current being pulled from the power rails. Especially on breadboards and through long power cables the power rail can't immediately serve that current, but there's a certain inductance/reluctance that causes the current to slowly ramp up (like trying to abruptly move a heavy object). The capacitors add a local reservoir of energy that is close to the chips, which can supply current over a much shorter wire and inductance. This evens out the power drawn over the main power cable.

Thank you very much! 🙂 I'm glad the series is useful and motivates you to do a series too. I'd totally watch that 😃

Great point! 🙂 On the one hand I plan to have conditional jumps as you say, with jump offsets encoded as immediates. (With proper instruction decoding, jumps can use the rd operand bits as condition code, which leaves the upper 8 bits for the immediate.) But you should also be able to compute the offsets with labels in the assembler, for example as `ldi r4, (exit2-loop2-2)`.

@fabianschuiki the value of the address of the label is available in the Layouter part. So you need an Operand kind "Expression" and "Label" that can be resolved in the 2nd iteration of Layouter (first iteration is getting the value of the addresses with "label opcode" like "loop:" and "exit:" , 2nd iteration is resolving the "label operands" and "expression operands" where label values are used). For each Opcode where a Label operand is used, in the Layouter you resolve the "Imm operand". For example if inst.opcode == Opcode.JRELI, change the "Label operand" for the "Imm operand" with the value of Label address - current_address, which gives the proper Immediate jump value (ahead or back, + or -).

@KeesJanLogemann Yeah, this sounds great! 😃 Having at least a limited form of expressions available is going to be very useful 👍

​@@fabianschuiki​​ it took me some posts to realize UA-cam comments with links are destroyed 😢 To use "plain labels" for the jreli opcode, I forked your GitHub superscalar-cpu to mine (kjlogic) and added label support. Find the repo at / kjlogic / superscalar-cpu / assembler Use at your convenience 😊

@KeesJanLogemann That's awesome! 🥳 Thanks for the pointer 😃 Very convenient 😏

🙂

Not yet unfortunately 😕. I recorded the testing and the ALU build in the last episode in one recording session without time in between to react.

Thanks 🙂! If I remember correctly, the Arm instruction set had a feature that sounds like what you describe. There were some conditional prefixes you could attach to instructions (or they might have been part of the instruction itself), which allowed you to only execute them under certain cirumstances. I'm not sure if that applied to all instructions, or whether that was limited to a certain subset.

And I think there's definitely room for multiple ALUs. Once we move to superscalar execution, we'll want at least two ALUs to showcase how that can help with performance. If all goes well, I'll end up with a reservation station for the ALUs that collects instructions to be executed, and then you'd have two ALUs that work on executing those instructions once they are ready.

Thank you very much for the kind words! 🙂

For a microprocessor implementation testing and validation is absolutely key to success. You have to test every permutation because you never know when an operation on the edge of timing conditions is going to start randomly failing. This project is following best practice in this respect and as it becomes more complex and clock speeds get ramped up this will really be invaluable. The reason ARM is so successful is precisely because their testing and validation systems are so extensive and complete. Testing is essentially most of the value of that company and extremely time consuming and expensive to implement which is why so many companied license ARM architecture rather than creating their own.

@@schrodingerscat1863 Did I say or indicate that he shouldn't test? I merely suggested that doing it on camera makes for rather drawn out segment. I agree that comprehensive testing of each function is mandatory, just that it doesn't make for great content. And I certainly didn't suggest that my view was any more valid than anyone else's.

@@OscarSommerbo Your OP didn't really make that clear, seemed to suggest that thorough testing was time wasting in my reading of it. I think showing the full testing process gives a realistic representation of how hardware design is done and how long testing takes compared to knocking up the circuit to test.

@@schrodingerscat1863 I might have misplaced a comma. My opinion is: Testing is essential, showing testing can get boring. "Can get", different viewers want different things, I was merely stating a preference, and since I am not making these videos I have no actual input.

@@OscarSommerbo It's a good point, the editing on the presentation could be tighter.

From a hardware design perspective, it's much easier to just add more GPRs than design SPRs. If you want to offload counting from the ALU, since this is supposed to become a superscalar, the way to go would be to add an increment/decrement unit that can operate independantly.

@@Artentus or more ALU's

😂 Oh yeah, I definitely need a ZIF socket. The sad part is that I had a whole box of ZIF sockets sitting around for two years, but their legs don't mate with the breadboard properly. So yeah, moving to PCBs is going to be fantastic for the ROM chip's legs 😁 SPA day! I will definitely be adding a set of special purpose registers, but more along the lines of the Control and Status Registers (CSRs) in RISC-V: basically an input/output feature of the CPU to break out of the tightly-controlled and timed out-of-order and superscalar pipeline, and get a simpler interface with just address, data, and a read/write strobe. That will allow you to have non-critical registers such as cycle counters, an LCD display, UART, and more, in a way that is still tightly coupled to the CPU, but outside the tight constraints of the pipeline. A counter register like you mentioned would be pretty interesting. I remember seeing that on other CPU architectures, mainly Digital Signal Processors, as "hardware loops". They do interfere with the instruction fetching and superscalar execution in potentially annoying ways -- I'll need to think about whether something like that can be integrated. It could be a nice frontend-only piece of hardware, but it adds state to the pipeline which is very tricky to handle during context switches and interrupts.

My thinking for a counter register was to use 74hc191 presetable up/down counters. You load with a value to want to count to, and every time you enable it, it counts down one and then raises a flag once you get to zero which you can check with a conditional jump instruction. The advantage is you can have the ALU speculatively executing what would happen if the flag isn't raised.

@JaenEngineering Yeah that sounds very neat! And in case an interrupt happens or you context-switch into the operating system, you would read the current count and store that as part of the state, and then later restore it when you resume execution of the program. That might work! 😃

Yeah that would have been a pretty nice idea! 🙂 You could probably fit the entire condition matching circuitry into a single 16V8 PLD. I'm trying to avoid using PLDs for everything because they could essentially absorb almost all logic in the build. Maybe you could have a maximum-PLD build that tries to use them to their greatest potential. They do also have a few downsides however, especially in terms of power consumption. I haven't really figured out a rule for myself as to when a PLD is okay, and when I'd rather use discrete chips. But for something like the circuitry in this episode, where almost all gates in the chips are actually utilized, having discrete chips instead of a PLD feels okay. But your point definitely stands: this could have been a PLD 🙂

The relative base is for future versions of the CPU where the instruction fetch is pipelined: the PC would keep advancing to fetch instructions from the ROM, which may take a couple of cycles to arrive at the instruction decoder and to be decoded. If it's a relative jump, the base address of the juml has to be the PC of the decoded instruction, and not what's currently in the PC, since the PC has already continued on in order to fill the pipeline. MIPSy 16-bit CPU definitely sounds like a UA-cam series worth watching 😏

Agreed, that would have been a nice design point as well 🙂. My thinking here was that I wanted to always have the address of the next instruction available, to have the option of storing it to a return address register. If I use only one adder and select between step/relative offset with a mux, I no longer have access to that address.

@@fabianschuiki If you want to grab the absolute value to return then you can do so from the adder - just set it so it would point to the next instruction after the jump, you grab it synchronously with doing the absolute PC load ;-) You want to go back to the next instruction after the jump anyway, right? BTW I'm really enjoying these series :-)

@akkudakkupl Thanks! 😃 It's great that you share your insights, ideas, and suggestions 🥳. Regarding the absolute value of the return address: I think you're right if you're only ever doing calls to absolute addresses. Which, to be fair, is probably a sensible limitation. I was trying to give the PC the capability to perform a relative jump while at the same time producing the instriction address after the jump as the return value. For this I need two adders: one to compute the next/return address, and one to compute the relative jump target.

Yes you're right! Misspoke there in the heat of the battle 🙂

Peasant! That's an "octothorpe". 😤

😂

Hmmm, I think it should work like any other signed number 🤔 I'll have to recheck that carefully though. Thanks for the pointer!

That's a great suggestion! The parsing, printing, and encoding is highly repetitive, and there are only 3 or 4 distinct instruction formats. I'll definitely move to a table-based approach in the future 🙂

😃 Yeah they definitely need to be tied off.

@@fabianschuiki I left a comment on your assembler video (last part), IDK if you get notifications on old videos. Very nice watch after the first two, I must say. Skimmed the second two a bit because I had and idea that might make your life easier and just had to comment. I'm certainly going to follow this like the James Sharman CPU series :-)

@akkudakkupl Thanks 🙂! Labels and a table-based approach are going to make the assembler a lot nicer to work with and extend 🥳

😃 Yeah I should. I think I have a license for it lying around somewhere.

Thanks! 🙂 I'm learning a lot about x86 and its humble beginnings by going through these circuits. I did most of my work on more modern RISC-style architectures, where flags are mostly absent. It's great to work with them for a change! Although I can totally see why they will become very annoying once you're trying to do out-of-order execution 😬

@@fabianschuikiI thought that the flags register in OoO CPUs gets renamed like any other architectural register. Microbenchmarks e.g. on the Firestorm cores in Apples A14/M1 suggested that it has a flags register file of 128 entries. It’s on the other hand astonishing that all the needed logic can be implemented with so few components..

@janhofmann3499 Yeah I think when you move to OoO execution, you promote the flags register to just yet another register. And all your ALU instructions have an implicit flags register operand that is read and/or written. That makes it almost just a compression scheme in the instruction set which makes certain register operands implicit. It's kind of fun to think about, but I also get why more modern ISAs like RISC-V skip flags entirely 🙂

Yeah I felt bad about not being able to use that output. It's already there! 🙂 But the XOR gate was already there, so I didn't even have to add another chip. 😃