[smallpipe]

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;

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

[alain94040]

Fair, but it's just a tooling issue. You don't debug your Verilog anymore at the gate-level, do you?

[variaga]

When debugging/fixing timing problems, or trying to implement a functional change using only metal layers - yes, it is absolutely still necessary to debug verilog at the gate level.

Also, "just a tooling issue" is a pretty big problem when you're talking about something that wants to be adopted as part of the toolchain.

[smallpipe]

I do for the most sensitive path of the design, but only because it's needed. I don't want to have to look at it for day-to-day debugging, where it's just a distraction.

[adwn]

> just a tooling issue

The word "just" is carrying the weight of the world on its shoulders…

[Pet_Ant]

Whenever I see that I think of the Itanium where it was destined to be a success, the compiler just needed to...

[TeMPOraL]

It's been said that the arc of history bends toward just-ice...

[minetest2048]

> it's just a tooling issue

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