Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Designing a RISC-V CPU, Part 1: Learning hardware design as a software engineer

mcla.ug

Post reply on HN
Print view View original

11–20 of 32 posts

Re: Designing a RISC-V CPU, Part 1: Learning hardware design as a software engineer

#11

Post by randomskk »

cillian64 wrote: post #7

Is 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'm about 20kloc in to a (not public) nMigen project, including a UDP/IP stack, various peripheral drivers, a DSP pipeline, and some custom networking code. So far I think "do the advantages of being able to metaprogram outweigh..."is a resounding "yes", but I came to it with extensive Python experience so it feels like a very natural fit to me, and given how other attempts at embedded metaprogramming go (Tcl...) I'm not sure Python is easily beat. Being able to integrate with numpy for DSP work, pytest for simulation and testing, Python packaging (such as it is) for distributing modules and managing dependencies and versioning, and simulating inside Python too are all additional compelling advantages.

nMigen is a pretty fledgling project so there aren't a ton of big projects in it yet, but for example Luna[0] (from the makers of the HackRF) implements a full USB stack including USB3 support, with enough abstraction that you can create a USB-serial converter inside your FPGA using two I/Os for full-speed USB and wire it into the rest of your project in about ten lines of Python[1].

[0]: https://github.com/greatscottgadgets/luna [1]: https://github.com/greatscottgadgets/luna/blob/master/exampl...

Migen, the Python-based project nMigen is based off, has been around for longer and has some large projects, such as LiteX[2] which uses Migen to glue together entire SoCs, including peripheral cores such as GigE, DDR3/4, SATA, PCIe, etc, all written in Migen, and is pretty widely used. It also pulls in Verilog/VHDL designs (such as many of its CPU core choices) since it's easy to pull in those from the Python side.

[2]: https://github.com/enjoy-digital/litex/

Re: Designing a RISC-V CPU, Part 1: Learning hardware design as a software engineer

#13

Post by mikewarot »

NextHendrix wrote: post #5

For 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 why the LED brightness changed with the number of lit LEDs.

Hardware isn't the same as software... it's easy to forget that sometimes. 8)

Re: Designing a RISC-V CPU, Part 1: Learning hardware design as a software engineer

#14

Post by cillian64 »

diarmuidc wrote: post #12

Migen looks good but avoiding HDLs while trying to learn hardware design is not the best learning approach. They might be ugly languages but the do force your to think in hardware and gates.

That’s interesting, my first impression of nMigen is that it looks like it does a much better job of forcing you to think in terms of the hardware you’re describing, compared to verilog which can lull you into just writing a sequential program.

Re: Designing a RISC-V CPU, Part 1: Learning hardware design as a software engineer

#15

Post by dw-im-here »

If you want to learn hardware design in chisel (RTL level HDL implemented in scala), I would give this project here a huge recommendation (I'm the author): https://github.com/PeterAaser/RISCV-FiveStage.

It's coursework that takes you from knowing nothing about hardware design to designing your own RISC-V In-Order Five stage architecture. As far as I know a few students have actually done the work to run this on an FPGA, but for the most part you will have the luxury of an emulator, giving you things like stack traces compared to the model execution for all the test programs etc. Execution trace example shown here: https://github.com/PeterAaser/RISCV-FiveStage/blob/master/Im...

Re: Designing a RISC-V CPU, Part 1: Learning hardware design as a software engineer

#16

Post by nickmqb »

cillian64 wrote: post #7

Is 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…

Shameless plug: I had a similar impression when looking at nMigen, but wasn't super happy with Verilog either, so I wrote a new HDL called Wyre [0]. No metaprogramming, but a Verilog-like language with a focus on ergonomics instead. I'm currently making a basic Minecraft clone for the Lattice iCE40 with it.

[0] https://github.com/nickmqb/wyre

Re: Designing a RISC-V CPU, Part 1: Learning hardware design as a software engineer

#17

Post by cbm-vic-20 »

Robert Baruch recently re-booted his "Build a RISC-V Processor without using an FPGA" series[1]. His approach is heavily dependent on nmigen and formal verification. Check it out.

[1] https://www.youtube.com/watch?v=YgXJf8c5PLo&list=PLEeZWGE3Pw...

Re: Designing a RISC-V CPU, Part 1: Learning hardware design as a software engineer

#18

Post by bogomipz »

The 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 even't driven is in Javascript web app, GUI etc? I'm having trouble wrapping my head around it in a digital circuit context. Also in second part of that passage wny would manual coding be unnecessary for synchronous circuits?

Re: Designing a RISC-V CPU, Part 1: Learning hardware design as a software engineer

#19

Post by bogomipz »

lochsh wrote: post #10
designlikedigi wrote: post #2

Does part 2 exist yet? This is basically an explanation of what FPGAs are and a "hello world" nMigen example. That said, high-level HDLs like nMigen are very promising for education, and I hope more people take the same first steps as the article's author did. It's a fun field. And along those lines, here's hoping that MIT updates their free 6.004 edX course to reflect the in-person class' new RISC-V focus soon.

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?

Re: Designing a RISC-V CPU, Part 1: Learning hardware design as a software engineer

#20

Post by vzidex »

bogomipz wrote: post #18

The 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…

> Can someone say is "event driven" in the context of an HDL different than say what even't driven is in Javascript web app, GUI etc? I'm having trouble wrapping my head around it in a digital circuit context.

I think what they mean is that when you're defining synchronous logic in (System)Verilog or VHDL, the behaviour of that synchronous logic is defined as being in response to an event. For example, look through a Verilog codebase and you'll probably see lots of blocks that look like the following:

  always @(posedge clock) begin
      ... // Some logic
  end
What that block says is that the logic defined inside it - most often writing to some sort of storage element, or sampling a signal - will trigger at every positive edge of the "clock" signal, which is the "event". Usually, people will work in more control signals like a clock enable, reset, etc. to make it do more interesting things.
Post reply on HN