6 ms·

Designing a RISC-V CPU in VHDL: Arty S7 RPU SoC

80 points by matt_d 8y ago

rbanffy 8y ago
Someone really needs to publish a nicer font in an easy-to-integrate way for these projects. This MDA/EGA/VGA thing hurts my eyes.
- pjmlp 8y ago
  You just brought me back memories of EuroPC computers. :)
- gh02t 8y ago
  The article looks to be using screenshots from the FPGA IDE (Xilinx Vivado in this case), which is probably why they look so bad. The later snippets are using actual text and look a lot better, at least on my screen. FPGA design is really really complicated and most of the development environments for them look like a hot mess because they have to cover so much functionality. Vivado is actually one of the sleeker tools available.
rbanffy 8y ago
It's a bit disappointing that, at a time all monitors have enough memory and brains to display images out of their own memories (to say nothing about doing complex image operations on incoming video in real time), they still need perfectly timed pixels.
- dleslie 8y ago
  I'd rather they be dumber. There's too much input latency in modern hardware as result of all the smart layers.
  - andai 8y ago
    There was a post here recently that measured hardware latency of modern computers and 80s computers and found that, in a modern computer, in the time it takes for a keypress to leave the keyboard's circuits, an 80s computer has already drawn the letter on the screen. A USB keyboard, incidentally, has more transistors than an Apple II.
    - Koshkin 8y ago
      I still have no idea what was so wrong about the RS-232 as the keyboard and mouse interface that it had to be replaced first with PS/2 and then USB.
      - akiselev 8y ago
        IIRC, there were quite a few economic/technical reasons why PS/2 has gone largely extinct. RS232 and PS/2 are hardware interrupt driven instead of using polling like USB so they have always had a relatively high opportunity cost. Nowadays you'll only see PS/2 ports on workstation motherboards with higher end chipsets (which have more lanes on memory/PCIe buses, more hardware interrupts available before they need to be coalesced into software interrupts, etc). Also, PS/2 wasn't (generally) hot-swappable back then. That annoyance and some extreme pricing competition in the 2000s drove everyone towards USB.
  - rbanffy 8y ago
    I don't mind they accept pixels. What I mind is they require pixels to be carefully timed as if we were still chasing an electron gun. I should be able to send pixels at any rate I want. I should also be able to send blocks of pixels to specific screen coordinates, control individual pixels and query the screen about its contents in a sensible way.
- rwmj 8y ago
  If you don't need actual HDMI and a regular monitor then there are other solutions which are more like what you describe: Firstly there are simple character LCDs which all have a standardized and simple electrical interface[1] for sending ASCII characters and control codes. Then there are bit-addressable colour displays that let you send drawing commands, eg: [2] [3] [4] [1] https://www.youtube.com/watch?v=hZRL8luuPb8 https://www.youtube.com/watch?v=hZRL8luuPb8 [2] https://www.adafruit.com/product/1770 https://www.adafruit.com/product/1770 [3] https://www.vizictechnologies.com/smartgpu-2 https://www.vizictechnologies.com/smartgpu-2 [4] https://www.aliexpress.com/item/3-2-inch-37PIN-TFT-LCD-Screen-ILI9320-Drive-IC-240-RGB-320-No-Touch-Panel/32579843844.html https://www.aliexpress.com/item/3-2-inch-37PIN-TFT-LCD-Scree...
- akiselev 8y ago
  They're digital electronic signals. They all need to be "perfectly" timed, regardless of whether it's HDMI at 40 gbps or UART at 9600 bps. Moving logic to the monitor doesn't change the laws of physics, the FPGA will still have to time the data signals going over to the monitor. Except, ever notice how much more bandwidth your GPU has access to on the PCIe bus than your monitor does through HDMI? PCIe x16 was pushing 40 gbps (unidirectional only, doubles to 80 gbps for two-way) a decade ago and we only got HDMI2 a few years ago.
  - rwmj 8y ago
    This is not really true. Character based LCDs have data signals which are latched by an external "enable" pin. You can feed the commands and characters in at any speed you want, or at irregular intervals if you like.
    - akiselev 8y ago
      That's why I put "perfectly" in quotes. The only way to make a perfectly timed signal is to be precise down to one plank. That's obviously a ridiculous definition because we can't even make any hardware that can differentiate such precise inputs. Perfectly timed in EE means to within operating specs so that the chip does what you want. It's the only definition that makes sense. What you're describing, by the way, is a feature at the MAC level, not the PHY level (think signals vs data frames vs packets). The vast majority of ICs are all push based so they just continue normal operation when there is power but no other inputs. Your example still requires timing your clock/enable signal so that the ringing on data lines settles down before clk/en rises and the data doesn't change before the rising edge is detected.
  - rbanffy 8y ago
    They need to be synced to your clock signal, but there's nothing to prevent the signal source to also generate the clock pulses at any rate it finds convenient or even be irregular. In fact, being irregular removes a lot of EM interference sources. Think of asynchronous CPUs.
pjmlp 8y ago
Brownie points for choosing VHDL. :) Nice article.
- anyfoo 8y ago
  Though generally, mimicking imperative languages (C and Ada for Verilog and VHDL respectively) is just such a bad fit for the massively parallel, circuit combining nature of FPGAs. For my private projects (admittedly the only setting I currently use FPGAs for), I’ve since discovered clash, which is essentially Haskell for FPGAs, and am impressed how much more productive I am, how much abstraction a more fitting paradigm opens up, and how much more terse and readable the code is as a result. I came about searching for an alternative when I got fed up with reimplement the same AXI protocol schemes over and over again, mostly through slightly altered cut and paste, and have instead slowly been building my own library of commonly used patterns and AXI protocol abstractions. However, the one thing I’m not so sure about is whether I would be able to effectively use clash if I didn’t have any experience in using Haskell for software before, or whether I would be constantly banging my head against it just to finally give up instead. I suspect that the price of clash’s power of abstraction is a very steep learning curve.
  - pjmlp 8y ago
    I have read somewhere that Intel uses Haskell for formal verification, but public information is scarce.
    - KSteffensen 8y ago
      Standard tools for formal verification of RTL is either SystemVerilog assertions or PSL. In my (limited) experience these are expressive enough to not be the problem with formal verification. They must have some very specialized or large properties they want to prove if they decided to roll their own formal proving tool. That's not a small task. Of course, Intel does have more resources than most ASIC design shops.
    - orbifold 8y ago
      Intel uses SystemVerilog for implementation and most likely also verification, some of the verification features in the system verilog standard were actually contributed by Intel. At some point they were using a ML derivative called reflect https://www.cs.ox.ac.uk/tom.melham/res/reflect.html https://www.cs.ox.ac.uk/tom.melham/res/reflect.html in a verification environment called Forte https://www.cs.ox.ac.uk/tom.melham/res/forte.html https://www.cs.ox.ac.uk/tom.melham/res/forte.html. The implementation of Forte was open source at some point but sadly has (as far as I can tell) vanished from the internet. Here is a fairly recent presentation on formal verification by Intel (https://www.turing-gateway.cam.ac.uk/sites/default/files/asset/doc/1707/Big%20Proof%20Day%20Melham%2019-07-2017.pdf https://www.turing-gateway.cam.ac.uk/sites/default/files/ass...) Here is another mention of Forte (https://ptolemy.berkeley.edu/projects/embedded/esd-seminar/spring03/abstract/moondanos.html https://ptolemy.berkeley.edu/projects/embedded/esd-seminar/s...) the link there is dead and the wayback machine apparently does not index ftp servers unfortunately.
slededit 8y ago
If you want an open source DDR3 controller to go with your open source SoC I recommend LiteDRAM. Its getting pretty polished. https://github.com/enjoy-digital/litedram https://github.com/enjoy-digital/litedram

80 points by matt_d 8y ago

Someone really needs to publish a nicer font in an easy-to-integrate way for these projects. This MDA/EGA/VGA thing hurts my eyes.

pjmlp 8y ago
You just brought me back memories of EuroPC computers. :)
gh02t 8y ago
The article looks to be using screenshots from the FPGA IDE (Xilinx Vivado in this case), which is probably why they look so bad. The later snippets are using actual text and look a lot better, at least on my screen. FPGA design is really really complicated and most of the development environments for them look like a hot mess because they have to cover so much functionality. Vivado is actually one of the sleeker tools available.

rbanffy 8y ago

It's a bit disappointing that, at a time all monitors have enough memory and brains to display images out of their own memories (to say nothing about doing complex image operations on incoming video in real time), they still need perfectly timed pixels.

dleslie 8y ago
I'd rather they be dumber. There's too much input latency in modern hardware as result of all the smart layers.
- andai 8y ago
  There was a post here recently that measured hardware latency of modern computers and 80s computers and found that, in a modern computer, in the time it takes for a keypress to leave the keyboard's circuits, an 80s computer has already drawn the letter on the screen. A USB keyboard, incidentally, has more transistors than an Apple II.
  - Koshkin 8y ago
    I still have no idea what was so wrong about the RS-232 as the keyboard and mouse interface that it had to be replaced first with PS/2 and then USB.
    - akiselev 8y ago
      IIRC, there were quite a few economic/technical reasons why PS/2 has gone largely extinct. RS232 and PS/2 are hardware interrupt driven instead of using polling like USB so they have always had a relatively high opportunity cost. Nowadays you'll only see PS/2 ports on workstation motherboards with higher end chipsets (which have more lanes on memory/PCIe buses, more hardware interrupts available before they need to be coalesced into software interrupts, etc). Also, PS/2 wasn't (generally) hot-swappable back then. That annoyance and some extreme pricing competition in the 2000s drove everyone towards USB.
- rbanffy 8y ago
  I don't mind they accept pixels. What I mind is they require pixels to be carefully timed as if we were still chasing an electron gun. I should be able to send pixels at any rate I want. I should also be able to send blocks of pixels to specific screen coordinates, control individual pixels and query the screen about its contents in a sensible way.
rwmj 8y ago
If you don't need actual HDMI and a regular monitor then there are other solutions which are more like what you describe: Firstly there are simple character LCDs which all have a standardized and simple electrical interface[1] for sending ASCII characters and control codes. Then there are bit-addressable colour displays that let you send drawing commands, eg: [2] [3] [4] [1] https://www.youtube.com/watch?v=hZRL8luuPb8 https://www.youtube.com/watch?v=hZRL8luuPb8 [2] https://www.adafruit.com/product/1770 https://www.adafruit.com/product/1770 [3] https://www.vizictechnologies.com/smartgpu-2 https://www.vizictechnologies.com/smartgpu-2 [4] https://www.aliexpress.com/item/3-2-inch-37PIN-TFT-LCD-Screen-ILI9320-Drive-IC-240-RGB-320-No-Touch-Panel/32579843844.html https://www.aliexpress.com/item/3-2-inch-37PIN-TFT-LCD-Scree...
akiselev 8y ago
They're digital electronic signals. They all need to be "perfectly" timed, regardless of whether it's HDMI at 40 gbps or UART at 9600 bps. Moving logic to the monitor doesn't change the laws of physics, the FPGA will still have to time the data signals going over to the monitor. Except, ever notice how much more bandwidth your GPU has access to on the PCIe bus than your monitor does through HDMI? PCIe x16 was pushing 40 gbps (unidirectional only, doubles to 80 gbps for two-way) a decade ago and we only got HDMI2 a few years ago.
- rwmj 8y ago
  This is not really true. Character based LCDs have data signals which are latched by an external "enable" pin. You can feed the commands and characters in at any speed you want, or at irregular intervals if you like.
  - akiselev 8y ago
    That's why I put "perfectly" in quotes. The only way to make a perfectly timed signal is to be precise down to one plank. That's obviously a ridiculous definition because we can't even make any hardware that can differentiate such precise inputs. Perfectly timed in EE means to within operating specs so that the chip does what you want. It's the only definition that makes sense. What you're describing, by the way, is a feature at the MAC level, not the PHY level (think signals vs data frames vs packets). The vast majority of ICs are all push based so they just continue normal operation when there is power but no other inputs. Your example still requires timing your clock/enable signal so that the ringing on data lines settles down before clk/en rises and the data doesn't change before the rising edge is detected.
- rbanffy 8y ago
  They need to be synced to your clock signal, but there's nothing to prevent the signal source to also generate the clock pulses at any rate it finds convenient or even be irregular. In fact, being irregular removes a lot of EM interference sources. Think of asynchronous CPUs.

pjmlp 8y ago

Brownie points for choosing VHDL. :) Nice article.

anyfoo 8y ago
Though generally, mimicking imperative languages (C and Ada for Verilog and VHDL respectively) is just such a bad fit for the massively parallel, circuit combining nature of FPGAs. For my private projects (admittedly the only setting I currently use FPGAs for), I’ve since discovered clash, which is essentially Haskell for FPGAs, and am impressed how much more productive I am, how much abstraction a more fitting paradigm opens up, and how much more terse and readable the code is as a result. I came about searching for an alternative when I got fed up with reimplement the same AXI protocol schemes over and over again, mostly through slightly altered cut and paste, and have instead slowly been building my own library of commonly used patterns and AXI protocol abstractions. However, the one thing I’m not so sure about is whether I would be able to effectively use clash if I didn’t have any experience in using Haskell for software before, or whether I would be constantly banging my head against it just to finally give up instead. I suspect that the price of clash’s power of abstraction is a very steep learning curve.
- pjmlp 8y ago
  I have read somewhere that Intel uses Haskell for formal verification, but public information is scarce.
  - KSteffensen 8y ago
    Standard tools for formal verification of RTL is either SystemVerilog assertions or PSL. In my (limited) experience these are expressive enough to not be the problem with formal verification. They must have some very specialized or large properties they want to prove if they decided to roll their own formal proving tool. That's not a small task. Of course, Intel does have more resources than most ASIC design shops.
  - orbifold 8y ago
    Intel uses SystemVerilog for implementation and most likely also verification, some of the verification features in the system verilog standard were actually contributed by Intel. At some point they were using a ML derivative called reflect https://www.cs.ox.ac.uk/tom.melham/res/reflect.html https://www.cs.ox.ac.uk/tom.melham/res/reflect.html in a verification environment called Forte https://www.cs.ox.ac.uk/tom.melham/res/forte.html https://www.cs.ox.ac.uk/tom.melham/res/forte.html. The implementation of Forte was open source at some point but sadly has (as far as I can tell) vanished from the internet. Here is a fairly recent presentation on formal verification by Intel (https://www.turing-gateway.cam.ac.uk/sites/default/files/asset/doc/1707/Big%20Proof%20Day%20Melham%2019-07-2017.pdf https://www.turing-gateway.cam.ac.uk/sites/default/files/ass...) Here is another mention of Forte (https://ptolemy.berkeley.edu/projects/embedded/esd-seminar/spring03/abstract/moondanos.html https://ptolemy.berkeley.edu/projects/embedded/esd-seminar/s...) the link there is dead and the wayback machine apparently does not index ftp servers unfortunately.

slededit 8y ago

If you want an open source DDR3 controller to go with your open source SoC I recommend LiteDRAM. Its getting pretty polished. https://github.com/enjoy-digital/litedram https://github.com/enjoy-digital/litedram