-
Notifications
You must be signed in to change notification settings - Fork 360
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
mixing VHDL-2008 with other standards? #908
Comments
You have to analyze all your sources using vhdl 2008. But if you want to check that your top entity only vhdl93 features, you can also analyze the top entity using vhdl 93.
Right now there is no support for mixed vhdl/verilog files.
|
As of today, VHDL does not support mixing multiple versions of the standard. Each time you analyze a source, a representation is saved in some internal file which is dependent on
Nevertheless, you should be able to write your top level entity with 1993 syntax, but have GHDL analyze it with In the worst case, you could have an outer VHDL 1993 top level, a 1993-to-2008 wrapper and your 'real' 2008 top level.
Not currently. However, we have discussed/asked about some related features before. Bear with me. Until some months ago, GHDL had multiple "frontends" (parsers for different versions of the standard) to the internal representation, but a single target (generate executable machine code) that was implemented with three possible backends (mcode, LLVM or GCC). Recently, synthesis features were added, which implement a different target (synthesizable hardware description) with two possible backends (built-in Currently, the output of Furthermore, when analyzing licensing similarities and differences between the output generated by GHDL (for simulation) and other open source tools for HDL, such as Verilator, the possibily to provide/write a 'vhdlator' has been proposed. This would be an additional target (third), to generate/output C/C++ source code. Hence, it would be possible to generate separate C/C++ units with different versions of the standard and then integrate them in a wrapper C/C++ project. Nevertheless, Verilator supports the synthesisable subset of Verilog only, I don't know whether the hypothetical 'vhdlator' would be limited too. I want to believe that we can take advantage of LLVM to have it done for the non-synthesisable subset too.
Technically, it is possible. But it is not straightforward and the granularity at which you can integrate the sources is pretty coarse. Currently, AFAIK there is no open source tool that accepts up-to-date versions of Verilog and VHDL. Hence it is not possible to instantiate a Verilog module in VHDL sources or viceversa, as you can with some commercial tools. However, since GHDL supports VHPIDIRECT and/or VPI, and other tools for Verilog exist which provide similar features, you can write your own orchestrator in any C-compatible language (say C, C++, Python, Ruby, Go?, Rust?, etc.). E.g.:
Further notes:
There have been, and still are, multiple efforts to better integrate GHDL with other simulation environments, but I am not aware of any 'working' prototype:
@tgingold, I'm thinking that it would be friendlier for users if GHDL emitted a different error message when trying to elaborate a design with a standard version but files were analyzed with a different version. Instead of 'unit not found in library lib', something like 'unit not found in library lib for std version XX, but available for std version(s): ... Did you forget |
I had some gray hairs when I started using 2008 because that was what vunit used. I did not understand what was wrong until I saw that my work-obj08.cf differed from my my_utils-obj93.cf and had the bright idea to re-analyse my utils in the newer standard. |
I think that we must revisit how ghdl handles vhdl revision. And do like the commercial simulators.
|
In practice, does that mean to make |
Might be more complex as files must have the same view of ieee files.
|
there is still one thing I didn't understand yet: 93 Standard is part of both compatible and incompatible sets. I analysed with all standards and elaborated with 93. It doesn't seem as if 93 is incompatible with compatible standards in GHDL. Is it a typo? |
87 is only compatible with itself, 93, 00 and 02 are compatible, and 08 is only compatible with itself.
Can you point to the typo ? I am not sure where it is.
|
I think this might be just a 'wording' or 'understanding' issue. @arcturus140, in this context, 'incompatible' does not mean that GHDL will fail/crash if you mix different versions. Non-compatible sources are just ignored. Hence, if you have two files, ghdl -a --std=87 entity.vhd
ghdl -a --std=93 entity.vhd
ghdl -a --std=00 entity.vhd
ghdl -a --std=02 entity.vhd
# One of these will fail because `entity.vhd` does not exist in `work/v08/*.cf`.
# I.e., you will get the same result as if you had not executed the four commands above.
ghdl -a --std=08 arch.vhd
ghdl -e --std=08 myentity By the same token, ghdl -a --std=08 entity.vhd arch.vhd
# This will fail because `myentity` is not found.
# I.e., you can 'rm -rf work/v08', the error should be the same.
# However, if you analized both files with '--std=00' or '--std=02', this elaboration command would work.
ghdl -e --std=93 myentity Precisely, this last case is the one that described @svenn71 above, and the one I find quite frequently. That's why I suggested to provide two different errors: 'does not exist' and/or 'it exists, but in a non-compatible version'. Currently, both of these cases are reported as 'does not exist'. |
@1138-4eb I think all of these would fail with a black box warning or missing entity failure because std=08 can not be elaborated with sources analysed using any other standard. I have an understanding problem: (from read the dox)
as already mentioned, 87 and 08 are only compatible with itself. 93, 93c, 00 and 02 can be mixed. 93 is both compatible and incompatible. |
Ok. I get you now. It might be a wording problem, not necessarily an understanding problem. Let me rewrite it for you:
I think this is because most of the tools accept Group B at least. Hence, VHDL 1993 or 93 is commonly used as 'neither 87 nor 08'. |
It all makes sense now. I didn't see that there are only 3 types of library files. In the documentation, I would rename the groups into '87', '93' and '08' as it reflects the library file names.
Instead of
Library database
I can edit the documentation if you find it befitting, but not before I return from vacation by the end of next week. |
Ok. Feel free to improve the doc and create a PR (after your vacations). |
You can name it
Furthermore, you might want to:
Note that this is mostly a checklist for myself. I won't be able to update the docs again this month, so I'll complete in a future update whatever is left. |
what is a |
The For completeness, it is an intermediate file that is generated when docs are compiled to tex and then to dvi. There is a make target for it.
I normally use the bash script or the fork. But it is up to you. |
The tool I am using must not have VHDL-2008 standard as the top level entity. The documentation of GHDL states that
So 93 is compatible with 93c, 00 and 02 but incompatible with 87 and 08.
87 is not compatible with 93 and 08.
This is clear but is 87 compatible with the rest? Same for 08. I only need the non-2008 for the wrapper the rest of the design is VHDL-2008.
Another question: Is there any way to link Verilog sources with VHDL? I found a discussion about this for iVerilog, which appearently has limited VHDL support and development on VHDL support has been abandoned (never used iVerilog I am not too well informed).
The text was updated successfully, but these errors were encountered: