Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
1,064 Views

Qsys generates PCIe designs that do not compile.

Hi, 

 

I have recently updated Quartus installation from 11.1 to 11.1sp2 (Subscription Edition). I can compile previous Qsys designs with PCIe, but when create a new design, compilation stops during analysis & synthesis with the following error: 

 

Error (10162): Verilog HDL Object Declaration error at altera_pcie_hard_ip_reset_controller.v(261): can't declare implicit net "pipe_mode_int" because the current value of 'default_nettype is "none" 

 

The offending file looks the same in designs created in the past, which compile correctly. 

I cannot edit the file because it is overwritten when I start compiling the design. 

 

Is this error caused by some default settings for new projects? What can I change to make the design compile successfully? 

 

Thanks, 

Adrian
0 Kudos
3 Replies
Altera_Forum
Honored Contributor I
53 Views

Hi Adrian, 

 

You could try the design files/procedure I document here: 

 

http://www.alteraforum.com/forum/showthread.php?t=35678 

 

I've tested it with 11.0, 11.1sp1, and 11.1sp2. I do not get compilation errors. Just timing errors.  

 

Perhaps this will help determine your compilation error. Once you get that resolved, if you happen to know the solution to the timing errors I am seeing, please let me know!  

 

Cheers, 

Dave 

 

Note: I haven't updated the S4GXDK designs to include a qsys_system_11.1sp2.qsys file, just copy and rename the 11.1sp1 file. The C4GXSK design has been updated. You'll see what I am talking about when you run the automated synthesis script.
Altera_Forum
Honored Contributor I
53 Views

Apparently the `default_nettype setting is preserved across compilation of different verilog sources, and thus the result depends on the order of compilation. I prefer to enable `default_nettype none, to avoid hard to find bugs caused by typos in net names. 

It seems sufficient to place `default_nettype wire at the end of each file where I change this setting - now the design compiles. 

 

I would classify this as a serious bug in the compiler, though. 

 

As for your problems with timing, I am using only Arria II GX and I used to have some timing errors. For me it was sufficient to precisely specify all clocks, enable all optimizations for timing, and add these entries in the top-level .sdc file: 

 

derive_clock_uncertainty 

derive_pll_clocks 

 

In 11.1 it was also necessary to add this: 

set_clock_groups -asynchronous -group [get_clocks {alt_cal_edge_detect_clk}] 

 

In 11.1sp2, no clock is matched for that setting, so I suppose it is not needed anymore. 

I must run some further tests to check if the design works stably, though.
Altera_Forum
Honored Contributor I
53 Views

 

--- Quote Start ---  

Apparently the `default_nettype setting is preserved across compilation of different verilog sources, and thus the result depends on the order of compilation. I prefer to enable `default_nettype none, to avoid hard to find bugs caused by typos in net names. 

It seems sufficient to place `default_nettype wire at the end of each file where I change this setting - now the design compiles. 

 

--- Quote End ---  

 

 

This is one reason I like to script the final design. If there are compilation ordering issues, it helps to 'encode' those requirements in the script. 

 

 

--- Quote Start ---  

 

As for your problems with timing, I am using only Arria II GX and I used to have some timing errors. For me it was sufficient to precisely specify all clocks, enable all optimizations for timing, and add these entries in the top-level .sdc file: 

 

derive_clock_uncertainty 

derive_pll_clocks 

 

--- Quote End ---  

 

 

Yep, I have all this, and TimeQuest shows the design is fully constrained. 

 

 

--- Quote Start ---  

 

In 11.1 it was also necessary to add this: 

set_clock_groups -asynchronous -group [get_clocks {alt_cal_edge_detect_clk}] 

 

In 11.1sp2, no clock is matched for that setting, so I suppose it is not needed anymore. 

I must run some further tests to check if the design works stably, though. 

--- Quote End ---  

 

 

I get the timing errors under 11.1sp2 as well, so its probably not this. However, I'll take a look at the clocks and see. 

 

Thanks for the pointer. 

 

Cheers, 

Dave
Reply