mixing VHDL-2008 with other standards?

[arcturus140]

The tool I am using must not have VHDL-2008 standard as the top level entity. The documentation of GHDL states that

The 93, 93c, 00 and 02 standards are considered compatible: you can elaborate a design mixing these standards. However, 87, 93 and 08 are not compatible.

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).

[tgingold]

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.

[eine]

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 --std. This means that any file analyzed with --std=93 is not found if you try to elaborate with --std=08. Hence, you can use a different standard to analyze the top level entity, but you won't be able to elaborate all the design together by doing so.

The tool I am using must not have VHDL-2008 standard as the top level entity.

Nevertheless, you should be able to write your top level entity with 1993 syntax, but have GHDL analyze it with --std=08. I have successfully used this approach to e.g. simulate VHDL output from Vivado HLS (non VHDL 2008) along with VUnit Verification Component libraries (requires VHDL 2008) using GHDL.

In the worst case, you could have an outer VHDL 1993 top level, a 1993-to-2008 wrapper and your 'real' 2008 top level.

Does this mean a VHDL-2008 source cannot be linked with any other standard in GHDL? I only need the non-2008 for the wrapper.

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 --synth; or yosys, through ghdlsynth-beta).

Currently, the output of ghdl --synth is not very usable, mostly for debugging purposes. But, in the future, it will be either an EDIF or VHDL file. Then, it will be possible to use GHDL to convert source files in any version of the standard to some common representation which will be hopefully compatible with tools that are not up-to-date. However, on the one hand, note that this feature will be limited to the synthesizable subset, because this comes from the 'synthesizable hardware description' target. On the other hand, I cannot foresee what will be the specific procedure to elaborate sets of sources with different versions of the standard and then merge the outputs together. I.e., whether it will be supported by GHDL or some external 'system level' tool will be required. I believe that it is always possible to use black boxes to delay it almost until P&R.

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.

Another question I have: 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).

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.:

• CPU soft-core written in Verilog with AXI ports. Process with Verilator and get C++ sources.
• Accelerator written in VHDL with AXI ports as top interfaces. Process with GHDL (LLVM backend) and VHPIDIRECT/VPI glue-logic in C, to generate an executable binary.
• Write 'main' C/C++ function that:
  • Allocates some memory to be used as the 'virtual interconnect' between the CPU and the accelerator.
  • In a thread, loads the GHDL binary dynamically (as a shared library) and starts the simulation after binding top interfaces to the 'virtual interconnect'.
  • In a different thread, runs the while loop that keeps the verilator sources/simulation running.

Further notes:

• It is difficult to make Verilog and VHDL modules run with exactly the same clock source. The 'virtual interconnect' is going to be a kind of FIFO that handles cross-domain synch, even though both modules run at the same speed. This is because Verilator allows to control the simulation (stop/pause, step, etc.), but GHDL runs continuously until the end. As a result, co-execution is valid for behavioural validation but not for timing analysis.
• This same approach allows to add any other tool/application (local or remote) to the 'co-execution environment', either from sources or with already compiled binaries.

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:

• https://github.com/orsonmmz/mhdlsim
• https://github.com/FOSSEE/nghdl
• Replace FreeHDL by GHDL Qucs/qucs#830

---

@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 --std?'. Is this feasible or must GHDL ignore libraries for any version other than the selected one?

[svenn71]

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.

[tgingold]

I think that we must revisit how ghdl handles vhdl revision. And do like the commercial simulators.

[eine]

I think that we must revisit how ghdl handles vhdl revision. And do like the commercial simulators.

In practice, does that mean to make --std an analysis option only?

[tgingold]

Might be more complex as files must have the same view of ieee files.

[arcturus140]

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?

[tgingold]

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.

[eine]

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, entity.vhd and arch.vhd:

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'.

[arcturus140]

@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)

The 93, 93c, 00 and 02 standards are considered compatible: you can elaborate a design mixing these standards. However, 87, 93 and 08 are not compatible.

---

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.

[eine]

Ok. I get you now. It might be a wording problem, not necessarily an understanding problem. Let me rewrite it for you:

Group A: 87
Group B: 93, 93c, 00 and 02
Group C: 08

The 93, 93c, 00 and 02 standards in each group are considered compatible: you can elaborate a design mixing these standards. However, 87, 93 and 08 standards of different groups are not compatible.

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'.

[arcturus140]

It all makes sense now. I didn't see that there are only 3 types of library files. In the documentation, VER is used for VHDL standard: --std=VER and VHDL version: NAME-objVER.cf.

I would rename the groups into '87', '93' and '08' as it reflects the library file names.

Multiple standards can be used in a design:

VER	VHDL Standard
87	87
93	93, 93c, 00 and 02
08	08

The standards in each group are considered compatible: you can elaborate a design mixing these standards. However, standards of different groups are not compatible.

Instead of VER, GROUP or SET can be used. Also makes it easy to update the documentation when more standards are supported. Later, this can be used in the documentation:

[...] --std=<standard> option, where <standard> is [...]

Library database

The name of these files is NAME-objVER.cf [...]

I can edit the documentation if you find it befitting, but not before I return from vacation by the end of next week.

[tgingold]

Ok. Feel free to improve the doc and create a PR (after your vacations).

[eine]

Instead of VER, GROUP or SET can be used. Also makes it easy to update the documentation when more standards are supported. Later, this can be used in the documentation:

You can name it VER, GROUP or SET. I think that any of them is equally good as long as:

• Wherever you use the term, just link it back.
• It does not conflict with other uses of the term. I.e., rename --std=VER to --std=<standard>, as you suggest.
• You edit subsection Library database accordingly, as said.

Furthermore, you might want to:

• Put the last paragraph in https://ghdl.readthedocs.io/en/latest/references/ImplementationOfVHDL.html#vhdl-standards into a HINT, NOTE, WARNING... block.
• Add some reference/link/comment in Library commands. See context in GHDL --dir #137.

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.

[arcturus140]

what is a .texi file? Shall changes be applied there as well?
How do I build the documentation?

[eine]

what is a .texi file? Shall changes be applied there as well?

The *.texi should not be checked in the repo. You can remove it as part of your PR. Otherwise, I will do it in my next PR to the docs.

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.

How do I build the documentation?

• Use de makefile: https://github.com/ghdl/ghdl/blob/master/doc/Makefile
• Use the make script: https://github.com/ghdl/ghdl/blob/master/doc/make.ps1
• Use the build script: https://github.com/ghdl/ghdl/blob/master/doc/build.sh (this will use docker containers, so you don't need to install sphinx/latex on the host)
• Register a 'fork' in readthedocs.org to have it automatically built for you.

I normally use the bash script or the fork. But it is up to you.