UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Scholar richardhead
Scholar
1,331 Views
Registered: ‎08-01-2012

Simulating XPM FIFO in ActiveHDL - Error with 2018.2 libraries

I have a VHDL design simulated inside a VHDL testbench that contains an XPM FIFO, instatiated manually (no coregen).

 

When I simulate it using 2018.2 libraries provided by Aldec, I get the following error during elaboration

 

ELAB2: Fatal Error: ELAB2_0036 Unresolved hierarchical reference to "glbl.GSR" from module "flow_capture_tb.uut_inst.hdr_extract_inst.pkt_hdr_fifo.gnuram_async_fifo.xpm_fifo_base_inst.xpm_fifo_rst_inst.gen_rst_ic.wrst_rd_inst" (module not found).
ELAB2: Last instance before error: /flow_capture_tb/uut_inst/hdr_extract_inst/pkt_hdr_fifo/gnuram_async_fifo/xpm_fifo_base_inst/xpm_fifo_rst_inst/gen_rst_ic/wrst_rd_inst
KERNEL: Error: E8005 : Kernel process initialization failed.

 

This error does not occur when I use the 2017.2.1 libraries

0 Kudos
14 Replies
Scholar richardhead
Scholar
1,328 Views
Registered: ‎08-01-2012

Re: Simulating XPM FIFO in ActiveHDL - Error with 2018.2 libraries

For reference, here is the instantiation:

 

-- go from 156.25 to 202.5 mhz.
    pkt_hdr_fifo : xpm_fifo_async
    generic map (

      FIFO_MEMORY_TYPE          => "distributed",        --string; "auto", "block", "distributed", or "ultra" ;
      FIFO_WRITE_DEPTH          => 32,
      RELATED_CLOCKS            => 0,
      WRITE_DATA_WIDTH          => pkt_fifo_din'length,
      WR_DATA_COUNT_WIDTH       => 5,
      READ_MODE                 => "fwft",        --string; "std" or "fwft";
      FIFO_READ_LATENCY         => 1,
      FULL_RESET_VALUE          => 0,
      READ_DATA_WIDTH           => pkt_fifo_dout'length,
      RD_DATA_COUNT_WIDTH       => 5,
      CDC_SYNC_STAGES           => 2,
      ECC_MODE                  => "no_ecc",      --string; "no_ecc" or "en_ecc";
      PROG_FULL_THRESH          => 10,
      PROG_EMPTY_THRESH         => 10,
      DOUT_RESET_VALUE          => "0",
      WAKEUP_TIME               => 0
    )
    port map (

      rst                   => srst_ipclk,

      -- Write Interface
      wr_clk                => ip_clk,
      wr_en                 => pkt_fifo_we,
      din                   => pkt_fifo_din,
      full                  => open,        -- Should never go full

      -- Read Interface
      rd_clk                => sys_clk,
      rd_en                 => pkt_rd_en,
      dout                  => pkt_fifo_dout,
      empty                 => pkt_fifo_empty,

      wr_rst_busy           => open,
      underflow             => pkt_fifo_underflow,
      rd_rst_busy           => open,
      overflow              => pkt_fifo_overflow,
      prog_full             => open,
      wr_data_count         => open,
      prog_empty            => open,
      rd_data_count         => open,
      sleep                 => '0',
      injectsbiterr         => '0',
      injectdbiterr         => '0',
      sbiterr               => open,
      dbiterr               => open
    );
0 Kudos
Xilinx Employee
Xilinx Employee
1,318 Views
Registered: ‎07-16-2008

回复: Simulating XPM FIFO in ActiveHDL - Error with 2018.2 libraries

Did you compile the following glbl.v along with the design sources?

$XILINX_VIVADO/data/verilog/src/glbl.v

You also need to load the glbl together with the top level.

e.g. vsim <options> work.tb work.glbl

-------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Scholar richardhead
Scholar
1,315 Views
Registered: ‎08-01-2012

回复: Simulating XPM FIFO in ActiveHDL - Error with 2018.2 libraries

The libraries are provided pre-compiled by Aldec.
I do not need to load glbl with 2017.2 version.
0 Kudos
Scholar brimdavis
Scholar
1,291 Views
Registered: ‎04-26-2012

回复: Simulating XPM FIFO in ActiveHDL - Error with 2018.2 libraries

@richardhead   "The libraries are provided pre-compiled by Aldec."

It's been a while since I've used Aldec, but IIRC glbl.v was never precompiled by Aldec.
When using a mixed language or Verilog flow, you needed to compile glbl.v yourself and put it at the top level with your testbench.

>
> I do not need to load glbl with 2017.2 version.
>
It looks like Xilinx changed the xpm_cdc library (used by the FIFOs) in 2018.2 - now all simulators use the glbl.GSR reset (only turned off for a formal verification flow), whereas in 2017.x only certain simulators did:

 

C:\Xilinx\Vivado\2018.2\data\ip\xpm\xpm_cdc\hdl\xpm_cdc.sv

  // -------------------------------------------------
// Simulation only variable and signal assignment // -------------------------------------------------
// synthesis translate_off `ifndef ONESPIN `define XPM_CDC_BHVSIM_ONLY tri0 glblGSR_xpmcdc = glbl.GSR; `endif // synthesis translate_on

 

C:\Xilinx\Vivado\2017.4\data\ip\xpm\xpm_cdc\hdl\xpm_cdc.sv

  // ------------------------------------------------
  // Simulation only variable and signal assignment
  // ------------------------------------------------
  // synthesis translate_off
  `ifdef VCS
    `define XPM_CDC_BHVSIM_ONLY
    tri0 glblGSR_xpmcdc = glbl.GSR;
  `endif
  `ifdef INCA
    `define XPM_CDC_BHVSIM_ONLY
    tri0 glblGSR_xpmcdc = glbl.GSR;
  `endif
  `ifdef MODEL_TECH
    `define XPM_CDC_BHVSIM_ONLY
    tri0 glblGSR_xpmcdc = glbl.GSR;
  `endif
  `ifdef XILINX_SIMULATOR
    `define XPM_CDC_BHVSIM_ONLY
    tri0 glblGSR_xpmcdc = glbl.GSR;
  `endif
  `ifdef _VCP
    `define XPM_CDC_BHVSIM_ONLY
    tri0 glblGSR_xpmcdc = glbl.GSR;
  `endif
  // synthesis translate_on

-Brian

Scholar richardhead
Scholar
1,276 Views
Registered: ‎08-01-2012

回复: Simulating XPM FIFO in ActiveHDL - Error with 2018.2 libraries

Well this is an unwelcome and undocumented change.

This is only a unit test - so why would I put a global reset in there? I have no intention of using a global reset in a unit test. It is not used in my unit.

 

Why does Xilinx insist on using the global reset in this way? Why cant it be a port to the design like everything else so people can chose just to connect it to '0', rather than hiding it away and insisting we have one in the testbench?

 

The next question is where do I even get glbl.v from?

0 Kudos
Scholar richardhead
Scholar
1,267 Views
Registered: ‎08-01-2012

回复: Simulating XPM FIFO in ActiveHDL - Error with 2018.2 libraries

Interestingly, in the code supplied by Aldec for 2017.2.1, there is no mention of glbl anywhere in the code for the XPM. 

I guess I can just modify the xilinx code to remove the glbl reference.

0 Kudos
Scholar brimdavis
Scholar
1,257 Views
Registered: ‎04-26-2012

回复: Simulating XPM FIFO in ActiveHDL - Error with 2018.2 libraries

@richardhead  "The next question is where do I even get glbl.v from?"

 

As mentioned up-thread by graces: 

  C:\Xilinx\Vivado\2018.2\data\verilog\src\glbl.v

 

See also the "Running RTL/Behavioral Simulation" section of this Aldec webpage:

   https://www.aldec.com/en/support/resources/documentation/articles/1674

 

>

> I guess I can just modify the xilinx code to remove the glbl reference.

>

If I'm following Xilinx's 2018.2 code correctly, you could just define that ONESPIN Verilog macro in your design to turn off the globals, without needing to edit the library source code.

 

>

> Well this is an unwelcome and undocumented change.

>

There seems to be a bit of churn in the XPM libraries, particularly in the FIFO reset code.

 

Overall, I am not a fan of the XPM's  - the concept is fine, the implementation is not:

 - Unlike the UNIMACROs they replace, there is no support for single language VHDL RTL simulation [1]

 - Last I checked, using XPM with third party simulators required both SystemVerilog and SVA licenses ($$$)

 

-Brian

 

[1] https://forums.xilinx.com/t5/Simulation-and-Verification/no-VHDL-simulation-models-for-XPM-s/td-p/813397

0 Kudos
Scholar richardhead
Scholar
1,248 Views
Registered: ‎08-01-2012

回复: Simulating XPM FIFO in ActiveHDL - Error with 2018.2 libraries

 - Last I checked, using XPM with third party simulators required both SystemVerilog and SVA licenses ($$$)

Thats true, but I got Aldec support to re-compile the libraries to remove the SVA (funny how Xilinx sim just ignores SVA!). I can modify the code to pretend to be onespin!

 

I also agree - XPM is a good idea, and clearly arrived because people wanted something similar to Altera's altsyncram and SC/DCFIFO blocks, that can be used just like XPM blocks. But altera have had these for 10+ years.

0 Kudos
Scholar richardhead
Scholar
574 Views
Registered: ‎08-01-2012

回复: Simulating XPM FIFO in ActiveHDL - Error with 2018.2 libraries

@graces

This is still an issue with 2018.2.2 libraries.

I want to use the XPM async fifo in a VHDL testbench, and is assumes I have a GSR module called "glbl" as a top level (because SV allows multiple top levels). In  a VHDL testbench, you can only have one top level - the testbench. In addition, you cannot even instantiate the glbl module with the name "glbl"

Hence the reference to glbl in the cdc code always fails (line 960 in xpm_cdc.sv):

// -------------------------------------------------------------------------------------------------------------------
// Simulation only variable and signal assignment
// -------------------------------------------------------------------------------------------------------------------
// synthesis translate_off
  `ifndef ONESPIN
    `define XPM_CDC_BHVSIM_ONLY
    tri0 glblGSR_xpmcdc = glbl.GSR;
  `endif
// synthesis translate_on

The only workaround is to modify this file either by adding the following define to the xpm_cdc.sv (just below the line "DO NOT EDIT THIS FILE" - the irony)

`define ONESPIN

Or diconnect the GSR (which isnt needed anyway - my testbench provides a reset)!

Can you confirm you are going to raise a ticket against this? It currently makes it impossible to use XPM_FIFO_ASYNC in a VHDL testbench without the HACK below.

 

Btw: if you want to run XPM in ActiveHDL and you dont have an SVA licence, heres the steps to remove SVA:

1. Open <activeHDL_install>/vlib/xilinx_vivado/src/update_xpm.do

2. replace the contents with (also add the `ONESPIN hack above to xpm_cdc.sv):

set OPT -dbg

setlibrarymode -rw xpm
#clearlibrary

#cd $dsn
alog -sv2k12 -work xpm -na all $OPT .\src\glbl.v
alog -sv2k12 -work xpm -na all $OPT .\src\xpm_cdc.sv
alog -sv2k12 -work xpm -na all $OPT .\src\xpm_fifo.sv
alog -sv2k12 -work xpm -na all $OPT .\src\xpm_fifo_tb.sv
alog -sv2k12 -work xpm -na all $OPT .\src\xpm_memory.sv
acom -2008 -work xpm $OPT .\src\xpm_VCOMP.vhd

setlibrarymode -ro xpm

3. Ensure you have <activeHDL>/bin/ in your $PATH variable

4. Open a command window and navigate to <activeHDL_install>/vlib/xilinx_vivado/

5. run the command:

vsimsa -do ./src/update_xpm.do

You've now removed SVA and the annoying requirement for a GSR module in your testbench (which is impossible in a VHDL testench anyway!)

0 Kudos
Scholar richardhead
Scholar
567 Views
Registered: ‎08-01-2012

回复: Simulating XPM FIFO in ActiveHDL - Error with 2018.2 libraries

@graces

There actually appears to be some odd behaviour when I hack it. It overflows on the first write.

The only workaround appears to be to use the 2017.2 version of the xpm library for now as this doesnt have the annoying GSR requirement.

This code works fine compiled in 2018.2.1 on the board.

I would rather use the 2018.2 simulation libraries, but appears I am blocked from doing so.

0 Kudos
Scholar richardhead
Scholar
553 Views
Registered: ‎08-01-2012

回复: Simulating XPM FIFO in ActiveHDL - Error with 2018.2 libraries

@graces

I would really like to know if you are going to raise a ticket for this or if Xilinx are basically dropping all VHDL simulatiuon support with new libraries?

Otherwise, please can you provide a useful workaround.

0 Kudos
Scholar richardhead
Scholar
514 Views
Registered: ‎08-01-2012

回复: Simulating XPM FIFO in ActiveHDL - Error with 2018.2 libraries

Can I not get any comment from someone at Xilinx?

It seems a really poor solution to have to fall back on the 2017.2 libraries because the code will currently not work with a VHDL testbench, even though I have a mixed language AHDL licence? This will affect all simulators, not just ActiveHDL. The way the code currently works requires a dual top level, which is only possible in Verilog.

0 Kudos
Xilinx Employee
Xilinx Employee
505 Views
Registered: ‎07-16-2008

回复: Simulating XPM FIFO in ActiveHDL - Error with 2018.2 libraries

Can you provide a test case demonstrating the issue that you encountered in mixed language design (VHDL tb + XPM sources)?

-------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Scholar richardhead
Scholar
494 Views
Registered: ‎08-01-2012

回复: Simulating XPM FIFO in ActiveHDL - Error with 2018.2 libraries

Ok, so I admit this is mostly a problem of me not understanding how to set up multiple top levels in ActiveHDL. I have now done this an I am able to setup testbenches that use the LPM_FIFO_ASYNC within them

But I am still concerned/worried about Xilinx IP generating it's own reset (The GSR). The current model has a 100 ns reset, and getting hold of it in a VHDL testbench in order to avoid driving the ASYNC FIFO is non-trivial. I need to create a verilog module that outputs the GSR as a signal, a VHDL component that maps this compoent to a VHDL entity and outputs the signal:

`timescale 1ps / 1ps

module gsr_hook_v (
  output wire GSR
);

assign GSR = glbl.GSR;

endmodule : gsr_hook_v
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

entity gsr_hook is
  port (
    GSR     : out std_logic
  );
end entity gsr_hook;

architecture hook of gsr_hook is
  component gsr_hook_v is
  port (
    GSR : out std_logic
  );
  end component gsr_hook_v;
begin

  hooker : gsr_hook_v
  port map ( GSR => GSR );

end architecture hook;

Could the glbl module be modified so that the glbl has outputs that are assigned to the GSR, rather than relying on heirarchical references to the glbl module? 

I doubt many VHDL engineers have the nouse to setup a dual top level testbench, let alone map the GSR signal out like I have above? Why does the ASYC FIFO even need a GSR (it worked just fine in 2017.2)?

0 Kudos