That is for sure my biggest concern with typst. I wrote a tool that can convert from typst to latex for final submissions, but it is a bit sketchy and at the moment won't handle math very well. https://gitlab.com/theZoq2/ttt
That is a real concern, but I wouldn't say there are any critical features in the closed source portion. I wrote the whole thesis locally with only open source tools. One of the included papers was written in the cloud platform for collaboration.
It is a concern that there is a single company doing most of the development, but there is quite a bit of community involvement so I don't think it is an immediate concern
Hehe thanks for the kind words! I think once Verilog and VHDL are de-throned there will be plenty of room for more than one new HDL :) Especially if we can figure out interoperability between languages
Spade author here :) Coming from a functional programming adjacent background, the VHDL type system leaves a lot to be desired. Not supporting types with generics means you can't encode things like a genral purpose ready/valid stream. When you have those, you can start using methods to compose those streams which becomes even more powerful when you add higher order functions which allow you to transform the content of the stream without worrying about the stream details.
> wrangling hand written modules with enormous I/O, stitching IP together
This is something where I'm confident a good type system can help significantly, part of the problem imo is that the module interfaces are often communicated with prefixes on variable names. The Spade type system bundles them together as one interface, and with methods on that interface you can start to transform things in a predictable way
Generating memory maps is also an obvious problem to solve with a language that attaches more semantics to things. I haven't looked into it with Spade, but I believe the Clash people are working on something there
> The challenge of a HDL over a regular sequential programming (software) language is that a software language is programmed in time, whereas a HDL is programmed in both space and time. As one HDL theory expert once told me "Too many high level HDLs try to abstract out time, when what they really need to do is expose time."
That's an excellent quote, I might steal it :D In general, I think good abstractions are the ones that make important details explicit rather than ones that hide "uninteresting" details.
Spade author here! The biggest difference is that BlueSpec uses a different abstraction than standard "RTL". That has significant advantages of course, but also means some overhead and a shift in mental model.
With Spade my goal is to build new abstractions on top of RTL. That should allow you to operate at a higher abstraction level with minimal overhead most of the time, and dive down to regular RTL when necessary
Clash was the HDL that I used before starting Spade. I'm not a huge fan of haskell and wanted a few more hardware specific features which is why I didn't stick with it.
That said, Clash is great and I know quite a few people at QBay. They don't seem to be slowing down any time soon!
That is a good point, sadly I'm not experienced enough with verification to know what is actually needed for verification from a language design perspective which is why I just offload to cocotb. There are a few interesting HDLs that do focus more on verification, ReWire, PDVL, Silver Oak, and Kôika are the ones I know about if you're interested in looking into them
Also, nitpick but amaranth does have its own simulator as far as I know
My probably controversial opinion on output code quality is that if you have to see the generated Verilog, I've done something wrong since there is probably a compiler bug if you need to go down to that level.
Of course, you could just be looking at output from tools like timing reports, and then as someone else commented out, it is a bit of a tooling issue. Spade does emit (* src = *) attributes which yosys and friends accept to show the original Spade source instead of Verilog, but it is still kind of leaky in some cases
I'm also an FPGA person that started off in software and this is exactly how I feel, and the reason I'm building my own HDL too. Software languages have evolved so much since the 80s and are so much more productive, HDLs have missed out on that, but convincing hardware engineers about that is an uphill battle
Yep, I hosted a minecraft server for a few years and most of it was just hanging out and talking to people, often with it open on a second monitor while doing other things
I'm not sure how well it would work, the rust embedded HAL crates like to be in control of all peripherals in order to give nice guarantees of things being properly initialised.
Calling C would also have to touch the same structures which would, if nothing else, change the state of some peripherals to something that will break the rust guarantees.