Ghdl: Error in src/vital2000/timing_p.vhdl when using VHDL 2008 and Xilinx unisim primitives

[MJoergen]

Description
When making a unit with "ghdl -m" that uses VHDL 2008 and Xilinx unisim primitives, I get the error

../../src/vital2000/timing_p.vhdl:152:14:error: result subtype of a pure function cannot have access subelements

Expected behavior
Since the file indicated (timing_p.vhdl) is part of the GHDL distribution, I expect the compilation to work without error.

Context

• OS: Ubuntu 18.04 LTS
• Origin: Version tagged as release 0.35:
  Built from sources. Commit SHA: eb5499b1859680f2b94f89c5eabf544946af4ba3

Additional context
The full sequence of commands I'm using are the following

ghdl -i --std=08 --work=unisim /opt/Xilinx/Vivado/2017.3/data/vhdl/src/unisims/unisim_VCOMP.vhd
ghdl -i --std=08 --work=unisim /opt/Xilinx/Vivado/2017.3/data/vhdl/src/unisims/unisim_VPKG.vhd
ghdl -i --std=08 --work=unisim /opt/Xilinx/Vivado/2017.3/data/vhdl/src/unisims/primitive/*.vhd
ghdl -i --std=08 --work=work test.vhd
ghdl -m --std=08 tb

The last command exits with the above mentioned error.

How to reproduce?

#>> test.vhd
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std_unsigned.all;

library unisim;
use unisim.vcomponents.all;

entity tb is
end entity tb;

architecture behavioral of tb is

   constant G_WIDTH : natural := 8;
   signal wr_clk_i   : std_logic;
   signal wr_rst_i   : std_logic;
   signal wr_en_i    : std_logic;   -- Push data into the fifo
   signal rd_clk_i   : std_logic;
   signal rd_rst_i   : std_logic;
   signal rd_en_i    : std_logic;   -- Pull data from the fifo

   -- Signals valid @ wr_clk_i
   signal wr_fifo_di  : std_logic_vector(63 downto 0);
   signal wr_fifo_dip : std_logic_vector( 7 downto 0);
   signal wr_afull    : std_logic;
   signal wr_error    : std_logic;

   -- Signals valid @ rd_clk_i
   signal rd_fifo_do  : std_logic_vector(63 downto 0);
   signal rd_fifo_dop : std_logic_vector( 7 downto 0);
   signal rd_empty    : std_logic;
   signal rd_error    : std_logic;

begin  -- architecture behavioral

   -- Instantiate the Xilinx fifo
   inst_FIFO18E1 : FIFO36E1
      GENERIC MAP (
         FIRST_WORD_FALL_THROUGH => true,
         DATA_WIDTH              => (G_WIDTH*9)/8,
         EN_SYN                  => false)
      PORT MAP (
         DI            => wr_fifo_di,
         DIP           => wr_fifo_dip,
         WREN          => wr_en_i,
         WRCLK         => wr_clk_i,
         RDEN          => rd_en_i,
         RDCLK         => rd_clk_i,
         RST           => rd_rst_i,
         RSTREG        => '0',
         REGCE         => '0',
         DO            => rd_fifo_do,
         DOP           => rd_fifo_dop,
         FULL          => open,
         ALMOSTFULL    => wr_afull,
         EMPTY         => rd_empty,
         ALMOSTEMPTY   => open,
         RDCOUNT       => open,
         WRCOUNT       => open,
         WRERR         => wr_error,
         RDERR         => rd_error,
         INJECTDBITERR => '0',
         INJECTSBITERR => '0');

end architecture behavioral;


#>> sim.sh
ghdl -i --std=08 --work=unisim /opt/Xilinx/Vivado/2017.3/data/vhdl/src/unisims/unisim_VCOMP.vhd
ghdl -i --std=08 --work=unisim /opt/Xilinx/Vivado/2017.3/data/vhdl/src/unisims/unisim_VPKG.vhd
ghdl -i --std=08 --work=unisim /opt/Xilinx/Vivado/2017.3/data/vhdl/src/unisims/primitive/*.vhd
ghdl -i --std=08 --work=work test.vhd
ghdl -m --std=08 tb

#>> run.sh
docker run --rm -tv /$(pwd):/src:z -w //src ghdl/ghdl:buster-mcode sh -c ./sim.sh

#>> end

Note that run.sh is used to execute sim.sh inside a docker container. Please, put your commands in sim.sh and just copy run.sh from the example. Using ghdl/ghdl:* docker images to run the MWEs ensures that the latest available GHDL is used.

Files
N/A

Checklist
Before submitting your issue, please review the following checklist:

• [N/A ] Add GHDL Bug occurred log block
• [* ] Add a MWE
• [* ] Try the latest version

[diogratia]

I had an email exchange with Tristan on pure/impure functions in April of this year where he brought up the case of VITAL having functions that were improperly not labelled as impure under -2008.

The gist being IEEE 1076.4-2000 has been withdrawn and the IEEE has stated the consequence of that:

https://standards.ieee.org/findstds/standard/1076.4-2000.html

STATUS: Withdrawn Standard

Touch the question mark and a pop-up will give the meaning:

Withdrawn Standard - A standard which is no longer maintained and which may contain significant obsolete or erroneous information.

Withdrawn Date:2009-01-26

While the site has been since 'improved' removing the pop-up, the consequences remain. The VITAL (VHDL Initiative Towards ASIC Libraries) standard contains significant obsolete or erroneous information.

IEEE-SA STANDARDS BOARD OPERATIONS MANUAL

1. Review of IEEE standards

9.1 Revision
The Sponsor should initiate revision of a standard whenever any of the material in the standard (including all amendments, corrigenda, etc.) becomes obsolete or incorrect, or if three or more amendments to a base standard exist three years after its approval. The Sponsor may initiate revision of a standard when new material becomes available and normal evaluation of need and feasibility indicates revision is warranted. The procedure for revising a standard is the same as for developing a new standard. A revision shall encompass the cumulative scope of the project (including all approved amendments and corrigenda).

Instead of revision we saw the VITAL standard withdrawn the same day the VHDL-2008 revision was published (Published Date:2009-01-26, there appears to be a causal relationship here).

The error is valid:

IEEE Std 1076-2008 4.2 Subprogram declarations, 4.2.1 General:

It is an error if the result subtype of a function denotes either a file type or a protected type. Moreover, it is an error if the result subtype of a pure function denotes an access type or a subtype that has a subelement of an access type.

This paragraph is new to -2008 and such a function is impure. Adding it comes under the heading of insuring pure functions are formal notation for the subset of VHDL that describes hardware and not simulation modeling.

You could note that IEEE doesn't claim copyright to the VITAL_Timing package. Is there any consequence to your use of the VITAL packages resulting from marking function VitalTimingDataInit in file timing_p.vhdl as impure? (Noting there may be other cases).

Otherwise a VITAL specific relaxed rule would be required for ghdl (or indirection methods developed for any functions needing to remain pure, or VITAL use confined to previous revisions of the VHDL standard).

You could also note FPGA vendors provide their own means of timing closure based on the limited variability in routing and controlled fan out.

You'd find Tristan already has implemented one choice, using -frelaxed-rules to change that error to a warning:

ghdl -a --std=08 -frelaxed-rules timing_p.vhdl
timing_p.vhdl:152:14:warning: result subtype of a pure function cannot have access subelements [-Wpure]

[tgingold]

You should try with -frelaxed-rules

[Paebbels]

You can use compile-xilinx-vivado.sh from lib/vendors delivered with GHDL. It precompiles all Xilinx libraries (of Vivado).

Documentation: GHDL on ReadTheDocs -> Pre-compiling Vendor Primitives
Precompile script: libraries/vendors/compile-xilinx-vivado.sh

[Paebbels]

This is a duplicate of #247.