Hi Denis, Thanks for your feedback !
>jeu. 04 sept. 2025 at 17:17, Denis 'GNUtoo' Carikli ><gnu...@cyberdimension.org> wrote: >> "fpga" concerns more than fpgas, > Are you referring to gtkwave? To me beside gtkwave and openfpgaloader > everything is related to HDL. Nvc, iverilog, verilator are vhdl/verilog compilers; gtkwave is a trace viewer; yosys implements synthesis ... all of this also concern asics, kind the opposite to fpgas. Not to mention systemc, for generic event driven simulations. Vunit concerns unit testing of hdl, etc. Other than openfpgaloader, nextpnr and hdlmake, which are specific to fpgas, all the rest is mostly digital electronics design. >> and should be merged with "electronics" > Given that a lot of packages are also in engineering.scm, Electronics design related packages in engineering should move to electronics, IMMO. > I think that if we want to improve things (at the cost of backward > compatibility) it would be better to rename fpga.scm to hdl.scm > instead. I don’t see where is the point on putting a frontier between electronics design and hdl (or fpga, or anything else), as this complicates things: mix simulation of analog / digital circuits is hdl or not ? From my perspective, keeping two different modules (three with engineering) for electronics design complicates things and maintenance. > This would mean: > - openfpgaloader would be moved from fpga.scm in flashing-tools.scm Good catch, I was not aware of this module. > - gtkwave could be moved from fpga.scm to electronics.scm (as there is > already sigrok related packages there) or engineering.scm (there are > a lot of simulation tools there too, but electronics seems more > specific) Sure. > - abc-yosyshq, json-for-vhdl, prjtrellis, opensta, osvvm, > python-cocotb, python-cocotb-bus, python-edalize, > python-pydigitalwavetools, python-surf, python-vsg, symbiyosys, could > also be moved from electronics.scm to hdl.scm. Why not ? But once again, I don’t see the benefit of splitting hdl from electronics design. At the end, we fall into current situation where each one drops things around following his own criteria. > - minipro could be moved from electronics.scm to flashing-tools.scm Great idea. > The good side of this move would be that with hdl.scm one would be > pretty sure of what goes in there and what doesn't. And this would also > ensure that we don't have everything in a huge file. To me, this is not an issue. We already have much larger modules, and this simplifies inheritance and maintenance. > For instance any HDL synthetisis or simulation tool should go there, > but not tools to program FPGAs (flashing tools) nor more general > simulation programs (like gtkwave). > > I also found some small things that can be moved: > - python-esptool could be moved from engineering.scm to bootloaders.scm Definitely, engineering needs a serious clean up. > Beside that I've not looked in details into the rest, as one thing to > avoid here would be to have file names that don't convey clear > boundaries as of what goes or doesn't go there. > > A good example is that the content of electronics.scm and > engineering.scm overlap a lot, for instance both have simulation tools > for digital circuits, PCB capture tools and so on. engineering.scm also > has a wide variety of tools, from PCB capture, CAD software, binary > reverse engineering tools, tools to work with serial port, etc. Sure, all electronics design related packages should move to electronics. > So there would be room for improvement here, and personally If we move > things, I would be more inclined to move things carefully, like in the > hdl.scm move I propose, to make sure that the changes are worth the > issues (lack of backward compatibility can make bisect harder) and that > basically we don't end re-creating new files with very vague boundaries. > > And at the end of the day the vague boundaries carry of packaging twice > the same thing (it happened to me), and also make contributions easier, > so there is also clear benefit. The question is more if it worth the > cost of breaking backward compatibility (assuming the boundaries are > clear). Let’s not put boundaries within electronics design fields, just simply, to avoid further complications. Otherwise, some might argue that hdl, fpga, asics, analog, mix, pcb, drivers, embedded, ... are all sub fields, and they deserve a separate module, which brought us to the current situation. Best, C.
signature.asc
Description: PGP signature
