Using pyVHDLModel to aid in analyzing mixed language or projects with missing files.

[Tcenova]

I am curious on your thoughts in allowing pyVHDLModel to be used in analyzing partial (missing files) or mixed language projects. Currently, the Analyze function in __init__.py will raise an exception if a package, library, or entity is missing and full analysis cannot be performed. As a local test, I removed raising some of the exceptions, and instead just printed them to know what is missing. I am using these changes with success in my use case.

Is this something which you would be open to being added to pyVHDLModel? I would need to think on a better long term way to allow for disabling the hard checks in analysis. I see value in doing so, especially in mixed language projects, or projects which use vendor provided libraries or entities which may not have plaintext source, or source that is only in Verilog.

[Paebbels]

I'm not sure I fully got your thoughts.

You can add files step by step and each file is transformed into the model representation. Only higher level features like jumping from port to it's type require name resolutions etc. This can only (successfully) be done if all parts of the design exist.

For mixed language use cases, I hope for 2 things:

1. GHDL goes on with it's Verilog parser (there have been commits in the past).
2. Someone writes a pySVModel (currently an empty repository with only a VerilogVersion enum).

On VHDL side, we would have components for analysis. If the Verilog code is also loaded, pyVHDLModel could reference to Verilog entities. And vise versa.

For vendor libraries: Usually they provide components as an interface. For encrypted IPs, they need to provide the public interface as not encrypted. (see *.h files vs. *.a or *.so files)

---

For exception vs. no exception:
I think we could have a strikt mode vs. a relaxed mode or so. The question is then, how and where to collect these problems (exceptions). And if it could be continued afterwards.

Having such an error/warning collector, is somehow on my list. I'm faced this problem multiple times, were you want to relax parsing, so no exception and go on, but also provide a list of problematic zones in the code/file for users to improve.

I don't like the stop on first error behavior (most strikt), but everything else needs a clever implementation.