Has anyone worked with BlueSpec https://github.com/B-Lang-org/bsc How does it compare to nMigen. Recently heard oxide computer folks talking about it and they were all gungon about it.
Designing a RISC-V CPU, Part 1: Learning hardware design as a software engineer
21–30 of 32 posts
Re: Designing a RISC-V CPU, Part 1: Learning hardware design as a software engineer
#22Earlier quoted context omitted.
I'm hoping to write part 2 this weekend or next week -- I realise anyone knowledgeable of logic design won't be super excited by this first installment. It's intended mostly for people who are new like me! I look forward to writing in more detail about RISC-V and my cpu design :)
Looking forward to reading part 2. Can you or someone else say recommend some resources/tutorials for learning nmigen? Or are the official docs still the best source?
I've had this recommended and it looks v promising! https://vivonomicon.com/2020/04/14/learning-fpga-design-with...
Someone above has mentioned Robert Baruch too: https://github.com/RobertBaruch/nmigen-tutorial
I also found this helpful: http://blog.lambdaconcept.com/doku.php?id=nmigen:tutorial
And there is of course the IRC channel if you want to ask people questions, #nmigen on irc.freenode.net
Re: Designing a RISC-V CPU, Part 1: Learning hardware design as a software engineer
#23The author states the following: >"Despite being faster than schematics entry, hardware design with Verilog and VHDL remains tedious and inefficient for several reasons. The event-driven model introduces issues and manual coding that are unnecessary for synchronous circuits, which represent the lion's share of today's logic designs." Can someone say is "event driven" in the context of an HDL different than say what e…
Conceptually HDL is actually very similar to those cases, but with an important difference: simulated time. In an HDL simulator, the simulator starts executing by running code designated to run at time 0 (in Verilog, this is specified using an "initial" block).
Looking first at combinational logic: As the simulator goes through the "initial" code, it will set variables to new values. These value changes will activate event listeners throughout the code ("always @ *" or "assign" in Verilog), which represent combinational logic. So if variable "myvar" is updated, and it is an input to an adder in some other module, the always statement which updates the adder output will be triggered. Whenever a combinational event is triggered here at time 0, it is "scheduled" to be resolved at time 0 + delta, where delta just represents a time after time 0, but before time 0.000...01.
Alternatively, you can schedule events with a specific delay, such as setting up a clock signal to wait 0.5ns and then toggle. You can then setup event listeners to react to the rising edge of this clock signal ("always @ posedge" in Verilog), giving you synchronous logic.
Typically, a simulation will involve a bunch of setup a time 0, combinationally getting every variable to its initial condition. Then there will be no more events scheduled at the current simulator time, so the simulator advances until the next time it has an event scheduled (such as the clock edge at 0.5ns). That value changes from that event will likely trigger many more combinational events that will be resolved before moving onto the next clock edge.
So, all of the scheduling basically works the same as event driven javascript, the big difference from what I can tell is that events are scheduled relative to simulator time, rather than real world time, and the time doesn't advance until everything scheduled for the current time has resolved. This lets us simulate the massively concurrent nature of hardware even using a single simulator thread.
When considering how this looks in actual hardware, you can still consider clocked elements as being event driven, but it's not obvious that it makes sense to think of combinational gates that way. Still, the tools are designed to construct a circuit that gives you the same result as the event driven semantics, as long as you meet timing constraints.
I'm not a simulator expert, so I may be slightly off in my explanation, but hopefully that gives you the general idea!
Re: Designing a RISC-V CPU, Part 1: Learning hardware design as a software engineer
#24Is anyone around who has implemented a substantial project in nMigen? Looking at the syntax it looks very unintuitive and awkward, mainly due to being shoehorned into Python syntax. Do the advantages of being able to metaprogram in Python outweigh the disadvantages of the syntax? (I’m comparing to a hypothetical HDL which is at a similar abstraction level but has a dedicated syntax and some other way of embedding met…
I'd be interested in this too, I'm all for improving on the standard HDLs, but from this example I see more downsides than upsides, mostly due to the fact the synatx looks very verbose. Part of the is because its layered on top of python, so even a simple switch must be written in a more elaborate way. The code shown in the example would be very readable in SystemVerilog and quite a bit shorter. Also how does somethi…
Carries are documented. Two n-bit numbers result in an (n+1)-bit number. The “n+1th” bit is obviously the carry of the result. Sign extension is handled by declaring a `Signal` as signed or unsigned during creation.
For example, both:
x = Signal(4, true)
y = signed(4)
I will agree with you on the syntax, however. It’s caused by the fact that you’re not synthesizing your program, but writing code that generates code.
nmigen is a library, not a language. So it has to use what’s available to it. The upside is you don’t have to write tokenizers, parsers, etc, but the downside is it looks “hackish”.
For example:
m.d.comb += x.eq(y + 1)
Robert Baruch has a nice tutorial on nmigen: https://github.com/RobertBaruch/nmigen-tutorial
Re: Designing a RISC-V CPU, Part 1: Learning hardware design as a software engineer
#25For software engineers wanting to get into hardware design, the most important thing to remember is that it isn't software, despite feeling a bit like writing software. Writing instructions and describing hardware are very different, regardless of how much a HDL may try to hide that difference with similar looking constructs.
As someone who had done both hardware and software for decades, I'd forgotten how much I had internalized until I saw a programmer friend try to optimize the parts count on a circuit with an arduino, 8 LEDs and 8 resistors. He knew that the resistor was to limit current, and he knew about parallel and series circuits, so he just used one resistor on the other side of the LEDs instead of 8 of them... and then wondered…
A big difference is also that things are sequential at the gate level. Everything happens at the same time. It’s almost like a massive multithreaded program. Also, propagation delays can make you pull your hair out if you aren’t aware of them when debugging. There’s also a possibility of unclean signals (not Vcc or GND, transition bouncing, etc.).
Re: Designing a RISC-V CPU, Part 1: Learning hardware design as a software engineer
#26Earlier quoted context omitted.
As someone who had done both hardware and software for decades, I'd forgotten how much I had internalized until I saw a programmer friend try to optimize the parts count on a circuit with an arduino, 8 LEDs and 8 resistors. He knew that the resistor was to limit current, and he knew about parallel and series circuits, so he just used one resistor on the other side of the LEDs instead of 8 of them... and then wondered…
A big difference is also that things are sequential at the gate level. Everything happens at the same time. It’s almost like a massive multithreaded program. Also, propagation delays can make you pull your hair out if you aren’t aware of them when debugging. There’s also a possibility of unclean signals (not Vcc or GND, transition bouncing, etc.).
One level of abstraction further down, Gates are analog, not digital. If you don't clock things right, you could end up with huge currents going through two transistors trying to drive something opposite ways, and then lose the chip, or battery life, or an intermittent glitch.
Re: Designing a RISC-V CPU, Part 1: Learning hardware design as a software engineer
#27Is RISC-V actually going anywhere?
Re: Designing a RISC-V CPU, Part 1: Learning hardware design as a software engineer
#28Is RISC-V actually going anywhere?
Yes. But it's just an ISA, someone has to design good silicon
Re: Designing a RISC-V CPU, Part 1: Learning hardware design as a software engineer
#29I know it isn't direct HLS, but I have to say that Python in EDA seems like a weak combination - even if it's effectively just glue code when I write python I'm just constantly hanging myself on nooses that wouldn't exist in a statically typed language (not good when you have to pay millions for a respin) What does the formal verification flow/s look like for it?
This! I'd rather write VHDL then migen. I really don't understand the obsession that the open source hardware community has with it. There are way better alternatives.
Re: Designing a RISC-V CPU, Part 1: Learning hardware design as a software engineer
#30Is RISC-V actually going anywhere?
Yes. But it's just an ISA, someone has to design good silicon
Last I remember, our main bottleneck is getting data to the cpu fast enough that it's not idling all day, so icreasing the number of instructions by a large margin sounds counterproductive. It'll be interesting to see where it goes.