-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GHDL synth internal state inconsistent with Yosys state #137
Comments
For the spurious warnings when the same file is re-analyzed, I am not sure what to do. Maybe I won't do anything, as this is not a common case.
Currently, ghdl keeps track of files that have been analyzed. Maybe the 'ghdl' command should start from scratch at each execution.
|
Would this impact the possibility for defining different libraries? Currently, I use several |
No, external libraries would be kept.
But files that have been read from a previous ghdl command wouldn't be kept for the next commands.
|
I added another example of the spurious warning, which also occurs when one imports two different files that state the same module name. This could occur in practice, for example, if one file is a rewrite of the other file and the author wishes to formally verify their equivalence using a miter circuit. |
Yes, but this is not spurious. This exactly what the warning is about.
|
I would think that renaming the first module to a new name after importing would make the old name freely available, and that the second module (sharing the old name) would no longer collide with the first module after the rename. (I realize now that I did not make it clear in my comment that there was a rename involved with the example I added afterwards). If having a warning in this situation (with a rename) is an intended feature, then the other header of "Broken state after trying to import nonexistent file" would seem to be fixed by your commit to GHDL, and this issue could be closed after I have time to test the committed change. |
(The title of this issue refers to my best guess at explaining the behavior below, as I have not dived into how the GHDL synthesis code actually works. Please let me know if some other title would be more appropriate.)
The sections below describe behavior explainable by the GHDL synthesis plugin maintaining too much independent state, but please let me know if any of the below is actually intended behavior.
(This is related to the title of #74, but most of the comments under it appear to be a separate discussion about GPL licensing.)
Files used in below examples
addmodule_verilog.v
(not actually used below but a useful Verilog reference that should do the same thing)addmodule_vhdl.vhd
addmodule_vhdl_other.vhd
Broken state after trying to import nonexistent file
The second
ghdl
command should not result in an error.Spurious warnings after module rename
Since the imported module has been renamed, there should not be a name conflict when importing it again. (I suspect that a failure to track renames has wider repercussions in resolving file dependencies, but I have not had the chance to explore this further or generate a MCVE for a file dependency type situation.)
Another example with a different file but same module:
The text was updated successfully, but these errors were encountered: