LMARV-1 reboot part 2: the register card.

This part codes and formally verifies an async memory and the register card.
github repo for code: github.com/RobertBaruch/riscv...
nMigen tutorial: github.com/RobertBaruch/nmige...

[@xnooga]

That round light reflecting in your eyeballs and glasses is extremely trippy :D

[@RobertBaruch]

Yeah, I'm ditching it.

[@kalj7]

I am really happy you started working on this again. Such cool project! :)

[@fredo514]

This has to be the most complicated HDL language I’ve ever seen. It’s amazing you’re able to make it work! Do you know the formal verification engine you’re using can also be used with VHDL or verilog?

[@RobertBaruch]

It's isn't very complicated. It's just Python. True, there's a level of abstraction in that you're writing code to generate code (logic), but it's not a huge leap once you start using it. It was confusing for me in the beginning. That's why I wrote the tutorial to myself :) Yosys can read Verilog. However, be aware that no two Verilog tools support the same things because the Verilog standard isn't really all that practical.

[@marijnstollenga1601]

Awesome! LMARV is finally back! Sometimes when you look away from the camera, you are not really audible. Maybe there is a way to position the mic such that it picks it up in both directions? The light rings aren't too distracting. Is there some place where you document the planned architecture? Maybe would be nice to have in the repo to get an overview.

[@unkyuge]

I feel as if things could be presented better: Have you thought about deciding on an architecture for each functional unit and then taking the time to deconstruct it before our eyes? The idea of developing an architecture before our eyes is frankly ... exhausting. I also have the feeling that you're doing this for yourself and just taking us along for the ride. In that case, I completely understand the style you have chosen. It's probably a lot of effort for you too - so thanks for putting this out there for others to benefit from. Win-win for everyone already, but thought I throw an alternative idea out there fpr you to consider. I'll still watch them all!

[@ab0tj]

The ring lights were only distracting after you mentioned it

[@flutterwind7686]

Damn I'm so hyped

[@jamesrivettcarnac]

I find it strange that as a software developer, I find the formal verification harder to follow than the first attempt you made with the circuit diagrams. I expected that this would be easier to follow.

[@hermannpaschulke1583]

YES!

[@ThanassisTsiodras]

Thank you for these very educational videos, Robert! BTW, I checked your Github repo and don't see the code from this 2nd part there (I only see the transparent latch code).

[@RobertBaruch]

Ah, my bad. Thanks, updated.

[@kayakMike1000]

Why not get a pile of flip flops and whip up a decoder and multiplexer for the register file? Might be a bit biiig but would be pretty neat to put a bunch of LEDs on it...

[@tobiaspape]

That's mighty cool! But somehow I missed the part that _writes_ to reg0 are ignored, I only saw that _reads_ result in all 0.

[@hjups]

Writing to register 0 is irrelevant, since the contents are never read back. In an FPGA, you might do the opposite, where you inhibit writes to register 0, but allow reading. The difference here is that an FPGA can ensure that the registers are initialized to any value (i.e. 0), however, SRAM will have a random startup value, which is unique to the silicon die, so you can't rely on that. A solution would be to pre-initialize the SRAM, but that requires more logic, so the simplest solution is to just never read from register 0 and let garbage be written there which is impossible to read back due to the circuit design.

[@tobiaspape]

I just figured that writes to re0 are irrelevant, as reads never reach. Thanks to the commenters!

[@KBERGUE53]

I'm guessing I'm here way too late since you probably founda better solution in a video I haven't seen yet but for reg0 wouldn't it be way easier to just use a mux just before the X latch and the Y latch? Basically you just have your Y mem going to one of the input, a logic 0 going to the other input and control the mux with the address line added together? It would require 8 and gates and 2 2->1 muxes so not sure it's the cheapest option but it does seem easier than what you're explaining in your video

[@Schwuuuuup]

The reflections of the ring light clearly Stan out. It would be annoying if I had to constantly on your face. But most of the time I look at the code or diagrams anyway. With your glasses on they do more bad than good, and any light (even ones that illuminate you worse) would be better... But it is not a problem that is big enough to invest time or money

[@douro20]

I know it's impractical to implement in discrete logic but I wonder if there are any synthesizable RISC-V cores which use hard instruction coding like ARM does?

[@arnauddurand127]

What is "hard" instruction coding?

[@douro20]

@@arnauddurand127 Hard instruction coding is when instructions are implemented entirely in hardware rather than with microcode. Acorn designed the original ARM processors in this manner since they saw microcode as a potential bottleneck in instruction-per-clock performance.

[@AfterHoursEngineering]

I think this is also called a "control matrix" implemented as combinational logic.

[@hjups]

My understanding is that none of the RISC-V cores use microcode to implement their instructions. Microcode is typically a CISC thing. Did you perhaps mean without microprogramming? (that would be what a "control matrix" would be). The majority of the synthesizable cores don't use microprogramming either as far as I know, where they rely on combinational logic to do the decode instead - though the control matrix is implied because it's logically equivalent (lookup table vs logic gates).

[@RobertBaruch]

@@hjups Correct -- the instruction format for RISC-V was designed to be nearly trivial to decode.

[@hjups]

Another great video. Migen has always confused me, but you going through it seems to make a lot more sense (at least for combinational logic). So for a clarification question, when you say you want your CPU to be single cycle, do you mean single cycle execution stage? Or single cycle for the entire instruction (fetch, decode, execute). Right now what you have is a 2+ cycle / stage CPU, where you do a fetch and / or decode, and then do an execute + write back. If you were to do at least a decode + execute + writeback, then you need to break up your clock phases a little more - you can't assume that the control signals will be valid until some later stage in the cycle, since decoding will take time. Also, I'm not sure if your register zero method will work correctly, since you are going to have a propogation delay between the OE signal and driving the lines low, which could result in a "short". Assuming you are only doing execute in a single cycle, you may want to drive the RAM OE signal from the external control logic for phases 1-5, but not phase 0, which gives your zero read logic time to determine if it should surpress the OE signal. To do your zero checking, typically in silicon, large NAND gates are used - so a 5-input NAND gate for 32 registers where the result is 1 if they are all 0. You can also use a 5-input OR-gate where if any input is 1, the output will be 1 (so ~is_zero). One possible solution to drive the register outputs low for register zero could be to use an open-collector driver. FETs would probably be too combersome since you would need 64 of them, but you can get NPN BJT arrays in packs of 4. That might reduce the maximum possible speed though since they aren't particularly fast. You could probably also get away with not worrying about bus collisions if you took that approach as well, since you could add pull-up resistors to the SRAM output which are probably push-pull. So the circuit would go RAM Bus tap NPN GND. The NPN would drive the bus low when it needed to regardless of the RAM output value, and when the NPN is disabled, the bus will float with the push-pull voltage of the RAM. One issue there could be the resistor value though, you want it high enough that you don't draw too much current when the RAM output is 1, but you want it low enough that you have are able to drive the attached devices (i.e. pass the VIL and VIH thresholds).

[@RobertBaruch]

That's a lot to unpack. Let's see... okay. Since I haven't designed the entire thing yet, I can't say what the final cycle count will look like. That's why I'm designing it fully in software first. My goal is to have as much happen in combinatorial logic as possible, without going crazy with hardware. As for the OE on the RAM, you could be right. The turn-off time for the RAM output is 6ns while the enable time for the latch is more like 2.5ns. I'd rather not use resistors if I don't have to, that would only slow things down. I don't think it's a big deal to idle things during phase 0. I'd still have phases 1 and 2 to do "work". Another alternative that I've been eyeing up is using a multiplexer instead of buffers. There are 2:1 16-bit multiplexers based on FETs.

[@hjups]

​@@RobertBaruch I would say that it would be important to figure out if you want to do decoding an execution in the same cycle, but you could always add more clock phases / slow down the overall cycle if you decide that you want to do that. The issue with phase 0 idling is that you need more clock pulses. However, you could probably co-opt your phi2 clock to do that, since you have the longer phi1 pulse to determine if it's reading or writing. That could be tricky though, because you want to minimize switching, so you would have too choose the logic carefully (you don't want to enable OE when phi1 switches from high to low). Multiplexers will probably be a good solution, since it's fewer chips and cost probably isn't that big of an issue. It would be equivalent to an un-optimized synthesis of "if(x) y else 0". Another thing you could do is just mask it. Use AND gates for the RAM output, and use an inverting signal so you have out = RAM AND ~isZero. AND gates might be cheaper / less overkill than a mux. You may want the choice to come down to the pinout of the chip - which is easier to route.

[@d95mback]

Do you have to write "signal == 1" or can you just write "signal"? Seems a bit cluttery to write "== 1".

[@RobertBaruch]

Probably just "signal" is fine if it's one bit.

[@GeorgeTsiros]

face reveal, woooo! "WE is HIGH" no we're certainly not! 😳

[@anshul493]

can you add sound , video hardware,TCP/IP stack,build compilers(C language), operating system(UNIX-Like,minix would be fine), middleware stack,TCP/IP (should at least serve web-pages,etc.) and application programs.please support telnet sessions also. basically the whole complete system (not just the cpu which is useless by itself)

[@jamesrivettcarnac]

I2C/serial, and PS/2 is probably minimum. And some storage of some kind, unless you're fine with flashing ROMs for everything you do.