cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
helmutforren
Scholar
Scholar
2,056 Views
Registered: ‎06-23-2014

How can I track down failing set_property PACKAGE_PIN?

Jump to solution

I'm using Vivado 2018.1. 

 

[The forum reader might jump forward to my "[EDIT BEFORE POST:" below and see the result of write_xdc...]

 

On a significantly different project, these two set_property PACKAGE_PIN constraints work, such that I can see PCIE_REFCLK_* on the desired H5 & H6 pins (MGTREFCLK0{P|N}_115) when I Report IO.  However, on this project, PCIE_REFCLK_* sticks to K5 & K6 (MGTREFCLK1{P|N}_115) and Vivado seems to ignore these two constraints.  

 

set_property PACKAGE_PIN H6 [get_ports PCIE_REFCLK_P]
set_property PACKAGE_PIN H5 [get_ports PCIE_REFCLK_N]

I've TCL'd "report_compile_order -constraints" and the xdc containing this constraints is listed.  I've programmatically searched the content of all xdc's in the project and this xdc is the only one mentioning "PCIE_REFCLK_".  I've programmatically searched the content of all files of any kind, and there's no conflicting mention.  I've looked through the warnings and there's no mention (and my all files search should have found any mention in warnings as well).  I've programmatically searched the content of all files for "MGTREFCLK" and all I get is the IO Report I've already seen, with the wrong pin usage.  (Note that one of these many searches simultaneously found my xdc as well as the IO Report with wrong assignment, so this should have eliminated a spelling snafu.  The "report_compile_order -constraints" should have eliminated an inclusion snafu.  Reopening the xdc from the gui source window should have eliminated a xdc file location snafu.)

 

 

Note that K5 & K6 (MGTREFCLK1{P|N}_115) are the default pins and so I'm getting default pin placement.  I need to override them to H5 & H6 (MGTREFCLK0{P|N}_115).  This override worked in the significantly different project, derived from PCIe v3.3 sample project.  It's not working in my long-ago derived from Xillybus example project, @billauer .

 

So why might this be happening?

 

Are there specific detail logs I can look at that trace the application of these constraints, where I might be able to find how or why they aren't being respected?  Or a way to increase how verbose a log or report is in order to see more under the hood?

 

[EDIT BEFORE POST:

 

I found https://www.xilinx.com/support/answers/59317.html .  I ran "write_xdc junky".  In junky.xdc, I find reference to my xdc file that contains these two constraints.  The reference includes both comments and constraints from this xdc.  However, the two constraints in question simply are not there.

 

The xdc snippet below is from my file and "goes into" Vivado:

#set_property PACKAGE_PIN J8 [get_ports PCIE_PERST_B_LS]
#set_property IOSTANDARD LVCMOS33 [get_ports PCIE_PERST_B_LS]
set_property -dict "PACKAGE_PIN J8 IOSTANDARD LVCMOS33 PULLUP true" [get_ports PCIE_PERST_B_LS]

set_property LOC IBUFDS_GTE2_X0Y0 [get_cells refclk_ibuf]
set_property PACKAGE_PIN H6 [get_ports PCIE_REFCLK_P]
set_property PACKAGE_PIN H5 [get_ports PCIE_REFCLK_N]
#not allowed for GT terminals#set_property IOSTANDARD  LVDS      [get_ports PCIE_REFCLK_*]
#port doesn't have this property#set_property DIFF_TERM   FALSE     [get_ports PCIE_REFCLK_*]
#???does this break H5,H6 pin positioning???#create_clock -period 10.000 -name PCIE_REFCLK -waveform {0.000 2.500} [get_ports PCIE_REFCLK_P]

# Tell Vivado that the input and output of the stream_clk_gen clock
# synthesizer should be treated as unrelated

But the snippet below is what "comes out" when I look in junky.xdc:

 

 

#set_property PACKAGE_PIN J8 [get_ports PCIE_PERST_B_LS]
#set_property IOSTANDARD LVCMOS33 [get_ports PCIE_PERST_B_LS]
set_property PACKAGE_PIN J8 [get_ports PCIE_PERST_B_LS]
set_property IOSTANDARD LVCMOS33 [get_ports PCIE_PERST_B_LS]
set_property PULLUP true [get_ports PCIE_PERST_B_LS]

#not allowed for GT terminals#set_property IOSTANDARD  LVDS      [get_ports PCIE_REFCLK_*]
#port doesn't have this property#set_property DIFF_TERM   FALSE     [get_ports PCIE_REFCLK_*]
#???does this break H5,H6 pin positioning???#create_clock -period 10.000 -name PCIE_REFCLK -waveform {0.000 2.500} [get_ports PCIE_REFCLK_P]

# Tell Vivado that the input and output of the stream_clk_gen clock
# synthesizer should be treated as unrelated

So notice how FOUR [EDIT: ? there may be an out of sequence in my cut/paste after many tries ?] of my constraints in the middle are simply missing.  I'm currently trying commenting out the first two constraints to see if one of them is foiling parsing...

 

 

0 Kudos
1 Solution

Accepted Solutions
helmutforren
Scholar
Scholar
2,015 Views
Registered: ‎06-23-2014

SOLVED.  I found it this morning, after getting some good sleep. 

 

As @billauer knows and perhaps others, I went back to my project and reconciled all of my xdc's against both a different old project of mine as well as the original Xillybus example.  In doing so, I copied over a number of constraints, just to make sure I wasn't missing any others as I was before.  One of those from the Xillybus example was:

set_property LOC IBUFDS_GTE2_X0Y1 [get_cells -match_style ucf */pcieclk_ibuf]

It turns out that this was a way to force the PCIe clock onto K5,K6 of the 160T.

 

How did I find it?  I did "write_xdc junky" one more time and searched it for my PCIE_REFCLK_{P|N}.  I **swear** I did this before and found only my own.  But there they were, in the wrong place (more later).  I must have gone around in circles so many times that I simply didn't look when they were there.  I guess this is why, sometimes, I say I'm going to set the problem down and sleep on it.

 

Anyway, I found the following three constraints "coming out" as seen on junky.xdc:

set_property LOC IBUFDS_GTE2_X0Y1 [get_cells -match_style ucf */pcieclk_ibuf]
set_property PACKAGE_PIN K6 [get_ports PCIE_REFCLK_P]
set_property PACKAGE_PIN K5 [get_ports PCIE_REFCLK_N]

So they were indeed forcing my PCIe clock to K5,K6 rather than my desired H5,H6.  The funny part is that my reconciled constraints that are "going in" to this process are just:

set_property LOC IBUFDS_GTE2_X0Y1 [get_cells -match_style ucf */pcieclk_ibuf]

All the xdc files are too long to post in their entirety.  But, in essence, my two set_property statements specifying H5,H6 got *removed* higher up, and then lower down they got *added* back, but for K5,K6.  The reason is the LOC of the IBUFDS_GTE2 above.  I have a hard time finding the doc for where these things are, but obviously X0Y1 corresponds to where K5,K6 are, and so this single set_property being lower down had the effect of overriding my earlier set_property to H5, H6.

 

I simply commented out this conflicting set_property, and now I get the PCIe clock on the "CLK0" pins that the board designer used (MGTREFCLK0{P|N}_115) , rather than the recommended "CLK1" pins (MGTREFCLK1{P|N}_115).

 

Perhaps now *all* the ducks are in a row.  I'll have that same board designer try my bitstream that just built, and we'll see if I both get a positive lspci result as well as, after loading the Xillybus driver on linux, I see my devices.  (I've gotten all this working on the KC705, but not yet on the custom board due to FPGA change from 325T to 160T, using non-recommended lanes 0-3 instead of 4-7 for a 4x, and using non-recommended CLK0 instead of CLK1.  Or even more, due to my slowness on getting all the constraints right!)

 

[EDIT: By the way, Eli, why the thing you found doesn't seem to apply, I don't know.  Thanks very much for trying.  You saved me on the previous post, just not on this one.  Note that my strictly Xilinx originated PCIe example got working last Thursday morning, including using CLK0.  So I knew already that this was possible.  That worked for lspci only, of course.  No drivers loaded yet to see local linux /dev/files.]

 

 

 

 

View solution in original post

0 Kudos
4 Replies
helmutforren
Scholar
Scholar
2,047 Views
Registered: ‎06-23-2014

I've trimmed my xdc file, and now what "goes in" from my xdc includes this snippet:

 

set_property PACKAGE_PIN J8 [get_ports PCIE_PERST_B_LS]
set_property IOSTANDARD LVCMOS33 [get_ports PCIE_PERST_B_LS]
#???does this break H5,H6 pin positioning???#set_property -dict "PACKAGE_PIN J8 IOSTANDARD LVCMOS33 PULLUP true" [get_ports PCIE_PERST_B_LS]

#???does this break H5,H6 pin positioning???#set_property LOC IBUFDS_GTE2_X0Y0 [get_cells refclk_ibuf]
set_property PACKAGE_PIN H6 [get_ports PCIE_REFCLK_P]
set_property PACKAGE_PIN H5 [get_ports PCIE_REFCLK_N]
#not allowed for GT terminals#set_property IOSTANDARD  LVDS      [get_ports PCIE_REFCLK_*]
#port doesn't have this property#set_property DIFF_TERM   FALSE     [get_ports PCIE_REFCLK_*]
create_clock -period 10.000 -name PCIE_REFCLK -waveform {0.000 2.500} [get_ports PCIE_REFCLK_P]

and what "comes out" via write_xdc includes this snippet:

 

set_property PACKAGE_PIN J8 [get_ports PCIE_PERST_B_LS]
set_property IOSTANDARD LVCMOS33 [get_ports PCIE_PERST_B_LS]
#???does this break H5,H6 pin positioning???#set_property -dict "PACKAGE_PIN J8 IOSTANDARD LVCMOS33 PULLUP true" [get_ports PCIE_PERST_B_LS]

#???does this break H5,H6 pin positioning???#set_property LOC IBUFDS_GTE2_X0Y0 [get_cells refclk_ibuf]
#not allowed for GT terminals#set_property IOSTANDARD  LVDS      [get_ports PCIE_REFCLK_*]
#port doesn't have this property#set_property DIFF_TERM   FALSE     [get_ports PCIE_REFCLK_*]
create_clock -period 10.000 -name PCIE_REFCLK -waveform {0.000 2.500} [get_ports PCIE_REFCLK_P]

As you can see, the second snippet differs only by missing the two constraints I'm interested in.

 

Say what?

 

 

0 Kudos
helmutforren
Scholar
Scholar
2,033 Views
Registered: ‎06-23-2014

So I moved a couple blocks around just in case, then I deleted and manually retyped the lines in case there was an unprintable char buried in there somehow.  Same problem.  This is absurd!

 

My file "going in" contains:

#???does this break H5,H6 pin positioning???#set_property LOC IBUFDS_GTE2_X0Y0 [get_cells refclk_ibuf]
set_property PACKAGE_PIN H5 [get_ports PCIE_REFCLK_N]
set_property PACKAGE_PIN H6 [get_ports PCIE_REFCLK_P]
#not allowed for GT terminals#set_property IOSTANDARD  LVDS      [get_ports PCIE_REFCLK_*]
#port doesn't have this property#set_property DIFF_TERM   FALSE     [get_ports PCIE_REFCLK_*]
create_clock -period 10.000 -name PCIE_REFCLK -waveform {0.000 2.500} [get_ports PCIE_REFCLK_P]

but write_xdc shows "coming out" contains:

#???does this break H5,H6 pin positioning???#set_property LOC IBUFDS_GTE2_X0Y0 [get_cells refclk_ibuf]
#not allowed for GT terminals#set_property IOSTANDARD  LVDS      [get_ports PCIE_REFCLK_*]
#port doesn't have this property#set_property DIFF_TERM   FALSE     [get_ports PCIE_REFCLK_*]
create_clock -period 10.000 -name PCIE_REFCLK -waveform {0.000 2.500} [get_ports PCIE_REFCLK_P]
0 Kudos
billauer
Adventurer
Adventurer
2,001 Views
Registered: ‎06-10-2014

Hello,

 

It looks like you want to use a reference clock that is different from what Xilinx' PCIe block selects for you. The truth is that I've never encountered this situation, as most people just set up the core and wire the PCB's clock to whatever pin assignment is made by the tools.

 

I'm going to allow myself some possibly inaccurate speculations below, to get the point through without wasting time on pinning down the fine details.

 

I think the root of your problem is that the placement of the resources is hard-coded in the Verilog files that are generated for the PCIe block. There's only one PCIe block on your device, on X0Y0, which I presume only has one QPLL it can use for producing the 2.5 GHz / 5 GHz clock for the GTX transceivers.

 

Looking at the instantiation of this QPLL in pcie_k7_vivado_qpll_wrapper.v (your file name may vary slightly), it says:

 

    GTXE2_COMMON #
    (
       
        //---------- Simulation Attributes ------------------------------------- 
        .SIM_QPLLREFCLK_SEL             ( 3'b001),                              //
        .SIM_RESET_SPEEDUP              (PCIE_SIM_MODE),                        //
        .SIM_VERSION                    (PCIE_USE_MODE),                        // 
        
        //---------- Clock Attributes ------------------------------------------
        .QPLL_CFG                       (27'h06801C1),                          // QPLL for Gen3, Optimized for silicon, 
      //.QPLL_CLKOUT_CFG                ( 4'd0),                                //
        .QPLL_COARSE_FREQ_OVRD          ( 6'b010000),                           // 
        .QPLL_COARSE_FREQ_OVRD_EN       ( 1'd0),                                // 
        .QPLL_CP                        (10'h01F),                              // Optimized for Gen3 compliance (Gen1/Gen2 = 10'h1FF) 
        .QPLL_CP_MONITOR_EN             ( 1'd0),                                //
        .QPLL_DMONITOR_SEL              ( 1'd0),                                //
        .QPLL_FBDIV                     (QPLL_FBDIV),                           // 
        .QPLL_FBDIV_MONITOR_EN          ( 1'd0),                                //
        .QPLL_FBDIV_RATIO               ( 1'd1),                                // Optimized for silicon
      //.QPLL_INIT_CFG	                (24'h000006),                           // 
        .QPLL_LOCK_CFG                  (16'h21E8),                             // Optimized for silicon, IES = 16'h01D0, GES 16'h21D0
        .QPLL_LPF                       ( 4'hD),                                // Optimized for silicon, [1:0] = 2'b00 (13.3 KOhm), [1:0] = 2'b01 (57.0 KOhm)
        .QPLL_REFCLK_DIV	              (1),                                    // 
    
        //---------- MISC ------------------------------------------------------
        .BIAS_CFG                       (BIAS_CFG)                              // Optimized for silicon
      //.COMMON_CFG                     (32'd0)                                 //
    
    )
    gtxe2_common_i 
    (
           
        //---------- Clock -----------------------------------------------------
        .GTGREFCLK                      ( 1'd0),                                //
        .GTREFCLK0                      (QPLL_GTGREFCLK),                       //
        .GTREFCLK1                      ( 1'd0),                                //
        .GTNORTHREFCLK0                 ( 1'd0),                                //
        .GTNORTHREFCLK1                 ( 1'd0),                                //
        .GTSOUTHREFCLK0                 ( 1'd0),                                //
        .GTSOUTHREFCLK1                 ( 1'd0),                                //
        .QPLLLOCKDETCLK                 (QPLL_QPLLLOCKDETCLK),                  //
        .QPLLLOCKEN                     ( 1'd1),                                //
        .QPLLREFCLKSEL                  ( 3'd1),                                //
        .QPLLRSVD1                      (16'd0),                                //
        .QPLLRSVD2                      ( 5'b11111),                            //
                                                                               
        .QPLLOUTCLK                     (QPLL_QPLLOUTCLK),                      //
        .QPLLOUTREFCLK                  (QPLL_QPLLOUTREFCLK),                   //
        .QPLLLOCK                       (QPLL_QPLLLOCK),                        //
        .QPLLFBCLKLOST                  (),                                     //
        .QPLLREFCLKLOST                 (),                                     //
        .QPLLDMONITOR                   (),                                     //
        
        //---------- Reset -----------------------------------------------------
        .QPLLPD                         (QPLL_QPLLPD),                          // 
        .QPLLRESET                      (QPLL_QPLLRESET),                       //
        .QPLLOUTRESET                   ( 1'd0),                                //
        
        //---------- DRP -------------------------------------------------------
        .DRPCLK                         (QPLL_DRPCLK),                          //
        .DRPADDR                        (QPLL_DRPADDR),                         //
        .DRPEN                          (QPLL_DRPEN),                           //
        .DRPDI                          (QPLL_DRPDI),                           //
        .DRPWE                          (QPLL_DRPWE),                           //
                                                                               
        .DRPDO                          (QPLL_DRPDO),                           //
        .DRPRDY                         (QPLL_DRPRDY),                          //
                
        //---------- Band Gap --------------------------------------------------    
        .BGBYPASSB                      ( 1'd1),                                //
        .BGMONITORENB                   ( 1'd1),                                //
        .BGPDB                          ( 1'd1),                                //
        .BGRCALOVRD                     ( 5'd31),                               //
        
        //---------- MISC ------------------------------------------------------
        .PMARSVD                        ( 8'd0),                                //
        .RCALENB                        ( 1'd1),                                // Optimized for GES
                                                                               
        .REFCLKOUTMONITOR               ()                                      //
    
    );

As you can see, this is a very low-level instantiation, where there reference clock, QPLL_GTGREFCLK is inserted directly to one of the QPLL's inputs (GTREFCLK0). This forces a specific physical pin input. The pin placement constraint doesn't matter. Why the tools didn't whine about this conflict is unclear.

 

It looks like the way to fix that, if possible at all, is to get down to the GTX level of the PCIe and change the QPLL's input source. I don't think that just changing the feeding pin in the instantiation will be good enough.

 

Also note that PCIe GTXes sometimes also depend on CPLLs. I think. And that there's a mechanism for switching rates (5 -> 2.5 GHz), which you should verify that you haven't messed up, if you want to edit these sources.

 

Once again, I've never given much thought on this issue, so I might be completely wrong in all said above, and I might be right on spot, with all possibilities inbetween.

 

Regards,

   Eli

0 Kudos
helmutforren
Scholar
Scholar
2,016 Views
Registered: ‎06-23-2014

SOLVED.  I found it this morning, after getting some good sleep. 

 

As @billauer knows and perhaps others, I went back to my project and reconciled all of my xdc's against both a different old project of mine as well as the original Xillybus example.  In doing so, I copied over a number of constraints, just to make sure I wasn't missing any others as I was before.  One of those from the Xillybus example was:

set_property LOC IBUFDS_GTE2_X0Y1 [get_cells -match_style ucf */pcieclk_ibuf]

It turns out that this was a way to force the PCIe clock onto K5,K6 of the 160T.

 

How did I find it?  I did "write_xdc junky" one more time and searched it for my PCIE_REFCLK_{P|N}.  I **swear** I did this before and found only my own.  But there they were, in the wrong place (more later).  I must have gone around in circles so many times that I simply didn't look when they were there.  I guess this is why, sometimes, I say I'm going to set the problem down and sleep on it.

 

Anyway, I found the following three constraints "coming out" as seen on junky.xdc:

set_property LOC IBUFDS_GTE2_X0Y1 [get_cells -match_style ucf */pcieclk_ibuf]
set_property PACKAGE_PIN K6 [get_ports PCIE_REFCLK_P]
set_property PACKAGE_PIN K5 [get_ports PCIE_REFCLK_N]

So they were indeed forcing my PCIe clock to K5,K6 rather than my desired H5,H6.  The funny part is that my reconciled constraints that are "going in" to this process are just:

set_property LOC IBUFDS_GTE2_X0Y1 [get_cells -match_style ucf */pcieclk_ibuf]

All the xdc files are too long to post in their entirety.  But, in essence, my two set_property statements specifying H5,H6 got *removed* higher up, and then lower down they got *added* back, but for K5,K6.  The reason is the LOC of the IBUFDS_GTE2 above.  I have a hard time finding the doc for where these things are, but obviously X0Y1 corresponds to where K5,K6 are, and so this single set_property being lower down had the effect of overriding my earlier set_property to H5, H6.

 

I simply commented out this conflicting set_property, and now I get the PCIe clock on the "CLK0" pins that the board designer used (MGTREFCLK0{P|N}_115) , rather than the recommended "CLK1" pins (MGTREFCLK1{P|N}_115).

 

Perhaps now *all* the ducks are in a row.  I'll have that same board designer try my bitstream that just built, and we'll see if I both get a positive lspci result as well as, after loading the Xillybus driver on linux, I see my devices.  (I've gotten all this working on the KC705, but not yet on the custom board due to FPGA change from 325T to 160T, using non-recommended lanes 0-3 instead of 4-7 for a 4x, and using non-recommended CLK0 instead of CLK1.  Or even more, due to my slowness on getting all the constraints right!)

 

[EDIT: By the way, Eli, why the thing you found doesn't seem to apply, I don't know.  Thanks very much for trying.  You saved me on the previous post, just not on this one.  Note that my strictly Xilinx originated PCIe example got working last Thursday morning, including using CLK0.  So I knew already that this was possible.  That worked for lspci only, of course.  No drivers loaded yet to see local linux /dev/files.]

 

 

 

 

View solution in original post

0 Kudos