51–60 of 64 posts
Another new HDL: https://veryl-lang.org/ It'll be a long while before either gets enough traction to be serious competition to system erilog, even if SV is, compared to modern software languages, outdated.
If a new HDL language doesn’t have simulation capabilities baked in its next to useless. See: hardcaml and amaranth. The hard part has never been writing HDL, it’s verifying HDL and making the verification as organized and as easy as possible. Teams spend something like 20% of time on design and 80%+ on verification allegedly (definitely true at my shop). Edit: I see it’s tightly integrated with cocotb which is good.…
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…
Also great work with spade. I love to hate, but the hardware industry needs folks like you pushing it forward. I just fear most people are making toys or focusing a ton of effort on the wrong issues (how to write HDL in a different way) instead of solving industry issues like verification, wrangling hand written modules with enormous I/O, stitching IP together, targeting real FPGAs, auto generating memory maps, etc. some of that is a tough solve because it’s proprietary.
[1] https://github.com/janestreet/hardcaml/blob/master/docs/wave...
Love to see this at the top of HN! I haven't written anything with this language yet, but I have met some of the developers of this language. They're pretty great and they are doing a lot of really good work in the open source hardware community. Another project they maintain is Surfer: https://surfer-project.org/ The challenge of a HDL over a regular sequential programming (software) language is that a software lang…
> 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." Exactly! It's astounding how often the documentation of some vendor component has in the documentation: "data_out is valid 2 cycles after read_enable is asserted", and NOTHING in the actual module definition makes a mention of this. There's so much dumb and error-prone mental a…
I have looked at TL-Verilog, I love the language, I am on the fence with the syntax, which arguably, is nearly an inconsequential nit given how far languages and tools need to progress.
https://github.com/TL-X-org/TL-V_Projects
Wow, a TL-Verilog video! https://www.youtube.com/watch?v=o2epusH-fXI
If the output SystemVerilog is unreadable I'm unlikely to use this. SV is still the lingua franca for physical tools. I'm not debugging timing on something that looks like this: localparam[14:0] _e_953 = 0; localparam[14:0] _e_958 = 1; assign _e_956 = \count + _e_958; assign _e_955 = _e_956[14:0]; assign _e_948 = _e_949 ? _e_953 : _e_955;
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 w…
https://en.wikipedia.org/wiki/Computer-aided_software_engine...
Another new HDL: https://veryl-lang.org/ It'll be a long while before either gets enough traction to be serious competition to system erilog, even if SV is, compared to modern software languages, outdated.
This looks much more likely to succeed tbh. Similar enough to SV that you can piggy back off the features that you're likely never going to replicate (SVA, functional coverage, multiple clock domains, etc. etc.) but also fixes the footguns.
Earlier quoted context omitted.
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…
Sorry hardcaml and amaranth were my examples of things with baked in sim features. Also great work with spade. I love to hate, but the hardware industry needs folks like you pushing it forward. I just fear most people are making toys or focusing a ton of effort on the wrong issues (how to write HDL in a different way) instead of solving industry issues like verification, wrangling hand written modules with enormous I…
> 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
If the output SystemVerilog is unreadable I'm unlikely to use this. SV is still the lingua franca for physical tools. I'm not debugging timing on something that looks like this: localparam[14:0] _e_953 = 0; localparam[14:0] _e_958 = 1; assign _e_956 = \count + _e_958; assign _e_955 = _e_956[14:0]; assign _e_948 = _e_949 ? _e_953 : _e_955;
Fair, but it's just a tooling issue. You don't debug your Verilog anymore at the gate-level, do you?
FPGA toolchains are infamous for one of the worst and cursed toolchains in the world. Where writing tcl scripts to imperatively connects blocks together in a block diagram that will integrate all the verilog code is not just normal, but encouraged. Because their internal block diagram description file is git hostile
If a new HDL language doesn’t have simulation capabilities baked in its next to useless. See: hardcaml and amaranth. The hard part has never been writing HDL, it’s verifying HDL and making the verification as organized and as easy as possible. Teams spend something like 20% of time on design and 80%+ on verification allegedly (definitely true at my shop). Edit: I see it’s tightly integrated with cocotb which is good.…
If a new HDL language doesn’t have simulation capabilities baked in its next to useless. See: hardcaml and amaranth. The hard part has never been writing HDL, it’s verifying HDL and making the verification as organized and as easy as possible. Teams spend something like 20% of time on design and 80%+ on verification allegedly (definitely true at my shop). Edit: I see it’s tightly integrated with cocotb which is good.…
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…
If there is something worth checking, but its only possible to check it in simulation (think UBSan), then you should add it anyway, just so that it can get triggered by a counterexample. (Think debug only signals/wires/record fields/inputs/outputs/components) You don't want people to write lengthy exhaustive tests or stare at waveforms all day.
Note that the point of formal verification here isn't to be uptight about writing perfect software in a vacuum. It's in fact the opposite. It's about being lazy and getting away with it. If you fuzz Rust code merely to make sure that you're not triggering panics, you've already made a huge improvement in software correctness, even though you haven't defined any application specific contracts yet!