[thezoq2]

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

[IshKebab]

Yeah.... I mean I get where you're coming from because how often do you have to look at disassembly to debug a C bug? Very rarely.

But that's because the tools debug at the C level. That isn't the case for SV at all - all the tools operate at the SV level.

Unless you're going to create commercial grade simulators, debuggers, synthesis tools etc. then users are going to be debugging SV.

My day job is debugging generated SV and even though it isn't nearly as bad as the code smallpipe posted it still suuucks. It costs me a lot of time reverse engineering it.

If anything is going to replace SV (and I really hope it does) it really really needs to focus on producing clean debuggable output. That includes things like using interfaces, structs and so on.

[sitkack]

Having clean SV will enable Spade to be used incrementally inside of a SV codebase. Var names should make it through, comments, asserts, etc. Treat it like a CASE tool.

https://en.wikipedia.org/wiki/Computer-aided_software_engine...