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