Code duplication/divergence in (System)Verilog backends is going to bite us someday.

[cbiffle]

The Verilog and SystemVerilog backends have a lot in common. Nearly parallel code. Nearly identical primitives.

Nearly. They diverge in places. Some of those places are probably intentional.

The two target languages are so similar that the backends ought to share code. I'm filing this to seek feedback before I go crazy and clean anything up.

I see two obvious options:

1. Factor shared code into a separate library.
2. Fold the two backends into a single library.

My preference would be for option 2 -- the rest of the compiler would not notice, and it reduces boilerplate.

[christiaanb]

@thoughtpolice is planning to fold the current backends into clash-lib: I think as part of this, seeing what can be shared between the Verilog and SystemVerilog backends would be a good idea.

The reason they don't share code right now is mostly for pragmatic/lazy reasons:

• Together with @Ericson2314 we wrote current backend code to get SystemVerilog generation aside from VHDL generation. We picked SV because SV has more in common with VHDL than Verilog in terms of supporting things like structs (and arrays at module boundaries)
• I then started a Verilog backend, and instead of making sure I could share code between SV and Verilog backend, I was lazy, and just copied code...

Anyhow, option 2 will (eventually) happen when the current backends get merged into clash-lib

[cbiffle]

Thanks for the historical context. I'm happy to hold off and let @thoughtpolice do this, or to pitch in myself.

[thoughtpolice]

I need to revive my WIP branch. Just moving everything in isn't too hard; I'll get to it soon...