Live data from Hacker News

Filament – A Language for Fearless Hardware Design

filamenthdl.com

1–10 of 34 posts

Re: Filament – A Language for Fearless Hardware Design

#2
I think this is super interesting. Kind of like a rust style language for symbolic logic.

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.

Re: Filament – A Language for Fearless Hardware Design

#5
I never really understand how HDL works.

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?

Re: Filament – A Language for Fearless Hardware Design

#6
post #5

I never really understand how HDL works. 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?

For loops are one of those things that just don't really exist in hardware.

The way I like to think of hardware is as a machine that takes a giant blob of state, applies a pure function to it, and when the clock goes from low to high it replaces the original state with the new one and the process starts again.

Re: Filament – A Language for Fearless Hardware Design

#7
post #6
post #5

I never really understand how HDL works. 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?

For loops are one of those things that just don't really exist in hardware. The way I like to think of hardware is as a machine that takes a giant blob of state, applies a pure function to it, and when the clock goes from low to high it replaces the original state with the new one and the process starts again.

> For loops are one of those things that just don't really exist in hardware.

Hardware for loops are just fine if you think of a for loop as existing in space rather than time--effectively it is always fully unrolled.

> The way I like to think of hardware is as a machine that takes a giant blob of state, applies a pure function to it, and when the clock goes from low to high it replaces the original state with the new one and the process starts again.

That's the way hardware guys think of it, too. :)

https://en.wikipedia.org/wiki/Mealy_machine

Re: Filament – A Language for Fearless Hardware Design

#8
My experience with most "neo HDLs" is that they are all code generators which make the tedious part easy and don't really end up touching the hard part.

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.

Re: Filament – A Language for Fearless Hardware Design

#9
post #5

I never really understand how HDL works. 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?

Preface: My experience is in verilog so I'll mostly be coming from there.

In most HDLs you have two kinds of code, procedural and continuous code.

Your continuous code is wires which propagate signals and continuous logic (basically pure functions). Since there aren't any registers in this logic, that means you generally need to do timing analysis to make sure it never gets too long between any two given registers (or latches if you are clock stealing). In verilog you mostly do this via assign statements and module instantiations.

Your procedural code is register or latch based code. In verilog these are your always blocks. Here the code represents logic that occurs on every occurance of a given clock edge. The type of always block you use and which edge you specify changes exactly what happens but generally it means "this code runs during this interval every time the clock does a specific transition". Your inputs are generally going to be registers or latches and your outputs will be as well. Anything that happens must do so fast enough for the logic in between to reach a steady state and long enough for it to catch the edge of the register, edge of the edge triggered latch, or level of the level triggered latch and set the register or latch. If that sounds complicated it kinda is but generally you just let your timing analyzer figure it out and complain if stuff is too slow.

Now outside your normal procedural code there are some other ones you see occasionally. There are also initial blocks which only run once and repeat blocks which only run a set number of times but with both you can pause or wait for a condition before proceeding. And there are also forever blocks. In all three of these blocks you can specify timings and delays for things. The most common use for forever blocks for example is to declare a clock that runs at a specified frequency. And initial blocks are used to do setup (such as start the clock loop, set initial values, etc).

Now as to how you do loops and procedural logic? You use registers to break it up. That's what those always blocks are for. Your always block does a little bit of work each time and you use a state machine to codify where in the loop or procedural logic you are. In general FSMs (finite state machines) become your friend in HDL work very quickly.

Re: Filament – A Language for Fearless Hardware Design

#10
Very cool.

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?

[1]: https://github.com/cucapra/filament/tree/main/frisc

Post reply on HN