cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
aaron-ueas
Visitor
Visitor
784 Views
Registered: ‎01-07-2020

IO standards for Aurora/GTH Tx/Rx pins?

Jump to solution

Hi All,

I'm using a few 64b/66b Auroras that I am locking into place using the IP generated LOC primitives such as this:

current_instance <design_name>../.../.../.../<..._gt_i>/inst; #set local scope to this IP

set_property LOC GTHE3_CHANNEL_X1Y2 [get_cells -hierarchical -filter {NAME =~ *gen_channel_container[24].*gen_gthe3_channel_inst[2].GTHE3_CHANNEL_PRIM_INST}]

However, the generated constraints contain a note saying that channel primitive serial data pin location such as the following example is not required:

set_property package_pin BA9 [get_ports gthrxn_in[2]]

My issue is that if I don't use set_property package_pin <PIN> then I am unable to generate a bitstream. Note that my top.vhd has the GTH Tx/Rx pins defined as IO ports and that I am feeding them to a module that contains the aurora. This module then maps the GTH Tx/Rx pins to rxp/txp pins on the Aurora 64/66 port map. How do I express the IO constraints so I can create a bitstream? As far as I know, Aurora IO standard is implicit...

0 Kudos
Reply
1 Solution

Accepted Solutions
roym
Moderator
Moderator
621 Views
Registered: ‎07-30-2007

>For reference my board is a XKCU115 and I am using quads 228, 224 and 225 but this is not required information, I just want to know how to map the ports if I haven't got external pins?

First of all RX and TX pins are external only.  They run at speeds up to and over 10Gbps which is too fast for any internal node.  I'm not sure I understand your statement.  If you don't map the aurora TX/RX to external pins it won't work. 

The whole point is that if you select the starting quad and starting lane in the wizard, it will define the pins for you.  You need to enter no constraints for the aurora TX and RX pins.  So in my example if you map the aurora TXP pin to "AuroraTXOut" at the top level.  Then that AuroraTXOut pin will be on the starting TX lane pin since there is only one lane and will be on V7.  Nothing needs to be done for that to happen because quad X1Y10 and starting lane X1Y41 has TXP at V7. 

GT are dedicated hard blocks I do not see a GT pin on a XKU115 AW10.  What is your package?

 




----------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution
Be sure to visit the Resources post periodically to keep up with the latest
https://forums.xilinx.com/t5/Serial-Transceivers/Serial-Transceiver-Forum-Guidelines-and-Useful-Resources/td-p/1173590
----------------------------------------------------------------------------


View solution in original post

7 Replies
roym
Moderator
Moderator
736 Views
Registered: ‎07-30-2007

In the aurora wizard you give the quad and starting lane that you will be using.  Nothing else needs to be constrained.  See PG074, page 91, on this.  If the GT is already constrained any movement you try to do will create a clash of constraints.  The IO standard never needs to be constrained for a GT.  If Vivado is calling errors on this then it sees the pins as normal IO and there are connection problems.  You need to make sure the IP you have is already targeted to the pins you have in mind.




----------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution
Be sure to visit the Resources post periodically to keep up with the latest
https://forums.xilinx.com/t5/Serial-Transceivers/Serial-Transceiver-Forum-Guidelines-and-Useful-Resources/td-p/1173590
----------------------------------------------------------------------------


aaron-ueas
Visitor
Visitor
711 Views
Registered: ‎01-07-2020

@roymHi Roym, thanks for your fast response!

I will give more detail to explain the issue I'm having. I had a reference design that worked, that had the Tx and Rx lanes manually constrained:

  set_property PACKAGE_PIN AW10 [get_ports TX15_P]
  set_property PACKAGE_PIN AY8 [get_ports RX15_P]
  set_property PACKAGE_PIN AY7 [get_ports RX15_N]
  set_property PACKAGE_PIN AW9 [get_ports TX15_N]
  set_property PACKAGE_PIN AY12 [get_ports TX14_P]
  set_property PACKAGE_PIN BA10 [get_ports RX14_P]
  set_property PACKAGE_PIN BA9 [get_ports RX14_N]
  set_property PACKAGE_PIN AY11 [get_ports TX14_N]
  set_property PACKAGE_PIN BA14 [get_ports TX13_P]
  set_property PACKAGE_PIN BB12 [get_ports RX13_P]
  set_property PACKAGE_PIN BB11 [get_ports RX13_N]
  set_property PACKAGE_PIN BA13 [get_ports TX13_N]
  set_property PACKAGE_PIN BC14 [get_ports TX12_P]
  set_property PACKAGE_PIN BC10 [get_ports RX12_P]
  set_property PACKAGE_PIN BC9 [get_ports RX12_N]
  set_property PACKAGE_PIN BC13 [get_ports TX12_N]

These pins are then input to a module/top file that is like this: 

entity example_top_module is
Port(
    TX15_P : in std_logic;
    TX15_N : in std_logic;
    TX14_P : in std_logic;
    TX14_N : in std_logic;
    TX13_P : in std_logic;
    TX13_N : in std_logic;
    TX12_P : in std_logic;
    TX12_N : in std_logic;
TX15_P : in std_logic;
-- rx ports also mapped --other_signals : in/out ... etc; ) end example_top_module;

 

And the top module instantiates/port-maps the Aurora 64b/66b like this:

 

txp(3) <= TX15_P;
txn(3) <= TX15_N;
txp(2) <= TX14_P;
txn(2) <= TX14_N;
-- and so on

example_aurora_inst : aurora_64b66b_x4_support PORT MAP( -- TX AXI4-S Interface s_axi_tx_tdata => tx_tdata_i, s_axi_tx_tvalid => tx_tvalid_i, s_axi_tx_tready => tx_tready_i, -- RX AXI4-S Interface m_axi_rx_tdata => rx_tdata_i, m_axi_rx_tvalid => rx_tvalid_i, -- GT Serial I/O rxp => rxp, -- <<<<< How do I map these without pin constraints for RX15_P etc.? rxn => rxn, -- <<<<< How do I map these without pin constraints for RX15_P etc.? txp => txp, -- <<<<< How do I map these without pin constraints for TX15_P etc.? txn => txn, -- <<<<< How do I map these without pin constraints for TX15_P etc.? --GT Reference Clock Interface gt_refclk1_p => CLK156_25MHZ4_P, gt_refclk1_n => CLK156_25MHZ4_N, -- Error Detection Interface hard_err => hard_err_i, soft_err => soft_err_i, -- Status channel_up => channel_up_i, lane_up => lane_up_i, -- System Interface user_clk_out => user_clk_i, sync_clk_out => sync_clk_i , reset_pb => reset_i , gt_rxcdrovrden_in => gt_rxcdrovrden_i , power_down => power_down_i , loopback => loopback_i , pma_init => gt_reset_i , gt_pll_lock => gt_pll_lock_i , ---------- AXI4-Lite input signals --------------- s_axi_awaddr => s_axi_awaddr_i , s_axi_awvalid => s_axi_awvalid_i , s_axi_awready => s_axi_awready_i , s_axi_awaddr_lane1 => s_axi_awaddr_lane1_i , s_axi_awvalid_lane1 => s_axi_awvalid_lane1_i , s_axi_awready_lane1 => s_axi_awready_lane1_i , s_axi_awaddr_lane2 => s_axi_awaddr_lane2_i , s_axi_awvalid_lane2 => s_axi_awvalid_lane2_i , s_axi_awready_lane2 => s_axi_awready_lane2_i , s_axi_awaddr_lane3 => s_axi_awaddr_lane3_i , s_axi_awvalid_lane3 => s_axi_awvalid_lane3_i , s_axi_awready_lane3 => s_axi_awready_lane3_i , s_axi_wdata => s_axi_wdata_i , s_axi_wstrb => s_axi_wstrb_i , s_axi_wvalid => s_axi_wvalid_i , s_axi_wready => s_axi_wready_i , s_axi_bvalid => s_axi_bvalid_i , s_axi_bresp => s_axi_bresp_i , s_axi_bready => s_axi_bready_i , s_axi_wdata_lane1 => s_axi_wdata_lane1_i , s_axi_wstrb_lane1 => s_axi_wstrb_lane1_i , s_axi_wvalid_lane1 => s_axi_wvalid_lane1_i , s_axi_wready_lane1 => s_axi_wready_lane1_i , s_axi_bvalid_lane1 => s_axi_bvalid_lane1_i , s_axi_bresp_lane1 => s_axi_bresp_lane1_i , s_axi_bready_lane1 => s_axi_bready_lane1_i , s_axi_wdata_lane2 => s_axi_wdata_lane2_i , s_axi_wstrb_lane2 => s_axi_wstrb_lane2_i , s_axi_wvalid_lane2 => s_axi_wvalid_lane2_i , s_axi_wready_lane2 => s_axi_wready_lane2_i , s_axi_bvalid_lane2 => s_axi_bvalid_lane2_i , s_axi_bresp_lane2 => s_axi_bresp_lane2_i , s_axi_bready_lane2 => s_axi_bready_lane2_i , s_axi_wdata_lane3 => s_axi_wdata_lane3_i , s_axi_wstrb_lane3 => s_axi_wstrb_lane3_i , s_axi_wvalid_lane3 => s_axi_wvalid_lane3_i , s_axi_wready_lane3 => s_axi_wready_lane3_i , s_axi_bvalid_lane3 => s_axi_bvalid_lane3_i , s_axi_bresp_lane3 => s_axi_bresp_lane3_i , s_axi_bready_lane3 => s_axi_bready_lane3_i , s_axi_araddr => s_axi_araddr_i , s_axi_arvalid => s_axi_arvalid_i , s_axi_arready => s_axi_arready_i , s_axi_araddr_lane1 => s_axi_araddr_lane1_i , s_axi_arvalid_lane1 => s_axi_arvalid_lane1_i , s_axi_arready_lane1 => s_axi_arready_lane1_i , s_axi_araddr_lane2 => s_axi_araddr_lane2_i , s_axi_arvalid_lane2 => s_axi_arvalid_lane2_i , s_axi_arready_lane2 => s_axi_arready_lane2_i , s_axi_araddr_lane3 => s_axi_araddr_lane3_i , s_axi_arvalid_lane3 => s_axi_arvalid_lane3_i , s_axi_arready_lane3 => s_axi_arready_lane3_i , s_axi_rdata => s_axi_rdata_i , s_axi_rvalid => s_axi_rvalid_i , s_axi_rresp => s_axi_rresp_i , s_axi_rready => s_axi_rready_i , s_axi_rdata_lane1 => s_axi_rdata_lane1_i , s_axi_rvalid_lane1 => s_axi_rvalid_lane1_i , s_axi_rresp_lane1 => s_axi_rresp_lane1_i , s_axi_rready_lane1 => s_axi_rready_lane1_i , s_axi_rdata_lane2 => s_axi_rdata_lane2_i , s_axi_rvalid_lane2 => s_axi_rvalid_lane2_i , s_axi_rresp_lane2 => s_axi_rresp_lane2_i , s_axi_rready_lane2 => s_axi_rready_lane2_i , s_axi_rdata_lane3 => s_axi_rdata_lane3_i , s_axi_rvalid_lane3 => s_axi_rvalid_lane3_i , s_axi_rresp_lane3 => s_axi_rresp_lane3_i , s_axi_rready_lane3 => s_axi_rready_lane3_i , init_clk => INIT_CLK_i , link_reset_out => link_reset_i , mmcm_not_locked_out => pll_not_locked_i , bufg_gt_clr_out => open, --bufg_gt_clr_out , sys_reset_out => system_reset_i , tx_out_clk => tx_out_clk_i);

So you can see that the GT Tx and Rx pins are directly mapped to the pins on the FPGA. This is what our working reference design does. I am confused about how we map txp and rxp ports on the Aurora design if we don't constrain external pins in the .xdc such as: TX15_P, TX15_N etc.

What do I connect to the rxp and txp ports on the Aurora instantiation if I am not supposed to constrain the GT pins?

0 Kudos
Reply
roym
Moderator
Moderator
699 Views
Registered: ‎07-30-2007

Refer to the diagram on PG074 page 85. The aurora wizard determines the lane from the quad and the starting lane inputs.  Since there is only one lane in your instantiation these 2 parameters give 4 specific pins.  RXP, RXN, TXP, TXN.  With the pulldowns you can choose any pins in the device.  If I choose quad X1Y41 for the VU9P FLGB2104 and starting channel x1Y41 and generate the example design.  I find a constraint file that contains the lines below.  This is a constraint file in the core so you won't work with it.  If you then give your own constrains you will have a clash of constraints.  So what was the starting channel and quad you used when you generated the wizard design? 

You can open the GT wizard and look at the physical view to get the XY parameters and pins for the given device.  You should be using the wizard flow or the tcl flow which also has the entry's for starting quad and starting channel (shown on page 91 I referenced before).  So if you used my example RXP is Y2 RXN is Y1  TXP is Y7 and TXN is Y6.  I could give you a little more detail if you would share your chip and package.

# UltraScale FPGAs Transceivers Wizard IP core-level XDC file
# ----------------------------------------------------------------------------------------------------------------------

# Commands for enabled transceiver GTYE4_CHANNEL_X1Y41
# ----------------------------------------------------------------------------------------------------------------------

# Channel primitive location constraint
set_property LOC GTYE4_CHANNEL_X1Y41 [get_cells -hierarchical -filter {NAME =~ *gen_channel_container[34].*gen_gtye4_channel_inst[0].GTYE4_CHANNEL_PRIM_INST}]

# Channel primitive serial data pin location constraints
# (Provided as comments for your reference. The channel primitive location constraint is sufficient.)
#set_property package_pin Y1 [get_ports gtyrxn_in[0]]
#set_property package_pin Y2 [get_ports gtyrxp_in[0]]
#set_property package_pin Y6 [get_ports gtytxn_out[0]]
#set_property package_pin Y7 [get_ports gtytxp_out[0]]
##set_false_path -through [get_pins -filter {REF_PIN_NAME=~*Q} -of_objects [get_cells -hierarchical -filter {NAME =~ *gen_pwrgood_delay_inst[0].delay_powergood_inst/gen_powergood_delay.pwr_on_fsm*}]] -quiet
set_case_analysis 1     [get_pins -filter {REF_PIN_NAME=~*Q} -of_objects [get_cells -hierarchical -filter {NAME =~ *gen_pwrgood_delay_inst[0].delay_powergood_inst/gen_powergood_delay.pwr_on_fsm*}]] -quiet

 

 




----------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution
Be sure to visit the Resources post periodically to keep up with the latest
https://forums.xilinx.com/t5/Serial-Transceivers/Serial-Transceiver-Forum-Guidelines-and-Useful-Resources/td-p/1173590
----------------------------------------------------------------------------


aaron-ueas
Visitor
Visitor
690 Views
Registered: ‎01-07-2020

@roym I used the IP catalog to generate the Aurora 64b/66b and used that wizard to define the quad and starting lane. My confusion comes from what to map the Rx and Tx pins to. In your example, can I just use Y1, Y2, Y6, Y7 etc?
For example, will this work for your example: ?

txp(3) <= TX15_P;
txn(3) <= TX15_N;
txp(2) <= TX14_P;
txn(2) <= TX14_N;
-- and so on

example_aurora_inst : aurora_64b66b_x4_support
    PORT MAP(
      -- TX AXI4-S Interface
      s_axi_tx_tdata  => tx_tdata_i,
      s_axi_tx_tvalid => tx_tvalid_i,
      s_axi_tx_tready => tx_tready_i,


      -- RX AXI4-S Interface
      m_axi_rx_tdata  => rx_tdata_i,
      m_axi_rx_tvalid => rx_tvalid_i,

      -- GT Serial I/O
      rxp => gthrxp_in[0],                 --              <<<<< Do I map it like this? I think this port name is only locally scoped so this will not work if I want to define more than one Aurora core 
      rxn => ?something_else?,                 --              <<<<< How do I map these without pin constraints for RX15_P etc.?                           

      txp => ?,                 --              <<<<< How do I map these without pin constraints for TX15_P etc.?
      txn => ?,                 --              <<<<< How do I map these without pin constraints for TX15_P etc.?

      --GT Reference Clock Interface
      gt_refclk1_p => CLK156_25MHZ4_P,
      gt_refclk1_n => CLK156_25MHZ4_N,

      -- Error Detection Interface
      hard_err => hard_err_i,
      soft_err => soft_err_i,

      -- Status
      channel_up => channel_up_i,
      lane_up    => lane_up_i,

      -- System Interface
      user_clk_out => user_clk_i,

      sync_clk_out      => sync_clk_i ,
      reset_pb          => reset_i ,
      gt_rxcdrovrden_in => gt_rxcdrovrden_i ,
      power_down        => power_down_i ,
      loopback          => loopback_i ,
      pma_init          => gt_reset_i ,
      gt_pll_lock       => gt_pll_lock_i ,

      ---------- AXI4-Lite input signals ---------------
      s_axi_awaddr        => s_axi_awaddr_i ,
      s_axi_awvalid       => s_axi_awvalid_i ,
      s_axi_awready       => s_axi_awready_i ,
      s_axi_awaddr_lane1  => s_axi_awaddr_lane1_i ,
      s_axi_awvalid_lane1 => s_axi_awvalid_lane1_i ,
      s_axi_awready_lane1 => s_axi_awready_lane1_i ,
      s_axi_awaddr_lane2  => s_axi_awaddr_lane2_i ,
      s_axi_awvalid_lane2 => s_axi_awvalid_lane2_i ,
      s_axi_awready_lane2 => s_axi_awready_lane2_i ,
      s_axi_awaddr_lane3  => s_axi_awaddr_lane3_i ,
      s_axi_awvalid_lane3 => s_axi_awvalid_lane3_i ,
      s_axi_awready_lane3 => s_axi_awready_lane3_i ,
      s_axi_wdata         => s_axi_wdata_i ,
      s_axi_wstrb         => s_axi_wstrb_i ,
      s_axi_wvalid        => s_axi_wvalid_i ,
      s_axi_wready        => s_axi_wready_i ,
      s_axi_bvalid        => s_axi_bvalid_i ,
      s_axi_bresp         => s_axi_bresp_i ,
      s_axi_bready        => s_axi_bready_i ,
      s_axi_wdata_lane1   => s_axi_wdata_lane1_i ,
      s_axi_wstrb_lane1   => s_axi_wstrb_lane1_i ,
      s_axi_wvalid_lane1  => s_axi_wvalid_lane1_i ,
      s_axi_wready_lane1  => s_axi_wready_lane1_i ,
      s_axi_bvalid_lane1  => s_axi_bvalid_lane1_i ,
      s_axi_bresp_lane1   => s_axi_bresp_lane1_i ,
      s_axi_bready_lane1  => s_axi_bready_lane1_i ,
      s_axi_wdata_lane2   => s_axi_wdata_lane2_i ,
      s_axi_wstrb_lane2   => s_axi_wstrb_lane2_i ,
      s_axi_wvalid_lane2  => s_axi_wvalid_lane2_i ,
      s_axi_wready_lane2  => s_axi_wready_lane2_i ,
      s_axi_bvalid_lane2  => s_axi_bvalid_lane2_i ,
      s_axi_bresp_lane2   => s_axi_bresp_lane2_i ,
      s_axi_bready_lane2  => s_axi_bready_lane2_i ,
      s_axi_wdata_lane3   => s_axi_wdata_lane3_i ,
      s_axi_wstrb_lane3   => s_axi_wstrb_lane3_i ,
      s_axi_wvalid_lane3  => s_axi_wvalid_lane3_i ,
      s_axi_wready_lane3  => s_axi_wready_lane3_i ,
      s_axi_bvalid_lane3  => s_axi_bvalid_lane3_i ,
      s_axi_bresp_lane3   => s_axi_bresp_lane3_i ,
      s_axi_bready_lane3  => s_axi_bready_lane3_i ,
      s_axi_araddr        => s_axi_araddr_i ,
      s_axi_arvalid       => s_axi_arvalid_i ,
      s_axi_arready       => s_axi_arready_i ,
      s_axi_araddr_lane1  => s_axi_araddr_lane1_i ,
      s_axi_arvalid_lane1 => s_axi_arvalid_lane1_i ,
      s_axi_arready_lane1 => s_axi_arready_lane1_i ,
      s_axi_araddr_lane2  => s_axi_araddr_lane2_i ,
      s_axi_arvalid_lane2 => s_axi_arvalid_lane2_i ,
      s_axi_arready_lane2 => s_axi_arready_lane2_i ,
      s_axi_araddr_lane3  => s_axi_araddr_lane3_i ,
      s_axi_arvalid_lane3 => s_axi_arvalid_lane3_i ,
      s_axi_arready_lane3 => s_axi_arready_lane3_i ,
      s_axi_rdata         => s_axi_rdata_i ,
      s_axi_rvalid        => s_axi_rvalid_i ,
      s_axi_rresp         => s_axi_rresp_i ,
      s_axi_rready        => s_axi_rready_i ,
      s_axi_rdata_lane1   => s_axi_rdata_lane1_i ,
      s_axi_rvalid_lane1  => s_axi_rvalid_lane1_i ,
      s_axi_rresp_lane1   => s_axi_rresp_lane1_i ,
      s_axi_rready_lane1  => s_axi_rready_lane1_i ,
      s_axi_rdata_lane2   => s_axi_rdata_lane2_i ,
      s_axi_rvalid_lane2  => s_axi_rvalid_lane2_i ,
      s_axi_rresp_lane2   => s_axi_rresp_lane2_i ,
      s_axi_rready_lane2  => s_axi_rready_lane2_i ,
      s_axi_rdata_lane3   => s_axi_rdata_lane3_i ,
      s_axi_rvalid_lane3  => s_axi_rvalid_lane3_i ,
      s_axi_rresp_lane3   => s_axi_rresp_lane3_i ,
      s_axi_rready_lane3  => s_axi_rready_lane3_i ,

      init_clk            => INIT_CLK_i ,
      link_reset_out      => link_reset_i ,
      mmcm_not_locked_out => pll_not_locked_i ,
      bufg_gt_clr_out => open, --bufg_gt_clr_out ,
      sys_reset_out => system_reset_i ,
      tx_out_clk    => tx_out_clk_i);

Regarding Pg074, I have read the document and understand creating the core with the correct starting lane and quad. My core creation is fine and If I open the implemented design and look at it on the device, then the aurora cores are routed in the correct quad. I am simply asking about port mapping to the core in HDL. The way my reference design does it is to map the port map like this:

rxp(0) <= EXAMPLE_PORT_NAME

where EXAMPLE_PORT_NAME is defined in the .xdc. The information in the documentation and also what you have said has confirmed this is the incorrect way to map the aurora core. How do I map the pins to the aurora core?

For reference my board is a XKCU115 and I am using quads 228, 224 and 225 but this is not required information, I just want to know how to map the ports if I haven't got external pins?

0 Kudos
Reply
roym
Moderator
Moderator
622 Views
Registered: ‎07-30-2007

>For reference my board is a XKCU115 and I am using quads 228, 224 and 225 but this is not required information, I just want to know how to map the ports if I haven't got external pins?

First of all RX and TX pins are external only.  They run at speeds up to and over 10Gbps which is too fast for any internal node.  I'm not sure I understand your statement.  If you don't map the aurora TX/RX to external pins it won't work. 

The whole point is that if you select the starting quad and starting lane in the wizard, it will define the pins for you.  You need to enter no constraints for the aurora TX and RX pins.  So in my example if you map the aurora TXP pin to "AuroraTXOut" at the top level.  Then that AuroraTXOut pin will be on the starting TX lane pin since there is only one lane and will be on V7.  Nothing needs to be done for that to happen because quad X1Y10 and starting lane X1Y41 has TXP at V7. 

GT are dedicated hard blocks I do not see a GT pin on a XKU115 AW10.  What is your package?

 




----------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution
Be sure to visit the Resources post periodically to keep up with the latest
https://forums.xilinx.com/t5/Serial-Transceivers/Serial-Transceiver-Forum-Guidelines-and-Useful-Resources/td-p/1173590
----------------------------------------------------------------------------


View solution in original post

aaron-ueas
Visitor
Visitor
606 Views
Registered: ‎01-07-2020

My board has an XKCU115 in flvf1924 package.

Okay, I think I finally understand what you are saying: The constraints are inbuilt/generated to the IP and do not need to be handled. All I should need to do is define the pins at the top level, and feed them to the Aurora port map and Vivado should be able to associate those top level signals with the constraints that it generated.

I will try this and see how I go, thanks for the help

 

0 Kudos
Reply
aaron-ueas
Visitor
Visitor
601 Views
Registered: ‎01-07-2020

Okay, I think @roym has helped me get to the bottom of this issue, the issue being my confusion.

- You do not need to constrain the Tx and Rx pins for aurora as the constraints are generated by the core. The signals still need to be mapped to your top level, with any arbitrary name that will get associated with the constraints, behind the scenes.

- My initial confusion was because I had a reference design that worked with constraining the Tx/Rx pins manually - this can work but is not the recommended flow. For some reason constraining manually did not work for my own design due to BEL/LOC conflicts between channel[3] and channel [0] etc in a x4 lane Aurora. Due to this, I wanted to do the recommended way and just let the tool generate the constraints.

- My design is actually for 2 different boards featuring the same FPGA - due to carelessness, I thought I was getting IO standards/constraints errors when writing a bitstream. This is because one synth/implement run in my project implements an Aurora in one specific quad but not in another quad. The errors I was getting was because one IP core was NOT being used (deliberately) but because my files are common to both scenarios, the top level ports include the Tx/Rx pins NOT being used for this particular run. In the case that the IP is not used in the synth/impl run but the ports are still fed in, I got errors where the top level ports cannot be associated with the autogenerated constraints, because there is no instantiation of the IP core. The TL;DR of this is: Do not define arbitrary ports for Aurora in your top design if they are not mapped to the Aurora. This will of course fail because they are unconstrained and have no IO Standard. Without the association between GT and the arbitrary ports, the requirement that top level ports need a physical location & io standard reappears and hence no bitstream can be generated.

Big thanks and kudos to @roym who helped me understand this problem, which was due to my own confusion...

 

0 Kudos
Reply