[Input needed] Repository Cleanup

[mole99]

Icarus Verilog has a long history to look back on. While that's great, it also means there's a lot of old code that may no longer be useful.

While I moved the text files to the new documentation I came across some files and folders which may be removed from the repository. Some of these files/folders where touched centuries ago, may not build anymore, or worse, contain outdated information.

In my opinion, it is favorable to remove old and unused code to keep the codebase lean and easier to maintain. With the git versioning system nothing is really lost and, if necessary, may even be restored.

If any of these directories is removed, the corresponding documentation should also be removed.

Candidates for removal

• iverilog/solaris - last changed ~20 years ago

I don't know if this still builds, but one of the files references version 0.7 of Icarus Verilog so it seems to be outdated. Therefore, I opt for removing this folder.

• iverilog/tgt-pal - last changed ~20 years ago

This code generator for Programmable Array Logic has also not been updated for a long time, if we don't count the maintenance updates.

This code generator is also in the NOTUSED list in the Makefile.

• iverilog/tgt-fpga - last changed ~20 years ago

The same points as for tgt-pal apply here.

This code generator is also in the NOTUSED list in the Makefile.

• iverilog/tgt-verilog - last changed ~10 years ago

I think the idea of this code generator was to produce Verilog > 95, but it seems like it never came really far.

This code generator is also in the NOTUSED list in the Makefile.

• iverilog/tgt-pcb - last changed ~12 years ago

Here I am not really sure. It is still shipped with every Icarus installation. Has anyone used this lately?

If the goal is to implement a circuit with discrete logic on a PCB, then I would argue that Yosys + techmap and KiCad will probably do a better job.

• /examples - VPI, FPGA and PAL examples

Some of the examples use some of the code generators listed above and thus don't work anymore on a standard installation. I would propose to remove the affected examples and maybe move the rest to the documentation?

---

Do you agree/disagree with the points listed above? Have you used one of the code generators lately? Please reply and discuss.

And if you know any other files which may be removed, please also add them in a reply. Thanks!

[caryr]

You will need comments from @steveicarus on tgt-pal, tgt-fpga and tgt-pcb, but here are some comments on the other directories. While I do agree nothing is ever truly lost with git once it is no longer visible it is effectively lost.

Solaris

Early in my days contributing to Icarus I had an OpenSolaris VM that I used to get Icarus to compile and run cleanly. I have no idea if anyone ever used it and I think this directory actually predates that work. When OpenSolaris was cancelled I stopped supporting this because the alternatives were not mature enough. I do not know if the other free alternatives matured into something usable or if Solaris itself is a viable alternative. Given how fringe Solaris has become I'm not against removing this, but would it be better to bring this up to date if there is a viable free alternative.

tgt-verilog

This predates the vlog-95 converter. I wrote the vlog-95 converter because it can translate any input file into something that can be used with archaic tools. We likely need a more complete verilog to verilog converter since things like classes etc. just cannot be translated into vlog-95 and looking at what the compiler produces in verilog is much easier for most people than decoding the VVP intermediate code. I assume all the appropriate information has been mined from this code and it now exists in the vlog-95 converter. If I was to add support for the constructs that cannot be translated it may be as an extension of the vlog-95 converter instead of duplicating the existing code. I'm not opposed to removing this.

examples

Yes, I think these files should be split up and placed with their corresponding documentation. For the directories we plan to delete should we move the examples and documentation to an appropriate place and then delete the documentation and implementation directory in a single commit so it is obvious what is being deleted and it can be easily restored without getting extra stuff. Specifically don't delete all the outdated targets in a single commit. Delete them individually. For example, should the hand written VVP files be grouped with the vvp documentation in a common subdirectory? Most things are now fully covered in the test suite, but these hand-written files do provide information that may not be as accessible as the code generated versions.

At some point I tried to get all these unused code generators to at least compile correctly so we didn't have any interface shifts, etc., but I have not looked at them in a very long time.

[mole99]

Regarding your statement, I agree that once these directories are no longer visible, it equals nonexistence, at least for newcomers to the project. Only those familiar with them would be able to restore the code. Hopefully, it should not be necessary to restore the code after carefully deciding to remove it.

My argument was more along the lines of if a contributor wants to develop something similar to what was removed. Then we, who know about it, could refer to previous commits.

But I doubt that will happen after most of the code hasn't been touched for centuries, so it seems like there is no need for these code generators in Icarus Verilog, or the code generators themselves lack features to be really useful. There are well-established tools in the open source scene with overlapping features, but many more capabilities like Yosys and nextpnr, at least for tgt-fpga.

Another option would be to move these generators to a separate repository.