thezoq2

That sounds like a fun project! Alexandria is the way to go for now but hopefully they will get proper support for it sooner rather than later.

Until 0.13 it wasn't quite as good as latex in my experience, it mainly inserted more hyphens than LaTeX.

As of this version, it would be very hard to tell a difference in my experience

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.

Ah right, I didn't know hardcaml has a simulator

> 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

Spade author here!

That's a good reminder that I need to update the example on the website, I must have written that example almost 3 years ago at this point :)

For more up to date motivation, my talk from LatchUp last year is probably the best one I have https://www.youtube.com/watch?v=_EdOHbY2dlg&t=277s

> So my fear is that this new hardware description language hasn't been created by a veteran who has many years of experience in using HDLs

That's annoyingly quite close to the truth :D But I think I have enough experience now to not be completely stumbling around in the dark

Thanks for the kind words!

> 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

Chisel, BlueSpec Spinal and Migen are already used quite a bit though of course much less so than Verilog. But we do need new languages, https://drops.dagstuhl.de/storage/00lipics/lipics-vol136-sna... does a pretty good job at articulating why

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!

Spade author here!

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

Spade author here!

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 love how this is being downvoted! Writing Verilog or VHDL is exactly like writing C, or maybe even assembly

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.

I would add solvespace to that list. It's FOSS and in my experience much more stable than FreeCAD.

That sounds like a way less annoying issue than trying to schedule things across borders

the ! indicates that it is a macro, so include_string! is run at compile time.

A professor of mine said something along the lines of "If something isn't confusing enough, give it multiple names"

People who built proper desktop applications didn't build them for linux. Even microsoft are releasing their electron things on linux (skype and VS code). I very much doubt that would have happened if they built native apps.

I much prefer the ability to running a slightly inefficient program over not having that program at all.

An out of bounds access doesn't have to lead to a crash. For most types in the standard library, the [] operator crashes but the "get" function returns Result<T, E> which you can deal with.

The advantage of rusts error handling is that it is explicit. The compiler knows that a function might result in an error and forces the programmer to deal with it, or pass it along.

In an exception based language you might forget to deal with the error and have it crash "higher up" in the code.

I also suspect that there might be a performance benefit but I could be completely wrong about that