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: 
Adventurer
Adventurer
11,512 Views
Registered: ‎10-11-2011

EDK pcore HDL files not being found by Vivado

Jump to solution

I'm building a Vivado project (2013.2) with an embedded source from EDK.  In the embedded source, I'm using a pcore from a user peripheral repository.  The pcore is a mix of Verilog and VHDL files.  I placed the HDL modules in a library by editing the PAO file:

 

lib proc_common_v3_00_a all 
lib axi_lite_ipif_v1_01_a all 
lib axi_master_burst_v1_00_a all 
lib orsoc_gpu_v1_00_a basic_fifo verilog  ## custom files start here
lib orsoc_gpu_v1_00_a div_uu verilog
lib orsoc_gpu_v1_00_a gfx_blender verilog
lib orsoc_gpu_v1_00_a gfx_clip verilog
lib orsoc_gpu_v1_00_a gfx_color verilog
lib orsoc_gpu_v1_00_a gfx_cuvz verilog
lib orsoc_gpu_v1_00_a gfx_fragment_processor verilog
lib orsoc_gpu_v1_00_a gfx_interp verilog
lib orsoc_gpu_v1_00_a gfx_line verilog
lib orsoc_gpu_v1_00_a gfx_params verilog
lib orsoc_gpu_v1_00_a gfx_rasterizer verilog
lib orsoc_gpu_v1_00_a gfx_renderer verilog
lib orsoc_gpu_v1_00_a gfx_transform verilog
lib orsoc_gpu_v1_00_a gfx_triangle verilog
lib orsoc_gpu_v1_00_a gfx_wbm_read_arbiter verilog
lib orsoc_gpu_v1_00_a gfx_wbm_read verilog
lib orsoc_gpu_v1_00_a gfx_wbm_write verilog
lib orsoc_gpu_v1_00_a gfx_wbs verilog
lib orsoc_gpu_v1_00_a timescale verilog
lib orsoc_gpu_v1_00_a gfx_top verilog
lib orsoc_gpu_v1_00_a orsoc_gpu vhdl

 

In the orsoc_gpu.vhd file, I create an instantiation of gfx_top like this:

 

...

library orsoc_gpu_v1_00_a;
use orsoc_gpu_v1_00_a.all;

...

    ORSOC_GFX_TOP: entity orsoc_gpu_v1_00_a.gfx_top
    port map (
        wb_clk_i            => wb_clk_i,
        wb_rst_i            => rst_i,
        wb_inta_o           => wb_inta_o,

        wbm_write_cyc_o     => wbm_write_cyc_o,
        wbm_write_stb_o     => wbm_write_stb_o,
        wbm_write_cti_o     => wbm_write_cti_o,
        wbm_write_bte_o     => wbm_write_bte_o,
        wbm_write_we_o      => wbm_write_we_o,
        wbm_write_adr_o     => wbm_write_adr_o,
        wbm_write_sel_o     => wbm_write_sel_o,
        wbm_write_ack_i     => wbm_write_ack_i,
        wbm_write_err_i     => wbm_write_err_i,
        wbm_write_dat_o     => wbm_write_dat_o,

        wbm_read_cyc_o      => wbm_read_cyc_o,
        wbm_read_stb_o      => wbm_read_stb_o,
        wbm_read_cti_o      => wbm_read_cti_o,
        wbm_read_bte_o      => wbm_read_bte_o,
        wbm_read_we_o       => wbm_read_we_o,
        wbm_read_adr_o      => wbm_read_adr_o,
        wbm_read_sel_o      => wbm_read_sel_o,
        wbm_read_ack_i      => wbm_read_ack_i,
        wbm_read_err_i      => wbm_read_err_i,
        wbm_read_dat_i      => wbm_read_dat_i,

        wbs_cyc_i           => wbs_cyc_i,
        wbs_stb_i           => wbs_stb_i,
        wbs_cti_i           => wbs_cti_i,
        wbs_bte_i           => wbs_bte_i,
        wbs_we_i            => wbs_we_i,
        wbs_adr_i           => wbs_adr_i,
        wbs_sel_i           => wbs_sel_i,
        wbs_ack_o           => wbs_ack_o,
        wbs_err_o           => wbs_err_o,
        wbs_dat_i           => wbs_dat_i,
        wbs_dat_o           => wbs_dat_o
    );

...

However, when I run synthesis, I get the following synthesis errors:

 

[Synth 8-493] no such design unit 'orsoc_gfx_top' ["<repository path>/pcores/orsoc_gpu_v1_00_a/hdl/vhdl/orsoc_gpu.vhd":208]
[Synth 8-285] failed synthesizing module 'orsoc_gpu' ["<repository path>/pcores/orsoc_gpu_v1_00_a/hdl/vhdl/orsoc_gpu.vhd":202]
[Synth 8-285] failed synthesizing module 'system_orsoc_gpu_0_wrapper' ["<vivado project path>/project_1.srcs/sources_1/edk/system/hdl/system_orsoc_gpu_0_wrapper.vhd":52]
[Synth 8-285] failed synthesizing module 'system' ["<vivado project path>/project_1.srcs/sources_1/edk/system/hdl/system.vhd":46]
[Synth 8-285] failed synthesizing module 'system_stub' ["<vivado project path>/project_1.srcs/sources_1/imports/system/system_stub.vhd":46]

So, for some reason Vivado finds the pcore top-level orsoc_gpu.vhd, but does not recognize the rest of the files in the pcore.  If I build the project directly from XPS, the files are recognized as expected.  What might I have to do to get Vivado to recognize the rest of the files, preferably so I can still use the library notation in the HDL?

0 Kudos
1 Solution

Accepted Solutions
Scholar brimdavis
Scholar
14,527 Views
Registered: ‎04-26-2012

Re: EDK pcore HDL files not being found by Vivado

Jump to solution

> So, for some reason Vivado finds the pcore top-level orsoc_gpu.vhd, but does not recognize the rest of the files in the pcore. 

 

I haven't used XPS within Vivado in this fashion, but I suspect your problems might be related to the recently-discussed bug with Vivado synthesis, which DOES NOT ALLOW direct instantiation of a Verilog component in VHDL.

 

AR# 47454 Vivado Synthesis - Does Vivado Synthesis support Verilog Module instantiation in a VHDL entity via work library?

 

So, with Vivado, you now need to have component declarations for any Verilog modules instantiated within a VHDL design.

 

I'd suggest that you create a package file with the Verilog component declarations, rewrite your VHDL code to eliminate the direct entity instantiations, and see if things build OK.

 

If that does turn out to be your problem, and you have webcase access, I would also suggest you file a webcase with Xilinx to fix this &#$!! bug in Vivado.
 

-Brian

0 Kudos
16 Replies
Scholar markcurry
Scholar
11,501 Views
Registered: ‎09-16-2009

Re: EDK pcore HDL files not being found by Vivado

Jump to solution

 

PAO are another one of those Xilinx "let's create yet another filetype, that's ill-defined, not documented".  When it works in the various wizards flows - great.  Step outside the wizards and well, you're on your own.  (In case it's not clear, I'm NOT a fan of their "wizards").

 

Anyway, we used to try and parse PAO files with scripts.  Xilinx kept tweaking the format in between releases, and our scripts broke.  We're moving towards converting any PAO files we need by hand.

 

It's basically just a list of files - for VHDL it can (optionally) include a library name.

 

So, we create TCL files - most tools these days interpret TCL.  An example's easiest.  This is from the axi_lite_ipif pao file:

 

lib proc_common_v3_00_a  all
lib axi_lite_ipif_v1_01_a  address_decoder.vhd vhdl
lib axi_lite_ipif_v1_01_a  slave_attachment.vhd vhdl
lib axi_lite_ipif_v1_01_a  axi_lite_ipif.vhd vhdl

 

Here's the TCL we create from the above (this is the WHOLE file).

 

source $topdir/shared/pcores/proc_common_v3_00_a/proc_common.tcl
eval $vh -work axi_lite_ipif_v1_01_a $topdir/shared/pcores/axi_lite_ipif_v1_01_a/hdl/vhdl/address_decoder.vhd
eval $vh -work axi_lite_ipif_v1_01_a $topdir/shared/pcores/axi_lite_ipif_v1_01_a/hdl/vhdl/slave_attachment.vhd
eval $vh -work axi_lite_ipif_v1_01_a $topdir/shared/pcores/axi_lite_ipif_v1_01_a/hdl/vhdl/axi_lite_ipif.vhd

 

The "source" line simply calls another similar TCL file with definitions for "proc_common".

The eval line does whatever's appropriate.  For modelsim it calls vcom to compile.  For XST it creates the appropriate "add_file" command for XST.  (Actually XST doesn't understand TCL, so it's indirect for XST).  For synplicty it's an "add_file -vhdl" command.  Should work for vivado too.

 

You get the idea.  The $topdir is just a variable to point to the top dir - so the TCL script can be executed from ANYWHERE in the tree, and still works. Same TCL file - multiple tools, works anywhere.  Works for both verilog and vhdl  (we use eval $vl for verilog files).  Simple to read/modify, and it's an executable script.

 

That's our solution. There's many ways to tackle.  It's all just a list of files being given to whatever tool.

 

Regards,

 

Mark

 

0 Kudos
Adventurer
Adventurer
11,496 Views
Registered: ‎10-11-2011

Re: EDK pcore HDL files not being found by Vivado

Jump to solution

Thanks for the detailed response!

 

I have other cores in the repository set up the same way (lib ... etc) that did not cause errors, so I wasn't sure why that one core specifically is causing the issue.  One difference I did notice is the other cores are all VHDL files, whereas the one causing the error contains one VHDL file and the rest Verilog.  And the synthesizer sees the VHDL file (orsoc_gpu.vhd), but doesn't seem to recognize the Verilog files...

 

Regardless, I will try implementing the TCL solution you recommended, as it would be more robust than relying on the wizard flow, plus I need more practice with TCL :)

0 Kudos
Scholar brimdavis
Scholar
14,528 Views
Registered: ‎04-26-2012

Re: EDK pcore HDL files not being found by Vivado

Jump to solution

> So, for some reason Vivado finds the pcore top-level orsoc_gpu.vhd, but does not recognize the rest of the files in the pcore. 

 

I haven't used XPS within Vivado in this fashion, but I suspect your problems might be related to the recently-discussed bug with Vivado synthesis, which DOES NOT ALLOW direct instantiation of a Verilog component in VHDL.

 

AR# 47454 Vivado Synthesis - Does Vivado Synthesis support Verilog Module instantiation in a VHDL entity via work library?

 

So, with Vivado, you now need to have component declarations for any Verilog modules instantiated within a VHDL design.

 

I'd suggest that you create a package file with the Verilog component declarations, rewrite your VHDL code to eliminate the direct entity instantiations, and see if things build OK.

 

If that does turn out to be your problem, and you have webcase access, I would also suggest you file a webcase with Xilinx to fix this &#$!! bug in Vivado.
 

-Brian

0 Kudos
Xilinx Employee
Xilinx Employee
11,458 Views
Registered: ‎06-14-2012

Re: EDK pcore HDL files not being found by Vivado

Jump to solution

You have to use the PAO file in the user guide below (Chapter 4) http://www.xilinx.com/support/documentation/sw_manuals/xilinx12_3/psf_rm.pdf

VHDL libraries can be used to share data amongst XPS peripherals in a Xilinx Microblaze FGPA implementation.  The same libraries can also be used with the test benches for individual peripherals.  

There are a lot of files and directories in the implementation, and finding the right place to create and configure the libraries be time-consuming for even experienced VHDL developers. 

This document explains a process that can be used to create a shared library that works in XPS and ISE for both synthesis and simulation.  We will use as an example the creation of a 'constants' package that will be placed in a library accessible by all project peripherals, as well as their associated test benches.


1. Decide where the shared library will be placed.  

- If the library is just to be shared amongst peripherals that are part of one processor project, it is best to use a path that is relative to each individual peripheral, but common to all the processor project peripherals.  One location is the pcores directory, as this is the first directory common to all peripherals in the project.

- If the library is shared outside the processor project, an absolute location can be chosen from the filesystem.  This may be less portable than copying a shared library into each project and treating using it as a relative path.  

This document assumes a relative path will be used, with the library location in a 'shared_libraries' subdirectory manually created in pcores, so create a 'shared_libraries' subdirectory in pcores.


2. Create the peripheral as normal within XPS, ensuring that standard VHDL templates are created by XPS.  


3. Once it is created, open an instance of ISE, and open the ISE project associated with the peripheral.  The ISE project file  will be at pcores/<peripheral_name>/devl/projnav.  It has an '.xise' extension.


4. Create the VHDL package (assuming it does not already exist).  Right click in the design pane and select New source, then select VHDL Package, and give it a filename 'constants'.  The 'Add to project' box should be selected.  By default, the new package file will be at  devl/projnav/constants.vhd.  This is not a good location for a shared package, so manually move the file to the desired shared location, in this case it will be moved to pcores/shared_libraries/constants.vhd.  It can (and probably should) be deleted from the original devl/projnav directory.

5. Open the pcores/shared_libraries/constants.vhd file, and add a constant as described in the file. In this example we insert the following line into the 'package constants is' area, as directed by the comments in the template:

constant TEST_CONSTANT_LIBRARY  : integer := 16;

This package file can be closed now, and we will reference the new constant in a peripheral, and in a test bench used by the peripheral.

6. Open the user_logic.vhdl file, and add the required library clauses.  The clauses would normally be near the top of the file, immediately below the 'LIBRARY ieee' clause and the associated 'USE' clauses which follow.  Assuming the library and package names are as described above, the clauses will be:

LIBRARY shared_libraries;
USE shared_libraries.constants.all;

The constant can be used in the file.  In this example, we simply want to show that the constant is accessible, so we will use it to select a bit in a typical peripheral read-back register.  One arbitrary example usage is shown here, where the constant is used to select a bit out of slave register 1 when slave register 0 is being read:

  SLAVE_REG_READ_PROC : process( slv_reg_read_sel, slv_reg0, slv_reg1, slv_reg2, slv_dac_data ) is
  begin

    case slv_reg_read_sel is
      when "100" => slv_ip2bus_data <= slv_reg1(TEST_CONSTANT_LIBRARY) &slv_reg0(30 downto 0);

This code will neither synthesize nor simulate unless the shared library is working, so it will be our test.

7. In the peripheral project, click on the 'Libraries' tab. Right-click in the list, and select New VHDL Library..., and enter shared_libraries as the name.  Use the button to the right of the location entry to browse to the pcores/shared_libraries directory you created earlier, and press OK, then OK again.  

An 'Adding Source Files' dialog will pop up by itself, and ask if you want to add the package(s) in that location to the project.  In this example, there is only one entry shown, which is for 'constants.vhd'.  If the file were for simulation only, or for synthesis only, we could limit the association, but in this example we deliberately want to use the same package for both.

Select OK.  Now in the ISE 'Libraries' tab for the peripheral you will see a library 'shared_libraries' listed, and it will have one package underneath it, 'constants.vhd'.  It is probably shown with no path, so right click on the entry, select File Path Display and then Relative Paths.  The entry will now appear as ..\..\..\shared_libraries\constants.vhd  .

8. The library is now accessible to the peripheral.  Assuming you already have created a testbench with a uut of user_logic, you should now be able to select the Design tab in ISE, then click on the testbench, and in the Processes below, double-click Behavioral Check Syntax.  In the Console window you should see an entry included similar to 'Parsing VHDL file ... shared_libraries/constants ...

NOTE: If you have not previously created a testbench for an XPS peripheral, you may not be aware that you need to include the necessary libraries for the peripheral in your testbench file.  These files are all in library 'work' in a typical ISE project, but they by default they are in a separate library in the peripheral.  On the 'Libraries' tab in ISE you will see a library that has the same name as the peripheral you created, including the version number and letter.  Typically there are two packages shown in the library, <peripheral_name>.vhd, and user_logic.vhd.  These are the actual files that implement the peripheral logic, so you need to add a reference to them in the testbench because the testbench only looks in 'work' by default.  The clauses that need to be added to your testbench will be similar to these, depending of course on your peripheral name:

LIBRARY sqbd_mdac_a_v1_00_a;
use sqbd_mdac_a_v1_00_a.all;


9. Confirm that ISIM is able to use the shared library by double-clicking 'Simulate Behavioral Model'.  There should not be any errors associated with a missing library or unresolved constant reference.  Note that the constants file could also be used in the testbench itself, by including the same lines as in the logic, in this example:

LIBRARY shared_libraries;
USE shared_libraries.constants.all;


10.  The peripheral project now recognizes the new library, and can access the constant.  However, if you close the peripheral project and open the overall project in ISE, synthesis will fail on library errors.  Similarly, if you go into XPS and attempt to generate a netlist (which invokes platgen anyway), it will also fail.  This is because the XPS processor project does not automatically pick up the library references from the peripheral - the required library references must be manually added into the PAO (Peripheral Analyze Order) file.

There is one PAO file for each peripheral, and it is located in the <peripheral_name>/data directory.  It is named <peripheral_name).pao  .  (In both cases the <peripheral_name> includes the full version number, not just the name you gave it, so if you create another version, you probably have to manually re-edit the PAO file again.)

An example of the line ('shared_libraries') that needs to be added is shown below.  The other entries shown are similar to the default entries that will already be in the file from the Create and Import Peripheral (CIP) wizard.  As this file determines the order of analysis, the position in the file usually matters a great deal.  In the case of something common, such as constants that do not depend on any other file, the new file will need to be the first file in the list (or at least before the file that requires them):

lib shared_libraries ../../../shared_libraries/constants.vhd     # New line for shared constants, placed first in file
# Remaining auto-generated lines follow and are left untouched:
lib proc_common_v3_00_a  all 
lib axi_lite_ipif_v1_01_a  all 
lib sqbd_mdac_a_v1_00_a user_logic vhdl
lib sqbd_mdac_a_v1_00_a sqbd_mdac_a vhdl


11. The project should now synthesize, either by synthesizing the top in ISE, or by using Generate Netlist in XPS

 

 

I hope this helps...


@david_va wrote:

I'm building a Vivado project (2013.2) with an embedded source from EDK.  In the embedded source, I'm using a pcore from a user peripheral repository.  The pcore is a mix of Verilog and VHDL files.  I placed the HDL modules in a library by editing the PAO file:

 

lib proc_common_v3_00_a all 
lib axi_lite_ipif_v1_01_a all 
lib axi_master_burst_v1_00_a all 
lib orsoc_gpu_v1_00_a basic_fifo verilog  ## custom files start here
lib orsoc_gpu_v1_00_a div_uu verilog
lib orsoc_gpu_v1_00_a gfx_blender verilog
lib orsoc_gpu_v1_00_a gfx_clip verilog
lib orsoc_gpu_v1_00_a gfx_color verilog
lib orsoc_gpu_v1_00_a gfx_cuvz verilog
lib orsoc_gpu_v1_00_a gfx_fragment_processor verilog
lib orsoc_gpu_v1_00_a gfx_interp verilog
lib orsoc_gpu_v1_00_a gfx_line verilog
lib orsoc_gpu_v1_00_a gfx_params verilog
lib orsoc_gpu_v1_00_a gfx_rasterizer verilog
lib orsoc_gpu_v1_00_a gfx_renderer verilog
lib orsoc_gpu_v1_00_a gfx_transform verilog
lib orsoc_gpu_v1_00_a gfx_triangle verilog
lib orsoc_gpu_v1_00_a gfx_wbm_read_arbiter verilog
lib orsoc_gpu_v1_00_a gfx_wbm_read verilog
lib orsoc_gpu_v1_00_a gfx_wbm_write verilog
lib orsoc_gpu_v1_00_a gfx_wbs verilog
lib orsoc_gpu_v1_00_a timescale verilog
lib orsoc_gpu_v1_00_a gfx_top verilog
lib orsoc_gpu_v1_00_a orsoc_gpu vhdl

 

In the orsoc_gpu.vhd file, I create an instantiation of gfx_top like this:

 

...

library orsoc_gpu_v1_00_a;
use orsoc_gpu_v1_00_a.all;

...

    ORSOC_GFX_TOP: entity orsoc_gpu_v1_00_a.gfx_top
    port map (
        wb_clk_i            => wb_clk_i,
        wb_rst_i            => rst_i,
        wb_inta_o           => wb_inta_o,

        wbm_write_cyc_o     => wbm_write_cyc_o,
        wbm_write_stb_o     => wbm_write_stb_o,
        wbm_write_cti_o     => wbm_write_cti_o,
        wbm_write_bte_o     => wbm_write_bte_o,
        wbm_write_we_o      => wbm_write_we_o,
        wbm_write_adr_o     => wbm_write_adr_o,
        wbm_write_sel_o     => wbm_write_sel_o,
        wbm_write_ack_i     => wbm_write_ack_i,
        wbm_write_err_i     => wbm_write_err_i,
        wbm_write_dat_o     => wbm_write_dat_o,

        wbm_read_cyc_o      => wbm_read_cyc_o,
        wbm_read_stb_o      => wbm_read_stb_o,
        wbm_read_cti_o      => wbm_read_cti_o,
        wbm_read_bte_o      => wbm_read_bte_o,
        wbm_read_we_o       => wbm_read_we_o,
        wbm_read_adr_o      => wbm_read_adr_o,
        wbm_read_sel_o      => wbm_read_sel_o,
        wbm_read_ack_i      => wbm_read_ack_i,
        wbm_read_err_i      => wbm_read_err_i,
        wbm_read_dat_i      => wbm_read_dat_i,

        wbs_cyc_i           => wbs_cyc_i,
        wbs_stb_i           => wbs_stb_i,
        wbs_cti_i           => wbs_cti_i,
        wbs_bte_i           => wbs_bte_i,
        wbs_we_i            => wbs_we_i,
        wbs_adr_i           => wbs_adr_i,
        wbs_sel_i           => wbs_sel_i,
        wbs_ack_o           => wbs_ack_o,
        wbs_err_o           => wbs_err_o,
        wbs_dat_i           => wbs_dat_i,
        wbs_dat_o           => wbs_dat_o
    );

...

However, when I run synthesis, I get the following synthesis errors:

 

[Synth 8-493] no such design unit 'orsoc_gfx_top' ["<repository path>/pcores/orsoc_gpu_v1_00_a/hdl/vhdl/orsoc_gpu.vhd":208]
[Synth 8-285] failed synthesizing module 'orsoc_gpu' ["<repository path>/pcores/orsoc_gpu_v1_00_a/hdl/vhdl/orsoc_gpu.vhd":202]
[Synth 8-285] failed synthesizing module 'system_orsoc_gpu_0_wrapper' ["<vivado project path>/project_1.srcs/sources_1/edk/system/hdl/system_orsoc_gpu_0_wrapper.vhd":52]
[Synth 8-285] failed synthesizing module 'system' ["<vivado project path>/project_1.srcs/sources_1/edk/system/hdl/system.vhd":46]
[Synth 8-285] failed synthesizing module 'system_stub' ["<vivado project path>/project_1.srcs/sources_1/imports/system/system_stub.vhd":46]

So, for some reason Vivado finds the pcore top-level orsoc_gpu.vhd, but does not recognize the rest of the files in the pcore.  If I build the project directly from XPS, the files are recognized as expected.  What might I have to do to get Vivado to recognize the rest of the files, preferably so I can still use the library notation in the HDL?


 

0 Kudos
Adventurer
Adventurer
11,432 Views
Registered: ‎10-11-2011

Re: EDK pcore HDL files not being found by Vivado

Jump to solution

It looks like my problem was due to the Vivado synthesizer not allowing direct instantiation of a Verilog component in VHDL.  I added a component declaration for gfx_top.v in orsoc_gpu.vhd and I didn't get the synthesis error in my original post.

 

However, now it seems like Vivado isn't recognizing the different user_logic files between the various pcores, and is trying to use one user_logic for all instances (so for example, the Vivado synthesizer is trying to use Pcore A's user_logic when user_logic is instantiated in Pcore B, even though they both have their own user_logic file).  I'm guessing this is just due to the way Vivado parses sources, and is more a problem of my project structure than the tool itself, so I'll try adding the files manually with TCL.

0 Kudos
Scholar brimdavis
Scholar
11,399 Views
Registered: ‎04-26-2012

Re: EDK pcore HDL files not being found by Vivado

Jump to solution

"the Vivado synthesizer is trying to use Pcore A's user_logic when user_logic is instantiated in Pcore B, even though they both have their own user_logic file"

 

XPS depends heavily upon libraries, with a library for every pcore; this sounds like the library information has not survived the import to Vivado.

 

Are you using a supported flow to migrate your existing pcore to Vivado, or are you doing this manually somehow?

 

My understanding ( note that I have not actually done this ) is that to use an XPS pcore in Vivado, you need to first run the existing XPS pcore through the Vivado "Package IP" process, see page 64 of  UG911 (v2013.2)

 

As a workaround, I believe you can also generate an NGC file using the ISE XPS, then import the .NGC into Vivado.

 

If you a trying to import an entire XPS project, not just a pcore, I believe there is a longer semi-automated conversion process described in UG911.

 

-Brian

0 Kudos
Scholar markcurry
Scholar
11,389 Views
Registered: ‎09-16-2009

Re: EDK pcore HDL files not being found by Vivado

Jump to solution

For all these (overcomplicated!) reponses, and user migration guides, etc., it all boils down to a list of verilog and/or VHDL RTL files going into some tool.  A PAO is just a list of sources files.  Sounds like Vivado has some issues with calling verilog modules from VHDL, but the workaround doesn't look too bad.

 

Now VHDL offers these "libraries", which I think it's just too much rope for Xilinx, and they've hung themselves with it.  I'm a verilog user, so don't really know the best practices VHDL wise - but everytime I integrate VHDL IP which overuses libraries in VHDL, it's going to be painful.  I think their use offers little benefit and a bunch of pain.  You get all sorts of compile order dependency problems, or other issues because of compiling of things into improper libraries.

 

Regards,

 

Mark

 

 

0 Kudos
Adventurer
Adventurer
11,299 Views
Registered: ‎10-11-2011

Re: EDK pcore HDL files not being found by Vivado

Jump to solution

I know this is a delayed response, but just to clarify, I'm not actually using the IP directly in Vivado.  What I'm doing is creating an embedded source (i.e. an XPS project), and within that XPS project, I'm adding a user peripheral repository containing my custom pcores and instantiating them in the XPS project.  So my Vivado project only contains the embedded source.  I figured the Vivado synthesizer would just synthesize the embedded design the same way XPS does, but that doesn't seem to be the case.

 

It could be this isn't really an intended use for Vivado, which is why it's having trouble handling the custom IP.  The embedded source synthesizes correctly when opened directly in XPS, so I'll probably just stick with XPS for this one.

0 Kudos
Highlighted
Scholar brimdavis
Scholar
11,288 Views
Registered: ‎04-26-2012

Re: EDK pcore HDL files not being found by Vivado

Jump to solution

Mark wrote: "Now VHDL offers these "libraries", which I think it's just too much rope for Xilinx, and they've hung themselves with it. "

 

I would take care to distinguish the various layers of XPS cruft from the library capabilities of VHDL itself.

 

Libraries and packages in VHDL are very powerful tools, particularly for large designs.

 

I would guess that Xilinx used them in the XPS flow in part to provide independent namespaces for each IP core.

 

-Brian

0 Kudos
Scholar brimdavis
Scholar
6,880 Views
Registered: ‎04-26-2012

Re: EDK pcore HDL files not being found by Vivado

Jump to solution

@David

> ...synthesizes correctly when opened directly in XPS,so I'll probably just stick with XPS

 

OK, but if you ever look into this again, I have some more questions below.

 

Bearing in mind that I haven't actually migrated any XPS designs to Vivado, so I could just be barking up the wrong tree :)


> What I'm doing is creating an embedded source (i.e. an XPS project),

> and within that XPS project, I'm adding a user peripheral repository

 

OK


> So my Vivado project only contains the embedded source. 

 

OK, but could you explain exactly ***how*** you went about adding this embedded source to the Vivado project ?

 

i.e., are you using one of the following methods:

 

A) manually adding the HDL source files somehow

 

B) re-creating the XPS project in Vivado as described in  UG911 (v2013.2) chapter 5

 

C) Although not mentioned in that Migration Guide,  I also found the following:

AR# 50682 2012.x Vivado - How can I add an Embedded system (XPS) into Vivado?

 

Are you generating an HDL wrapper from the XMP as described therein?


 

If you are importing the project as described in "C", and it's still failing, I would recommend that you open a Webcase  and ask Xilinx to fix this.

 


 

Although specifically related to an XPS pcore import (rather than an XPS project import), the information in the following document about recreating the XPS pcore library structure for Vivado IPI might be of use:

http://www.xilinx.com/Attachment/AR56358.pdf

 

-Brian

0 Kudos
Adventurer
Adventurer
6,867 Views
Registered: ‎10-11-2011

Re: EDK pcore HDL files not being found by Vivado

Jump to solution

@brimdavis:

 

My steps were (roughly):

 

1.  Open Vivado and follow the new project wizard

2.  When the project opens, right click "Design Sources" and select "Add Sources"

3.  Click the "Add or Create Embedded Sources" button, click Next

4.  Click "Create Sub-Design", entered a name, clicked Finish

5.  XPS opened, followed the BSB to get a partial system in place

6.  Added my peripheral repositories from XPS and instantiated the cores from them into the design

7.  Closed XPS

8.  Created constraints, created the top HDL wrapper, tried to synthesize

 

I've followed this process successfully in Vivado before, though not with custom IP from repositories (step 6).  It's not a problem with the embedded source itself, it's an issue with my use of custom IP from peripheral repositories in the embedded source, and the way the Vivado synthesizer recognizes these repositories and IP.  I'm not trying, nor do I want, to import the IP into Vivado and instantiate them from there, because the only way I know to use them with the embedded source is to drag the signals from the embedded source that connect to them (AXI, etc) to external ports in XPS, generate the top HDL from the embedded source in Vivado, instantiate the IP cores in the HDL, and connect the AXI and other signals manually in the HDL, which is the kind of thing XPS helps system designers avoid.

0 Kudos
Historian
Historian
6,859 Views
Registered: ‎02-25-2008

Re: EDK pcore HDL files not being found by Vivado

Jump to solution

@brimdavis wrote:

 

Libraries and packages in VHDL are very powerful tools, particularly for large designs.

 

I would guess that Xilinx used them in the XPS flow in part to provide independent namespaces for each IP core.

 


Yes, indeed, that's what I understand. It also ensures that different versions of a core can co-exist in a design (if you're into that sort of madness).

----------------------------Yes, I do this for a living.
0 Kudos
Scholar markcurry
Scholar
6,852 Views
Registered: ‎09-16-2009

Re: EDK pcore HDL files not being found by Vivado

Jump to solution

To keep my analogy going... A rope is a powerfool tool too - and you can still hang yourself with it.

 

As I said, I'm a verilog user, not a VHDL user, so don't know what the best practices are here.  But it looks to me that the different library feature was seen from Xilinx perspective of  "Oh, this is a neat feature of the language.  Let's use it"  Without thinking through the use model, and what they were trying to solve.

 

Let's see - from Xilinx install top pcores directory:

 % find . -name counter.vhd | wc -l

11

 

So, 11 copies of counter.vhd.  Are they all the same?  Are they all different?  Is any one of these extremes correct?  I just picked counter.vhd randomly, I know I've seen arbiters/muxs/address decodes and other logic cut/pasted all over the place in the Xilinx tree. 

 

It's a poor reuse strategy.  And the crap we have to juggle with when compiling things to the proper "library", and in the proper order (pao junk), is too much to pay for too little benefit. 

 

Xilinx should compile everything of theirs into library "Xilinx".  Apply true reuse and version control there, and make things easier for all of us.

 

My 2 cents...

 

Mark

 

0 Kudos
Scholar brimdavis
Scholar
6,840 Views
Registered: ‎04-26-2012

Re: EDK pcore HDL files not being found by Vivado

Jump to solution

@David "My steps were (roughly): <snip>"

 

Thanks for the detailed rundown, I didn't know Vivado supported an XPS flow for an existing IP repository.

 

I had (mistakenly) thought you were trying to take a working ISE XPS project and migrate it to Vivado.

 

I would look closely at the repository sources within your Vivado flow and see if the pcore library information has been lost somewhere along the way.

 


"I'm not trying, nor do I want, to import the IP into Vivado and instantiate them from there"

 

My understanding is that IPI is the wave of the future, and XPS has been deprecated.

 


 

"the only way I know to use them with the embedded source <snip detail> <is to> connect the AXI and other signals manually in the HDL, which is the kind of thing XPS helps system designers avoid."

 

I believe if you migrate the pcores themselves, using the IP packager flow, you can then perform the equivalent of the XPS .mhs connect-the-bus-and-configure-the-IP magic with a Vivado IPI TCL script  (as opposed to clicking on stuff in the IPI GUI, ohhh the horror...)

 

I think short term, continuing to build within XPS will be much less painful than the previous paragraph :)

 

But I think all XPS users will have to sort this out at some point in the not-so-far-off future.

 

-Brian

 

0 Kudos
Historian
Historian
6,828 Views
Registered: ‎02-25-2008

Re: EDK pcore HDL files not being found by Vivado

Jump to solution

@markcurry wrote:

To keep my analogy going... A rope is a powerfool tool too - and you can still hang yourself with it.


 funny, I say that about Verilog in general. :)


As I said, I'm a verilog user, not a VHDL user, so don't know what the best practices are here.  But it looks to me that the different library feature was seen from Xilinx perspective of  "Oh, this is a neat feature of the language. Let's use it" without thinking through the use model, and what they were trying to solve.


 Using libraries in the manner of the EDK is a best practice.

 

The problem it solves is where you have multiple entities with the same name but different implementations. Say, for example, you want to use some standard UART. Say, also, that you have a special-purpose UART you need to use.

 

Finally, assume that both the standard UART and your special-purpose thing are both called UART, and you can't change the names.

 

The way to ensure that the tools aren't completely baffled is to analyze each entity into separate libraries. Then the instantiation clarifies what gets used where:

 

    u_std_uart : entity stduart.uart is

        port map (....);

 

    u_special_uart : entity specialuart.uart is

        port map (...);

 

You can think of all sorts of places where this helps ...


Let's see - from Xilinx install top pcores directory:

 % find . -name counter.vhd | wc -l

11

 

So, 11 copies of counter.vhd.  Are they all the same?  Are they all different?  Is any one of these extremes correct?  I just picked counter.vhd randomly, I know I've seen arbiters/muxs/address decodes and other logic cut/pasted all over the place in the Xilinx tree. 


That shows the number files called "counter.vhd" in the Xilinx install tree. It doesn't tell the context for them (simulation library source, etc etc).

 

Now consider the case where you actually need to differentiate between entities called counter. See above. 


It's a poor reuse strategy.  And the crap we have to juggle with when compiling things to the proper "library", and in the proper order (pao junk), is too much to pay for too little benefit. 

 

Xilinx should compile everything of theirs into library "Xilinx".  Apply true reuse and version control there, and make things easier for all of us.


And then you have the namespace conflicts that the proper use of libraries is intended to mitigate.

----------------------------Yes, I do this for a living.
0 Kudos
Scholar markcurry
Scholar
6,825 Views
Registered: ‎09-16-2009

Re: EDK pcore HDL files not being found by Vivado

Jump to solution

 

The overhead's just not worth the hassle just for a little namespace conflict avoidance.  IMHO.  Rename one of the uarts and be done with it.  You have two modules named the same thing, and you want to use some tool trickery to  disambiguate them? That's asking for trouble.  But then I'm looking at this through verilog colored glasses...  :)

 

It is simpler in verilog in that only modules can have namespace collisions - they're really the only thing in global namespace.  Functions definitions and instances are all locally scoped in verilog.  VHDL needs globally scoped functions (well not global - library scoped).  It is a more powerful tool in VHDL.

 


@bassman59 wrote:


Let's see - from Xilinx install top pcores directory:

 % find . -name counter.vhd | wc -l

11

 

So, 11 copies of counter.vhd.  Are they all the same?  Are they all different?  Is any one of these extremes correct?  I just picked counter.vhd randomly, I know I've seen arbiters/muxs/address decodes and other logic cut/pasted all over the place in the Xilinx tree. 


That shows the number files called "counter.vhd" in the Xilinx install tree. It doesn't tell the context for them (simulation library source, etc etc).

 




Most of the duplicate files ARE the same file.  Just cut/pasted into everyone's own sandbox (library).  So now you find a bug in that counter.  How many places do you have to go to fix it - one or 11?  Poor reuse strategy.  That's the problem with too many sandboxes.  Everyone ends up managing there own copy of the same thing.  Instead do it once, make it shared, and all reference the same thing.

 

I can see one sandbox for Xilinx - a library named "Xilinx".  They should be able managing namespace collision internally.

 

It's just soo painful managing the compile order dependancies and feeding some poorly defined library name per file, to all the tools.  Synopsys at least as a "feed me ALL the RTL, I'll figure out the proper order dependency" command.  You still need to puzzle out feeding everything into the correct library.

 

Sidetracking the OP's thread here.  (And I'm trying not to pull this into a language war... Really...).

 

--Mark

 

0 Kudos