cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
EnthuMan
Explorer
Explorer
1,463 Views
Registered: ‎11-18-2013

GTH placement constraints

Hello,

     I have a question regarding GTH placement constraints and in general constraints for IP blocks.

As per the GTH guide, the location of the GTH transceiver is set by the placement constraints in an xdc file. 

Example of Kintex ultrascale in a particular package where there are 20 GTH transceivers or channels. 4 channels are grouped in a single bank (called a quad) and hence there are 5 such banks (from 224 to 228). Question: Can the GTH pins in each bank be assigned to any of the 4 channels in the bank or are they fixed to a particular channel? I am trying to understand the reason behind the user constraint of the GTH transceiver location (X_Y_)

So lets say, I have using 6 GTH transceivers rx_p[5..0] and tx_p[5..0]. In my constraints is it sufficient to assign the pins or do I also have to assign the location of the GTH transceiver? 

Further, in an example case of the a JESD IP core, the GUI asks me the number of lanes also asks the location of the first channel (X_Y_) as it assigns them in a sequence. So lets X0Y2 to X0Y7. So does this map sequentially i.e., rx_p[0] to X0Y2 and rx_p[5] to X0Y7?

Also, When I generate the core, it is created in /// project_1.srcs\sources_1\bd\mySystem\ip\mySystem_jesd204_phy_0_0

Along with core there are constraint files generated that based on the selection of the X_Y_ during the configuration have the appropriate location assignments. 

Questions here: Are these constraint files used by Vivado or are they samples for modification and usage by us. 

Thank you for your answers,

0 Kudos
7 Replies
1,442 Views
Registered: ‎07-23-2019

 

Whenever I used the GTH it was with the GT wizard so the GTH is selected in the GUI and then I suppose the constraint generated. If you select yourself what GTH to use, then they are bound to their pins, there is no selection possible between GTH transceivers and pins. you never constrain (LOC) the GTH pins, they are fixed. If the transceiver runs, the pins work.

0 Kudos
roym
Moderator
Moderator
1,399 Views
Registered: ‎07-30-2007

It is possible to reorder the pins within the banks.  It is not recommended because you would bypass some of the error checking by doing that.  If you can get the design to first implement and generate a bitstream successfully then it should be safe to reorder the pins within the banks.  It might be easier to reorder the T/RXDATA pins.  




----------------------------------------------------------------------------
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
----------------------------------------------------------------------------


0 Kudos
EnthuMan
Explorer
Explorer
1,353 Views
Registered: ‎11-18-2013

@roym @archangel-lightworks 

Thank you for your replies. 

I am afraid my question wasn't clear enough so I'll do it with the constraints that I have in a reference design.

The design uses a JESD phy and in the core configuration the starting location of the transceiver is taken as an input (XY location) and the channels are sequentially assigned. 

So lets say I have 8 inputs and nets are rx_in[7..0]. 

If I choose X0Y12 as the first location, the mapping will automatically be (or the tool assigned mapping):

rx_in[0]   -------- X0Y12

rx_in[1]   -------- X0Y13

and so on till

rx_in[7]   -------- X0Y19

 

Now lets say in my design I want rx_in[0] to be mapped to X0Y14 and rx_in[1] to be mapped to X0Y12 and similarly some combination for the rest what should I do?

The reference design does it in this way (I suppose this is the reason)

#set_property LOC GTHE3_CHANNEL_X0Y14 [get_cells -hier -filter {name =~ mySystem_i/JesdSubSys/jesd204_phy_0/inst/jesd204_phy_block_i/mySystem_jesd204_phy_0_0_gt_i/inst/gen_gtwizard_gthe3_top.mySystem_jesd204_phy_0_0_gt_gtwizard_gthe3_inst/gen_gtwizard_gthe3.gen_channel_container[0].gen_enabled_channel.gthe3_channel_wrapper_inst/channel_inst/gthe3_channel_gen.gen_gthe3_channel_inst[0].GTHE3_CHANNEL_PRIM_INST}]


#set_property LOC GTHE3_CHANNEL_X0Y13 [get_cells -hier -filter {name =~ mySystem_i/JesdSubSys/jesd204_phy_0/inst/jesd204_phy_block_i/mySystem_jesd204_phy_0_0_gt_i/inst/gen_gtwizard_gthe3_top.mySystem_jesd204_phy_0_0_gt_gtwizard_gthe3_inst/gen_gtwizard_gthe3.gen_channel_container[0].gen_enabled_channel.gthe3_channel_wrapper_inst/channel_inst/gthe3_channel_gen.gen_gthe3_channel_inst[1].GTHE3_CHANNEL_PRIM_INST}]

in addition to the following:

set_property PACKAGE_PIN H2 [get_ports {rxp_in_0[0]}]

set_property PACKAGE_PIN K2 [get_ports {rxp_in_0[1]}]

 

Question: Are both the above needed or only will suffice (because X0Y14 is anyhow mapped to H2). Would only the package_pin constraint suffice (and isn't it also simpler)?

Question 2: how can the long get_cells hier constraint be written in the set_property LOC constraint (how to get that long name)?

Question 3: We tried only the package_pin constraint and it did not work. Why?

Question 4: In a design if I have both rx_in[0] and tx_in[0] (logically not related) will remapping rx_in[0] by the constraints mechanism also remap tx_in[0]. 

Question 5: Referring to GTH transceiver guide Pg 23, the XY coordinate constraints are again mentioned (xdc files). Still not clear why just a pin assignment will not do the job? 

Thanks again for your time in helping me understand. 

 

 

 

 

 

 

0 Kudos
eschidl
Xilinx Employee
Xilinx Employee
1,344 Views
Registered: ‎10-19-2011

Hi @EnthuMan ,

you are right. The JESD PHY places the channels in sequential order from the starting point you give. You should not change this.
You could disrupt the created connections between quads used.

If you need to use transceivers that are not sequentially placed, please generate separate JESD cores for the separate sequences.
You could also set the 'Lane in use' register to disable/enable lanes within a core.

To swap lanes within a JESD/JESD PHY core please do not use the location constraints but the Lane ID register in the JESD core.
One JESD core can have 8 lanes maximum. With the use of the Lane ID register you could combine up to 32 lanes of several JESD cores to one entity.

Generally for the transceiver location constraints you have the two possibilities to define the location, either through the pin location or the channel primitive location. You should not use both together. One of them will suffice. Usually IPs that include transceivers have the transceiver location set in the underlying transceiver wizard IP. It depends on your design flow if you could overwrite this setting from toplevel or not.

------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
EnthuMan
Explorer
Explorer
1,303 Views
Registered: ‎11-18-2013

Hello @eschidl 

Thanks a lot for your response.

How do we change the lane ID. Is it through the AXI interface? 

Also, you mentioned that it is possible to overwrite the settings using a toplevel xdc file. A small side question here: Are all xdc files in the project directory (generated when IP cores are instantiated) used by the design? 

After some more search found the following Xilinx forum post:

https://forums.xilinx.com/t5/Serial-Transceivers/JESD204-Phy-IP-Starting-transceiver-location/m-p/878444/thread-id/2050

Here they propose three ways:

1) The first is a simple remapping (which even we wondered as to why it wasn't adopted in the first place, this type of "renaming" is done all the time)

2) Change LOC in XCI file. Please advise which XCI file and where?

3) Unpack AXI interface and reorder the channels. 

Thanks again,

 

0 Kudos
EnthuMan
Explorer
Explorer
1,152 Views
Registered: ‎11-18-2013

@eschidl sorry to bother you but may I ask if you could answer the queries. 

Thanks again,

0 Kudos
eschidl
Xilinx Employee
Xilinx Employee
1,089 Views
Registered: ‎10-19-2011

Hi @EnthuMan ,

sorry for the late reply.

seems I need to correct the part with the lane swap a little bit. If you have a lane swap on the board you would need to adjust similarly at another place. The lane ID can help with this. It is can be set by the JESD TX core and read by the JESD RX core. The access is through the AXI interface, thats right.

Additionally to the post you mention, you could swap the data already at the TX side if this is possible. In point 2) is not the actual xci file meant, but the underlying IP setup, if that is possible. We do not recommend to edit a xci file directly. You should do that through the corresponding wizard GUI for this. You could change the locations in the transceiver core xdc file, but you would need to make sure that the core files are not regenerated. This would overwrite the xdc file again.

Point 1) is probably the easiest way to do the swap internally.

If you want to use the xdc constraints you would need to consider some things to not run into problems. Should you use CPLL for the link a swap should be possible through constraints. When using QPLLs or other not lane specific PLLs you can only swap within the quad or entity. Otherwise you would run into implementation issues. Also it would depend on your design flow if you can easily change constraints. For example, if you would use a block design (IPI). Here, for instantiated IPs a DCP will be generated and will be used during synthesis/implementation. It often includes the used transceiver locations and your toplevel constraints that are meant to change these do not get applied. You would need to unmanage the IP and prevent the usage of the DCP. The underlying transceiver core sets the location through the CHANNEL primitive. If you want to overwrite from toplevel you should use this also. If you use the package pin locations instead you would have conflicting constraints.

------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------