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
2,059 Views
Registered: ‎05-09-2018

system Verilog pkg import

Jump to solution

I have a system verilog pkg file that I am importing into several files. I can get the code to compile in Modelsim so I believe all of the syntax is good.

However when the files are brought into Vivado (2018.3) I get a <name_pkg> is not declared error for the import statements.

ie.

In the the pkg file.

package my_name_pkg

... some declarations

endpackage

in the target file

import my_name_pkg::*;

looking at the compile order it doesn't seem to generate it correctly in that the pkg file is not in front of all modules that use it.

Also the error is reported only for the top level (Which should be compiled last) even though is included in submodules as well.

Just wondering if there is a problem with this feature in 2018.3?

 

 

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Historian
Historian
1,930 Views
Registered: ‎01-23-2009

Re: system Verilog pkg import

Jump to solution

add_files -norecurse <filename>.sv; set_property IS_GLOBAL_INCLUDE 1 [get_files <filename>]

This is not "normal".

The "GLOBAL_INCLUDE" flag is a project shortcut to make the contents of one file visible to all others - it is the equivalent of having

`include "<file_that_is_globally_included>"

at the top of every other file of the project. It has the secondary effect of ensuring that the files with this set are parsed before the ones that don't have it set. So, by setting it on every file, this basically nullifies the value of the property.

This property should only be set on the package file.

That being said, this property is sort "cheating" - in properly constructed code it shouldn't be necessary.

In order to ensure that every file that has the "import <package_name>::*", you must ensure that the package is parsed before the "import" and that it is in the same $unit space. The control of the $unit space differs somewhat from tool to tool, so the "safest" thing to do is the following:

In each file that has the import, you should do

`include my_name_package.sv
import my_name_package::*
module ..
...
endmodule

However, this may result in the package being read in multiple times, so one protects it with a `ifdef. In the package file do:

`ifndef MY_NAME_PACKAGE_READ
  `define MY_NAME_PACKAGE_REG
   package my_name_package
   ...
   endpackage
`endif

With this done, the package will work regardless of the compile order (and without the need for the GLOBAL_INCLUDE property) and with pretty much any tool. (However, you should still turn off the "GLOBAL_INCLUDE" property on all files).

Avrum

12 Replies
Scholar markcurry
Scholar
2,025 Views
Registered: ‎09-16-2009

Re: system Verilog pkg import

Jump to solution

SystemVerilog packages, (and imports thereof) are a supported listed feature of Vivado.  I can confirm - we've used them extensively in most version of Vivado  - including the latest 2018.3 release without trouble.

Our flows are pure non-project TCL, so I can't comment much on using Vivado in project mode.  But it certainly sounds like just a simple compile ordering problem.  There's other forums post detailing trouble with compile ordering in Vivado Project mode.  I'd investigate that avenue first.

Regards,

Mark

0 Kudos
Xilinx Employee
Xilinx Employee
2,009 Views
Registered: ‎05-14-2008

Re: system Verilog pkg import

Jump to solution

You can try right clicking on the pkg file and selecting "Set Global include".

Let us know if this works.

-vivian

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
0 Kudos
Adventurer
Adventurer
1,986 Views
Registered: ‎05-09-2018

Re: system Verilog pkg import

Jump to solution

Thanks for the reply Mark,

I am in fact running this primarily in batch mode. (I use HDLMAKE to generate the build stuff which the launch scripts)

I was launching the project to try and debug it.

The scripts source add all the files (IS_GLOBAL_INCLUDE 1 is set for all of them).

The scripts also update the compile order.

Everything compiles into a single library in Vivado.

 

 

 

0 Kudos
Adventurer
Adventurer
1,984 Views
Registered: ‎05-09-2018

Re: system Verilog pkg import

Jump to solution

Thanks Vivian.

 

The files are all listed in the Global Includes list. When I right click them both options for global include (set and clear) are greyed out.

 

Steve

0 Kudos
Scholar markcurry
Scholar
1,981 Views
Registered: ‎09-16-2009

Re: system Verilog pkg import

Jump to solution

Not sure about the IS_GLOBAL_INCLUDE, nor the "update compile order".  Those both sound like project mode scripting to me - not non-project mode tcl scripting

For pure non-project mode tcl, all you need to do is make sure you script does a "read_verilog" on the systemverilog package BEFORE it does a "read_verilog" on the module that requires the package.  That's it.

I've heard of HDLMAKE in the past, and know I glanced at it.  But never used it.  Can you post a (trimmed) version of the scripting files it creates?

Regards,

Mark

 

0 Kudos
Adventurer
Adventurer
1,965 Views
Registered: ‎05-09-2018

Re: system Verilog pkg import

Jump to solution

Hi Mark.

This is the Synthesize script.

open_project fae_test_chip2z.xpr
set_property -name {steps.synth_design.args.more options} -value {-verbose} -objects [get_runs synth_1]
set_property steps.synth_design.args.retiming 1 [get_runs synth_1]
set_property steps.synth_design.args.assert 1 [get_runs synth_1]
reset_run synth_1
launch_runs synth_1
wait_on_run synth_1
set result [get_property STATUS [get_runs synth_1]]
set keyword [lindex [split $result ] end]
if { $keyword != "Complete!" } {
exit 1
}
exit

 

The first thing it does is open a project so I guess you call this a tcl project flow.

There is another script that generates the project. So it does kind of look like a bug in the project flow.

 

Thanks,

Steve

0 Kudos
Scholar markcurry
Scholar
1,959 Views
Registered: ‎09-16-2009

Re: system Verilog pkg import

Jump to solution

Yes, that's Vivado project mode scripting.  Not non-project TCL.

I can't offer much help here - as I said, if you're using non-project mode tcl, it's as easy as just reading in the package before the module that uses it.

You'll need to pursue the help that viviany is offering.  

(Or better yet convert over to straight non-project mode TCL it's much more straightforward..)

Regards,

Mark

0 Kudos
Historian
Historian
1,942 Views
Registered: ‎01-23-2009

Re: system Verilog pkg import

Jump to solution

There is another script that generates the project. So it does kind of look like a bug in the project flow.

The compile order and the "Global Include" property are all contained in the "project". So when you do the "open_project fae_test_chip2z.xpr", the tool is reading in all these "project related" properties from the .xpr file.

From what you are describing, the generation of this project is not done correctly. You say that "The files are all listed in the Global Includes list" - I don't know what this means, and it doesn't sound correct. Why don't you open the .xpr file (using "open_project fae_test_chip2z.xpr") in the GUI, and take a screen capture of the "Sources" window as well as the "Properties" of one of your SystemVerilog and the package file.

With those, we may be able to figure out what is being done incorrectly in the project.

Alternatively, if the .xpr file is also being created by a Tcl script, you can post that - particularly the section around the "add_files" or "read_verilog" commands...

Avrum

0 Kudos
Adventurer
Adventurer
1,937 Views
Registered: ‎05-09-2018

Re: system Verilog pkg import

Jump to solution

OK The project create script looks like this.

create_project fae_test_chip2z ./

set_property part xc7Z020clg400-1 [current_project]

set_property target_language verilog [current_project]

set_property top fae_test_chip2z [get_property srcset [current_run]]

source files.tcl

update_compile_order -fileset sources_1

update_compile_order -fileset sim_1

exit

---- source_files.tcl is just a bunch of these

add_files -norecurse <filename>.sv; set_property IS_GLOBAL_INCLUDE 1 [get_files <filename>]

The package file is first in the list.

0 Kudos
Highlighted
Historian
Historian
1,931 Views
Registered: ‎01-23-2009

Re: system Verilog pkg import

Jump to solution

add_files -norecurse <filename>.sv; set_property IS_GLOBAL_INCLUDE 1 [get_files <filename>]

This is not "normal".

The "GLOBAL_INCLUDE" flag is a project shortcut to make the contents of one file visible to all others - it is the equivalent of having

`include "<file_that_is_globally_included>"

at the top of every other file of the project. It has the secondary effect of ensuring that the files with this set are parsed before the ones that don't have it set. So, by setting it on every file, this basically nullifies the value of the property.

This property should only be set on the package file.

That being said, this property is sort "cheating" - in properly constructed code it shouldn't be necessary.

In order to ensure that every file that has the "import <package_name>::*", you must ensure that the package is parsed before the "import" and that it is in the same $unit space. The control of the $unit space differs somewhat from tool to tool, so the "safest" thing to do is the following:

In each file that has the import, you should do

`include my_name_package.sv
import my_name_package::*
module ..
...
endmodule

However, this may result in the package being read in multiple times, so one protects it with a `ifdef. In the package file do:

`ifndef MY_NAME_PACKAGE_READ
  `define MY_NAME_PACKAGE_REG
   package my_name_package
   ...
   endpackage
`endif

With this done, the package will work regardless of the compile order (and without the need for the GLOBAL_INCLUDE property) and with pretty much any tool. (However, you should still turn off the "GLOBAL_INCLUDE" property on all files).

Avrum

Adventurer
Adventurer
1,925 Views
Registered: ‎05-09-2018

Re: system Verilog pkg import

Jump to solution

Thanks everybody for the input.

I have been able to narrow it down. There seems to be two things that are a bit strange.

1) The compile order appears to be reversed. 

If I set the compile order to manual and move the file order around I can get it to compile, but only by putting it at the bottom of the list. (In the Gui). Note that report_compile_order also shows that the pkg file should be compiled last in this case. However it does in fact compile correctly now.

 

2) If then go back and ask Vivado to update (Automatic update and compile order) it mucks up the order again.

Steve

 

 

 

0 Kudos
Adventurer
Adventurer
1,916 Views
Registered: ‎05-09-2018

Re: system Verilog pkg import

Jump to solution

Thanks Avrum,

That is the issue. Still seems a little odd that forcing never order got it to compile with the attributes all there.

However removing them did restore expected behaviour.

 

Steve

0 Kudos