
Designing a RISC-V CPU in VHDL: Arty S7 RPU SoC - matt_d
http://labs.domipheus.com/blog/designing-a-risc-v-cpu-in-vhdl-part-16-arty-s7-rpu-soc-block-rams-720p-hdmi/
======
rbanffy
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
I'd rather they be dumber. There's too much input latency in modern hardware
as result of all the smart layers.

~~~
andai
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
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
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.

------
pjmlp
Brownie points for choosing VHDL. :)

Nice article.

~~~
anyfoo
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.

~~~
nickik
You should checkout Chisel.

[https://chisel.eecs.berkeley.edu/](https://chisel.eecs.berkeley.edu/)

Its a HDL in Scala. It used extensively by Berkeley for things like the Open-
Source RISC-V Rocket and Boom SoC chips. There are lots of projects based on
it and you have some of the best open-source cores implemented in it.

See:

\- [https://github.com/freechipsproject/rocket-
chip](https://github.com/freechipsproject/rocket-chip)

\- [https://github.com/ucb-bar/riscv-boom](https://github.com/ucb-bar/riscv-
boom)

~~~
monocasa
And I'm going to throw out there that, unlike most of the "software language
used as HDL" crap you see, Chisel is fundamentally different and better for
it.

It's not really compiling Scala to a netlist; it's more that you're writing a
Scala program who's output is a generated netlist. It's pretty fantastic to
use.

~~~
nickik
Its actually a frontend that compiles to FIRRTL and the idea is basically that
FIRRTL is like LLVM bytecode. All the optimization run on FIRRTL.

The idea is that eventually different people will use different methods to
produce the FIRRTL.

~~~
monocasa
Sure, but FIRRTL is a netlist format.

------
slededit
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)

------
rbanffy
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.

~~~
gh02t
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.

