Live data from Hacker News

Filament – A Language for Fearless Hardware Design

filamenthdl.com

11–20 of 34 posts

Re: Filament – A Language for Fearless Hardware Design

#11

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 inexp…

Every time I see one of these pop up, the thought that software engineers are forever trying to avoid knowledge, understanding, and wisdom with another layer of abstraction comes to mind.

I’m all in favor of a better HDL. Verizon/SystemVerilog is loaded with completely non-obvious landmines. I’ve been doing this so long I forget they are there, but it’s pretty painful seeing someone new to the language step on them. But the alternative, VHDL has largely fallen out of favor in the US.

You would be hard pressed to find a more strongly typed language than VHDL, but damn is it verbose. None of the footguns, but you might get an RSA before you finish typing the code in. If you have ever given Ada a try, VHDL will look pretty familiar.

I know this may be a weird thing for software folks to think about, but writing HDL is a tiny part of digital design. In digital design, if done with discipline, writing the HDL is an almost mechanical process of translating the design. In a design that might take a year, writing the code might be 3 weeks.

Done without discipline you will spend all your time debugging. Wondering why it worked in the lab an hour ago, but after lunch nothing works and you won’t be able to make sense of it.

Understanding basic combinational logic, then sequential logic, followed by state machines (which are the bread and butter of digital design), followed by understanding IO timing and timing constraints (a brain damaged “language” to itself) will take you far.

Domain crossing isn’t so bad if you have those fundamentals.

Then you can spend time learning algorithms other more interesting things. Writing low power software accelerators for neural nets and signal processing.

You can go through all the gyrations of language design in the world, but the language isn’t the hard part. There is a huge amount of improvement to be done, no doubt. But digital design is not the language.

If you want to make the world of digital design a better place, more open, easier to break into, work on tools, not languages. I’d give a kidney for an open source timing diagrammer that could do simple setup and hold checks, create derived signals through Boolean combinations of other signals, and emulate a flop.

I’d do it, but I’ve tried and programming a gui is about the most painful thing I’ve done on a computer. So much work for so little payoff.

Re: Filament – A Language for Fearless Hardware Design

#12
post #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

It's under /apps in the repo: https://github.com/cucapra/filament/tree/f5da227a059f181b996...

Re: Filament – A Language for Fearless Hardware Design

#13
post #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

[deleted]

Re: Filament – A Language for Fearless Hardware Design

#14

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 inexp…

Every time I see one of these pop up, the thought that software engineers are forever trying to avoid knowledge, understanding, and wisdom with another layer of abstraction comes to mind. I’m all in favor of a better HDL. Verizon/SystemVerilog is loaded with completely non-obvious landmines. I’ve been doing this so long I forget they are there, but it’s pretty painful seeing someone new to the language step on them.…

But couldn't there be languages where it was easier to express that design? Your description reminds me what it's like to program in C.

Re: Filament – A Language for Fearless Hardware Design

#15

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 inexp…

We use the python based myhdl extensively and are very successful in writing hdl for fpga that has vanishingly few bugs. The reason why myhdl makes this possible is that testing is relatively trivial, so we use it properly (i.e. everywhere). You're right that it doesn't solve the hard problem, and discipline is needed around things like clocks, but it does enable modern development techniques and when writing RTL, HDL is very amenable to extensive tests to quash bugs.

Re: Filament – A Language for Fearless Hardware Design

#16

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 inexp…

Every time I see one of these pop up, the thought that software engineers are forever trying to avoid knowledge, understanding, and wisdom with another layer of abstraction comes to mind. I’m all in favor of a better HDL. Verizon/SystemVerilog is loaded with completely non-obvious landmines. I’ve been doing this so long I forget they are there, but it’s pretty painful seeing someone new to the language step on them.…

„they“ (someone not working in the field) try to solve a problem (i.e. warts in old and mature languages) that is literally not a problem in the field at all. Then they get pissed at you when you point it out that nobody needs this, like at all. Oh well.

Re: Filament – A Language for Fearless Hardware Design

#17
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?

HDL when operating as an HDL doesn't convert things into for loops or procedures, it's specifying a configuration of gates or FPGA lookup tables. Crucially it doesn't contain any layout information, so additional phases of work are needed.

There is some confusion because the hardware can also be simulated, in a fairly straightforward way - you just need to model all those delays and run an event based simulator. Then the existing HDLs like (System)Verilog contain actual programming language constructs that are just there for use in simulation and can't actually be replicated in hardware.

Re: Filament – A Language for Fearless Hardware Design

#18

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 inexp…

Every time I see one of these pop up, the thought that software engineers are forever trying to avoid knowledge, understanding, and wisdom with another layer of abstraction comes to mind. I’m all in favor of a better HDL. Verizon/SystemVerilog is loaded with completely non-obvious landmines. I’ve been doing this so long I forget they are there, but it’s pretty painful seeing someone new to the language step on them.…

Hell, I'd even give my left nut for a vendor- and IDE-agnostic tool that would convert a schematic to your HDL of choice. I still do a lot of work on graph paper.

Re: Filament – A Language for Fearless Hardware Design

#19

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 inexp…

[deleted]

Re: Filament – A Language for Fearless Hardware Design

#20

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 inexp…

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

That's generally make take too, only I'd say they make some of the hard parts harder.

When you're getting into timing, power and area optimizations it's important to have a good mental mapping from the HDL you're writing to the circuitry (or FPGA configuration) being produced. For some optimizations you also need to smash through neat abstractions.

Often these new HDLs abstract away more from the circuitry so you have to carry more things in your head to think through these optimizations. They aim to work out the details for you but those details matter and when you only have indirect control over them can make things more difficult.

In software we're generally happy to accept a drop in performance or an increase in memory usage to gain powerful abstractions and increase developer productivity. In hardware this is often less acceptable (in particular if you're building high-performance CPU, GPU, AI accelerators etc).

From my brief look at the front page of the Filament website I do like the type system but from experience building real CPUs (I worked on the A55, A510 and E1 at arm, focussed on memory systems and now work on Ibex: https://github.com/lowrisc/ibex amongst other things) bugs and other issues around pipelining are often to do with stall conditions, I wonder how well it can handle that? Stall conditions were large and complex and also where you had to do lots of those abstraction busting optimisations to meet timing so it's critical you have a strong grasp of the critical paths being produced in the circuitry. My fear with Filament is it abstracts a bunch of that away.

Of course the entire hardware world isn't CPUs, there could well be areas of design this kind of language works well. In particular I can see it's useful for prototyping/design exploration type work.

Post reply on HN