[VHDL] more than one module per file - a bad idea?
stnolting opened this issue · comments
I once learned to have only one module (entity + architecture) per file. However, I think it is quite convenient to have several modules in one file (for example all modules of the processor internal bus system in neorv32_intercon.vhd). 😅
As far as I can tell, FPGA tools and HDL simulators have no problems with that - even if some of the modules are not used at all. But what about ASIC tools? Modules that are part of the design sources but are not instantiated might be treated as additional top modules.
So what would be the "cleanest" way here (in terms of design portability and code readability)?
I learned from my professor in university to go as far as to even split up entity and architecture into its own files. I.e. adder-ent.vhd and adder-arch.vhd. I don't quite remember but I think he has given the reason for this to quickly exchange the architecture that is synthesized when one has multiple architectures (what could happen e.g. if a design is once optimized for FPGA and once for ASIC) by changing the fileset and not having to use other (more complex) ways of selecting the correct architecture. I wouldn't go that far though.
When I first used your project I was quite irritated by the fact that multiple entity+architectures reside within the same file I have to say. I did not expect it. It works in all tools that i use tough...
I learned from my professor in university to go as far as to even split up entity and architecture into its own files. I.e. adder-ent.vhd and adder-arch.vhd. I don't quite remember but I think he has given the reason for this to quickly exchange the architecture that is synthesized when one has multiple architectures (what could happen e.g. if a design is once optimized for FPGA and once for ASIC) by changing the fileset and not having to use other (more complex) ways of selecting the correct architecture. I wouldn't go that far though.
Now that's interesting! 😅 Our professor taught us that it's perfectly fine (and actually "good practice") to have even multiple architectures within a file, all associated with the same entity: one for FPGAs, one for ASICs, one for area-optimized design, ... etc.
When I first used your project I was quite irritated by the fact that multiple entity+architectures reside within the same file I have to say. I did not expect it. It works in all tools that i use tough...
I've never had any problems with it either, but I mainly live in the FPGA world. ASIC tools are a bit more... more special... I think @mikaelsky already had some issues with this?! 🤔
In addition to tool compatibility, code readability should also be important. So I'm not sure how to handle this - should we stick with the current (convenient) structure or should we explicitly pack each entity and architecture into individual files?
In some cases, VHDL will assign the "latest analysed architecture" to some component/instantiation. In those cases, you don't want to accidentally analyse "another architecture" for an entity/component, different from the "only one" you expect to exist.
I believe that problem does not exist with direct instantiation. However, direct instantiation requires the architecture to be hardcoded (it cannot be provided by a constant or a generic, it needs to be a literal, see https://gitlab.com/IEEE-P1076/VHDL-Issues/-/issues/235). So, in certain cases, a configuration or component is required, thus falling back to the default "the last analysed architecture", and wanting to limit the number of architectures viewed by the tool.
I believe that's the historic reason to keep multiple architectures for an entity in separated files. However, having multiple entities and a single architecture for each of them in a single file should not be a problem, except if the software does not know that parsing, analysing and elaborating are separated steps/stages and it incorrectly tries to do everything in a single run (which will run into "this was not defined yet", the same as when you don't use function prototypes in C).
The reason for splitting up code into entity and architecture files has a few reasons.
- It allows others to instantiate your entity without building the architecture, this helps SoC integrators to start assembling an SoC prior to all design blocks being completed. Akin to verilogs empty module concept.
- It allows you to utilize configurations to build-up designs with various architectural types. E.g early behavioral models mixed with RTL and/or VHDL-AMS. This is mainly useful if you use VHDL as a modelling language akin to System Verilogs Real Number modelling concept.
The separate ent/arch is often taught as part of the introduction to VHDL as that was the original reason for VHDL to exist, that is. VHDL is a modelling language based on ADA to allow modelling and descriptions of complex digital systems. It just so happens that if you apply certain constraints to VHDL it can also be converted into real things... like logic gates.
The design teams I worked with abandoned separate ent/arch back in 2003/2004 and I mostly see separate ent/arch with Interns until they get clued in :)
Prior to SystemVerilog existing VHDL had a lot of good going for it. Its a great intro language, as its Very strict and enforces some good discipline. With Verilog/SystemVerilog you can screw yourself over seven days to Sunday and not even know it... looking at you $signed() and un-constrained left and right vector sizing.
However, having multiple entities and a single architecture for each of them in a single file should not be a problem [...]
FPGA tools seem to be fine with that. An even ASIC tools (at least the ones from big C) seem to be able to handle that as well (tested with https://github.com/stnolting/neoTRNG/blob/main/rtl/neoTRNG.vhd).
The design teams I worked with abandoned separate ent/arch back in 2003/2004 and I mostly see separate ent/arch with Interns until they get clued in :)
😄 👍
So we stick to the fact that multiple architects per file are ok for now?
Btw, thank you all for your feedback!