▲ 80 points
back
32 comments
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.
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
[2] https://www.adafruit.com/product/1770
[3] https://www.vizictechnologies.com/smartgpu-2
[4] https://www.aliexpress.com/item/3-2-inch-37PIN-TFT-LCD-Scree...
I'd rather they be dumber. There's too much input latency in modern hardware as result of all the smart layers.
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.
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.
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.
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.
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.
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.
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.
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.
Brownie points for choosing VHDL. :)
Nice article.
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.
You should checkout Chisel.
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:
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.
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.
Sure, but FIRRTL is a netlist format.
Sounds good. That is the case for clash, too, by the way. Every type passed in from the top level is wrapped in a higher-level "Signal" type which represents the whole stream, and you essentially combine circuits which have those types as input and output.
That type is Applicative, so you can lift functions on "normal" types into it. Conveniently, the type of the moore and measly functions for state machines happens to be pretty much exactly the type of a State monad, so you can use that, too, to make sequential state machines.
You can then simulate Signal streams for development and testing.
Totally agreed. Additionally, BlueSpec looks pretty nice too, but I haven't had a chance to play with it.
I was mainly directing my comment at those OpenCL to HDL compilers you see, and terrible stuff like this abomination https://reconfigure.io/
I would not recommend Chisel unless you have some experience in RTL design. Although it is less documented and has a smaller community, I find SpinalHDL to be quite a bit better (it's based on Chisel but has taken the idea a step further).
Chisel allows you to make many obvious mistakes that will be hard to debug and fix unless you've already got some experience. SpinalHDL catches many design errors (with info resembling tracebacks in some cases) before you get to simulation or synthesis.
> Kami, a Coq library that uses labeled transition systems to enable similar expressive and modular reasoning for hardware designs expressed in the style of the Bluespec language. We can specify, implement, and verify realistic designs entirely within Coq, ending with automatic extraction into a pipeline that bottoms out in FPGAs. Our methodology has been evaluated in a case study verifying an infinite family of multicore systems, with cache-coherent shared memory and pipelined cores implementing (the base integer subset of) the RISC-V instruction set.
At Lockheed Martin I worked on a SIMD processor designed before VHDL and Verilog existed. The reference design was written in a lisp-like language. I don't know if the language had a name or if it was ever publicized in any way.
I'm curious to know more. Maybe some form/relative/precursor of EDIF (https://en.wikipedia.org/wiki/EDIF)? Not exactly Lisp, but an S-expression based format for describing netlists.
The DDD system was used in quite a few projects:
https://www.cs.indiana.edu/pub/techreports/TR544.pdf
May have been that one. If not, yall might still find it interesting.
I have read somewhere that Intel uses Haskell for formal verification, but public information is scarce.
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 in a verification environment called Forte 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/ass...)
Here is another mention of Forte (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.
Ah, I guess what I have read might have been about Forte and I mixed it up (ML and Haskell).
Thanks for the clarification.
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.
If you want an open source DDR3 controller to go with your open source SoC I recommend LiteDRAM. Its getting pretty polished.
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.
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.
You just brought me back memories of EuroPC computers. :)