by nbrempel on 3/3/24, 6:06 AM with 31 comments
by thrtythreeforty on 3/5/24, 7:02 AM
This may be the first HDL I've seen that attempts to move the needle on catching bugs at compile time. (I've worked with several engineers, on hardware bugs which turned out to be pipelining errors, who did not understand what I meant by "make this design error inexpressible.") I have several pages of notes on what I'd do differently if I designed my own HDL - the typical software engineer hubris - and this is the first language I've seen that starts to line up with what I was thinking.
Another perennial area where bugs crop up are when crossing clock and reset domains. The language ought to be able to make it so that you simply can't make many kinds of clock domain errors - trying to read a signal from the wrong clock domain shouldn't compile. Dedicated "unsafe" primitives from a stdlib should perform the crossing and the type conversion.
by bb88 on 3/5/24, 2:14 AM
The timing aspect is super interesting, though I wonder if a compiler given an fpga and a program could optimize the hard parts on an fpga and run the rest on a risc V core.
by unwind on 3/5/24, 8:09 AM
I was interested in the use of Filament to implement an entire RISC V processor ("frisc") but the link [1] at the bottom of the readme is broken and some quick searches of both Github and the web turned up nothing. Does anyone know what's up?
by j16sdiz on 3/5/24, 5:20 AM
I meant, in software programming, we usually program by either specifying the sequence or dependency.
In hardware, nothing runs sequentially, and signals propagate _with delay_. Everything happens at the same time, yet nothing run at the exact same moment. How could we express these chaos in for-loops and procedure look alikes?
by gchadwick on 3/5/24, 11:41 AM
by speps on 3/5/24, 3:24 AM
by carterschonwald on 3/5/24, 4:39 AM
by irq-1 on 3/5/24, 4:49 PM
Can we please stop with illegible text? Color: 333 indeed.