suoto / hdl_checker

Repurposing existing HDL tools to help writing better code
GNU General Public License v3.0
192 stars 22 forks source link

[Question] Managing component dependencies and more #86

Open pidgeon777 opened 3 years ago

pidgeon777 commented 3 years ago

Hi, first of all, congratulation for your tool.

I have a question, let's suppose the following:

1)

ENT_A.vhd - Declaration of ENT_A entity and instance of ENT_B as a component. ENT_B.vhd - Declaration of ENT_B entity.

Let's suppose I will change ENT_B entity name to ENT_C, without touching the instanced ENT_B name in the top ENT_A entity. Thus, I only modify ENT_B.vhd.

Will the tool report that ENT_A is now instancing a component (ENT_B) whose entity is not found anywhere?

Or, more in general, how could the tool report if any of the instanced components of the source files are not found anywhere as entities (nor in the library, nor in the source files)?

2)

Also, let suppose I still have ENT_A and ENT_B as in the first case. Now let suppose that I modify the generic/port names of ENT_B, in ENT_B.vhd. Then, as a result, the instanced ENT_B component in ENT_A will not match with the new ENT_B interface.

Will the tool report this new misalignment?

When manually compiling those two components, we would have:

3)

If I simply define a list of sources in the hdl_config file, eventually defining the libraries when needed, will the tool automatically analyze those in the correct order? If yes, in which situations?

4)

Is there a way to also display warnings from the chosen compiler?

Thank you.

suoto commented 3 years ago

(1) You can look at what the dependencies are by hovering over the entity name (maybe not the best way to report but still).

If ENT_A defines a component called ENT_B and instantiates the component (e.g., label : ent_b), then ENT_B.vhd is not a dependency, so its contents don't really matter. If you instantiate ENT_B explicitly (e.g., label : entity work.ent), then ENT_B will be compiled before ENT_A and errors and/or warnings from ENT_B should be displayed when compiling ENT_A as well.

Components can be bound after the compilation phase, but since HDL Checker will only compile sources, the component not bound warning won't show up at all.

(2) HDL Checker only cares about names, as long as a target file's dependencies name matches foo, the file that defines foo will be compiled before the target file. In this case, the list of warnings/errors for the target file will also include warnings/errors from compiling foo.

(3) It should compile in the correct order. It will parse some VHDL clauses like use <library>.<design_unit> to search for packages and contexts, label : entity <library>.<entity_name> to search for entities and package body <name> to search for package definitions. (The tool will query the compiler for what's built-in -- usually IEEE libraries, Xilinx precompiled libraries, etc --, so those will be ignored.)

You don't need to specify libraries for all sources, the tool will try to guess which library a source should be compiled on based on how the design units it defines are used. For example, if ent_a.vhd defines an entity called ent_a and the testbench instantiates it as <label> : entity some_library.ent_a, then ent_a.vhd should be compiled into some_library. If ent_a is instantiated in different libraries, the tool will pick the most common one and issue a dependency not unique warning listing the offending files.

I generally let HDL Checker try to guess and only manually set libraries of files it got wrong.

(4) Warnings from the compilation stage are shown by default, like I explained before, things that show up at runtime or simulation time will not be show because those steps are not run at all

Please let me know if that answers your questions or if you have any further questions!