cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Explorer
Explorer
976 Views
Registered: ‎10-09-2018

PCIe and Aurora 8b/10b GTP IP core in same Quad.

Hello,

I am working on 2 IP cores currently in same code and i.e. PCIe and GTP ( aurora 8b/10b).

As I am having 2 GTP common blocks in same bank, It's going to create problem for me. 

As I was reading other solutions about it, I have found out that I have to comment one of the GTP common block and drive all of it's signal to the other GTP  common block through instantiating in it's hierarchy to the other.

But i am confused here. How exactly I should do this How to add this signals from GTP common block to other(because it is already having it's own signal) 

0 Kudos
Reply
12 Replies
Xilinx Employee
Xilinx Employee
911 Views
Registered: ‎06-01-2017

The GTPE2_COMMON block includes PLL0 and PLL1, and is shared among 4 GTP channels. There is only one COMMON per quad. If you are running 2 channels of PCIe and 2 channels of Aurora in the same quad, then they have to share a single COMMON.

First, you will generate each of the designs with shared logic in the example design. This will place the COMMON outside of the core (in the example design) so you can make modifications to it in your user design. From the two IPs, you then generate example designs for both, so you will have 2 example designs and 2 COMMONs that you will now have to "merge". Make sure you are using different GTREFCLKs and PLLs so that the two IPs can be totally independent (one clocking/reset will not affect the other).

I would start with the PCIe example design. Copy over the Aurora CHANNEL instance from the Aurora example design. Then, look at the Aurora COMMON instance and compare that with the PCIe COMMON. Your goal is to merge them into one COMMON. This includes all port connections/wires and attributes. You will focus on merging the Aurora PLL settings into the PCIe COMMON. The attribute names should all have PLL0 or PLL1 prefix so you know which PLL they apply to.

I have to say that this is not a trivial task. My recommendation is to avoid sharing COMMON across different IPs if you can. Place them in different quads.

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
Explorer
Explorer
847 Views
Registered: ‎10-09-2018

Hello @jhua ,

Here is my system information:

- Win 10-64 bit , ISE 14.7, Artix 7 ( xc7a100t-2fgg484).

In above Artix series there is only 1 quad, So I have to share COMMON.

 

First, you will generate each of the designs with shared logic in the example design. This will place the COMMON outside of the core (in the example design) so you can make modifications to it in your user design. 

7s_wizard_init.jpg

above pic is from Vivado and it has option for shared logic.

but I am using ISE 14.7 and I am not seeing any option for shared logic here, So can I opt for shared logic as you said above? How to generate shared logic in the example design?

 

Thank You!

0 Kudos
Reply
Explorer
Explorer
783 Views
Registered: ‎10-09-2018

Hello,

@jhua  @karnanl @EnthuMan 

System- Artix7 xc7a100t-2fgg484(1 quad),  Win 10- 64  bit, ISE 14.7 

can anyone please give me some advice regarding above problem?

Instead of using aurora 8b/10b core, can I use 7series transceiver wizard IP core in ISE 14.7 to achieve what I want as I mentioned above.

 

Thanks!

Avinash

0 Kudos
Reply
Xilinx Employee
Xilinx Employee
753 Views
Registered: ‎06-01-2017

Hi @avinashc,

I believe in ISE, all files are available in RTL, i.e. you need not place the logics in example design (which is required in Vivado based design) to gain access to RTL.

In your generated design in ISE, you should see 2 COMMON blocks, one from PCIe and one from Aurora. Your goal is to migrate the Aurora COMMON and merge it into the PCIe COMMON. First, remove the Aurora COMMON from your design. Find out which PLL the Aurora IP uses. Let's assume Aurora uses PLL1 and PCIe uses PLL0. In the PCIe COMMON instance, you should see a lot of attributes with PLL1* prefix, and you need to copy over the PLL1* attributes from the Aurora COMMON to the PCIe COMMON (this is what I refer to as "merge"). For ports, you will take the PLL1OUTCLK from the PCIe COMMON and connect to the PLL1CLK port on the Aurora GTPE2_CHANNEL. Examine the other port connections done on the Aurora_COMMON <-> Aurora_CHANNEL, and make sure the same port connections are also migrated to the PCIe_COMMON <-> Aurora_CHANNEL.

Let me know if you have specific ports or attributes that you are not sure how to merge.

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
Explorer
Explorer
688 Views
Registered: ‎10-09-2018

Hello @jhua ,

So I was trying what you said above.

There was little change, I am using 2 aurora IP in same project. I created 2 IP's and then with below code I came to conclusion that both IP are using same pll i.e. pll0

Snippet of gtpe2_common present  inaurora_multi_gt ( this hierarchy  " aurora1_exedes->aurora1->aurora1_gt_wrapper->aurora1_multi_gt"). Same code is present in aurora2 hierarchy(gtpe2_common)

PLL0LOCK                        =>      GT0_PLL0LOCK_OUT,      
...
...
...
PLL1LOCK                        =>      open,

  let me know if this is correct and both IP's are using same pll i.e. pll0

--

I commented aurora1 gtpe2_common, attribute were same in both common and not driving anything so haven't took them from that IP to this IP. copied pll_clk port signals and drove them to gtpe2_channel in aurora IP1 from IP2.

So I have3 questions here,

1)so attribute thing is fine here,right?

2) Above "pll0_lock" which is driving  "GT0_PLL0LOCK_OUT" which is further getting used to generate gt_reset, do I need to follow up this signal and connect o/p of IP2's  "pll0_lock" to IP1's or I should not worry of this thing? ( how to take care of pll0_lock signal)

3) because I am using same IP twice, can i give same clk to both IP'S in the top file or that will create an issue?

 

Thank You!

0 Kudos
Reply
Xilinx Employee
Xilinx Employee
672 Views
Registered: ‎06-01-2017

Hi @avinashc 

1) Yes

2/3) If you have two identical IPs then yes, the two IPs will use the same PLL0 and PLL0 can be shared. You should make the same PLLLOCK connection from IP2/COMMON to IP1, i.e. IP1 will need the same gt_reset when PLL0LOCK deasserts. Also note that, in this configuration, since PLL0 is shared, if PLL0 is down, it would be down for both IPs. Say if you issue a PLL0 reset from one of the IP, then the other IP will lose the incoming clock at the same time. Namely the two IPs will have some dependency on each other.

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
Explorer
Explorer
567 Views
Registered: ‎10-09-2018

Hello @jhua ,

Thank you for the answer.

system- ISE 14.7, WIN 10-64bit, artix 7

Now  I am having 2 aurora IP and 1 PCIe IP core in same quad. As per above discussion I have already inserted 2 aurora IP in 1 quad successfully. Now I am adding PCIe IP core also in the same quad.

--

this is pcie gtpe2_common syntax in verilog file(I am using VHDL, but some files of IP core are in verilog)

.PLL0OUTCLK                     (QPLL_QPLLOUTCLK),                                            
        .PLL1OUTCLK                     (),        

So I think this means that PCIe is using pll0 while aurora is also using pll0. So now what should I do?

how to generate pll1 in PCIe IP core so that I can give it to aurora core and merge these IP's.

0 Kudos
Reply
Explorer
Explorer
528 Views
Registered: ‎10-09-2018

Hello @jhua ,

I am still stuck at the above problem.

If both aurora and PCIe IP core are using pll0, then can I copy pll0 attributes from aurora and paste it into  PCIe attribute in pll1 and then pll1 port output back to aurora IP. Is this the right way to solve my problem?

 

Thanks!

0 Kudos
Reply
Xilinx Employee
Xilinx Employee
446 Views
Registered: ‎06-01-2017

In ISE, do you get the option to choose which PLL the IP is generated with? Check both Aurora and PCIe GUI to see if either one of them has the flexibility?

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Reply
Explorer
Explorer
427 Views
Registered: ‎10-09-2018

Hello @jhua ,

No they don't have any pll option in there.

But i copied my aurora atrributes from gtp core and paste it into pll1 of pcie gtp common, It worked. Now 2 gtp and 1 pcie is working.

 

But i am having problem with generating bit file,it is giving me mapping error.

this is the error:

 

 

 

ERROR:Place:1388 - Unroutable Placement! A BUFDS / GT clock component pair have
   been found that are not placed at a routable BUFDS / GT site pair. The BUFDS
   component <pcie_inst/refclk_ibuf> is placed at site <IBUFDS_GTE2_X0Y3>. The
   GT component
   <pcie_inst/pcie_i/gt_top_i/pipe_wrapper_i/pipe_lane[0].pipe_quad.pipe_common.
   qpll_wrapper_i/gtp_common.gtpe2_common_i> is placed at site
   <GTPE2_COMMON_X0Y1>. The GT is driven by this BUFDS in regular mode and they
   must be placed in the same clock region to be routable because the BUFDS
   connects to the GT on a GTREFCLK pin. Furthermore, depending on the GTREFCLK
   bit used, only some BUFDS sites in the same clock region are routable to it.
   Check usage documents for routability of the device. This placement is
   UNROUTABLE in PAR and therefore, this error condition should be fixed in your
   design. You may use the CLOCK_DEDICATED_ROUTE constraint in the .ucf file to
   demote this message to a WARNING in order to generate an NCD file. This NCD
   file can then be used in FPGA Editor to debug the problem. A list of all the
   COMP.PINS used in this clock placement rule is listed below. These examples
   can be used directly in the .ucf file to demote this ERROR to a WARNING.
   < PIN "pcie_inst/refclk_ibuf.O" CLOCK_DEDICATED_ROUTE = FALSE; >
   < PIN
   "pcie_inst/pcie_i/gt_top_i/pipe_wrapper_i/pipe_lane[0].pipe_quad.pipe_common.
   qpll_wrapper_i/gtp_common.gtpe2_common_i.GTREFCLK0" CLOCK_DEDICATED_ROUTE =
   FALSE; >

ERROR:Place:1388 - Unroutable Placement! A BUFDS / GT clock component pair have
   been found that are not placed at a routable BUFDS / GT site pair. The BUFDS
   component <aurora2_exdes_inst/IBUFDS_GTE2_CLK1> is placed at site
   <IBUFDS_GTE2_X0Y2>. The GT component
   <pcie_inst/pcie_i/gt_top_i/pipe_wrapper_i/pipe_lane[0].pipe_quad.pipe_common.
   qpll_wrapper_i/gtp_common.gtpe2_common_i> is placed at site
   <GTPE2_COMMON_X0Y1>. The GT is driven by this BUFDS in regular mode and they
   must be placed in the same clock region to be routable because the BUFDS
   connects to the GT on a GTREFCLK pin. Furthermore, depending on the GTREFCLK
   bit used, only some BUFDS sites in the same clock region are routable to it.
   Check usage documents for routability of the device. This placement is
   UNROUTABLE in PAR and therefore, this error condition should be fixed in your
   design. You may use the CLOCK_DEDICATED_ROUTE constraint in the .ucf file to
   demote this message to a WARNING in order to generate an NCD file. This NCD
   file can then be used in FPGA Editor to debug the problem. A list of all the
   COMP.PINS used in this clock placement rule is listed below. These examples
   can be used directly in the .ucf file to demote this ERROR to a WARNING.
   < PIN "aurora2_exdes_inst/IBUFDS_GTE2_CLK1.O" CLOCK_DEDICATED_ROUTE = FALSE;
   >
   < PIN
   "pcie_inst/pcie_i/gt_top_i/pipe_wrapper_i/pipe_lane[0].pipe_quad.pipe_common.
   qpll_wrapper_i/gtp_common.gtpe2_common_i.GTREFCLK1" CLOCK_DEDICATED_ROUTE =
   FALSE; >

Phase 4.2  Initial Placement for Architecture Specific Features
(Checksum:5fe5585a) REAL time: 27 secs 

Total REAL time to Placer completion: 27 secs 
Total CPU  time to Placer completion: 27 secs 
ERROR:Pack:1654 - The timing-driven placement phase encountered an error.

 

 

 

please let me know if I am missing anything.

I have attached my ucf file

Thanks!

0 Kudos
Reply
Xilinx Employee
Xilinx Employee
415 Views
Registered: ‎06-01-2017

Hi @avinashc , check this answer record below and reverse the LOC constraints for MGTREFCLK0 vs MGTREFCLK1.

https://www.xilinx.com/support/answers/51349.html

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Reply
Explorer
Explorer
407 Views
Registered: ‎10-09-2018

Hello @jhua ,

*system: ISE 14.7,win10, Artix 7

              2GTP & PCIe in same quad.



@jhua wrote:

Hi @avinashc , check this answer record below and reverse the LOC constraints for MGTREFCLK0 vs MGTREFCLK1.

https://www.xilinx.com/support/answers/51349.html

                       I did that,even then error is coming as below:

 

ERROR:Place:1073 - Placer was unable to create RPM[BUFDS_RPMs] for the component
   pcie_inst/refclk_ibuf of type BUFDS for the following reason.
   The reason for this issue:
   All of the logic associated with this structure is locked and the relative
   placement of the logic violates the structure. The problem was found between
   the relative placement of BUFDS pcie_inst/refclk_ibuf at site
   IBUFDS_GTE2_X0Y3 and IPAD sys_clk_p at site IPAD_X1Y44.  The following
   components are part of this structure:
      BUFDS   pcie_inst/refclk_ibuf
      IPAD   sys_clk_p

ERROR:Place:1073 - Placer was unable to create RPM[BUFDS_RPMs] for the component
   aurora2_exdes_inst/IBUFDS_GTE2_CLK1 of type BUFDS for the following reason.
   The reason for this issue:
   Some of the logic associated with this structure is locked. This should cause
   the rest of the logic to be locked.A problem was found at site
   IBUFDS_GTE2_X0Y3 where we must place BUFDS
   aurora2_exdes_inst/IBUFDS_GTE2_CLK1 in order to satisfy the relative
   placement requirements of this logic.  BUFDS pcie_inst/refclk_ibuf appears to
   already be placed there which makes this design unplaceable.  The following
   components are part of this structure:
      BUFDS   aurora2_exdes_inst/IBUFDS_GTE2_CLK1
      IPAD   GTPQ2_P

ERROR:Place:1073 - Placer was unable to create RPM[BUFDS_RPMs] for the component
   pcie_inst/refclk_ibuf of type BUFDS for the following reason.
   The reason for this issue:
   All of the logic associated with this structure is locked and the relative
   placement of the logic violates the structure. The problem was found between
   the relative placement of BUFDS pcie_inst/refclk_ibuf at site
   IBUFDS_GTE2_X0Y3 and IPAD sys_clk_n at site IPAD_X1Y45.  The following
   components are part of this structure:
      BUFDS   pcie_inst/refclk_ibuf
      IPAD   sys_clk_n

ERROR:Place:1073 - Placer was unable to create RPM[BUFDS_RPMs] for the component
   aurora2_exdes_inst/IBUFDS_GTE2_CLK1 of type BUFDS for the following reason.
   The reason for this issue:
   Some of the logic associated with this structure is locked. This should cause
   the rest of the logic to be locked.A problem was found at site
   IBUFDS_GTE2_X0Y3 where we must place BUFDS
   aurora2_exdes_inst/IBUFDS_GTE2_CLK1 in order to satisfy the relative
   placement requirements of this logic.  BUFDS pcie_inst/refclk_ibuf appears to
   already be placed there which makes this design unplaceable.  The following
   components are part of this structure:
      BUFDS   aurora2_exdes_inst/IBUFDS_GTE2_CLK1
      IPAD   GTPQ2_N

Phase 1.1  Initial Placement Analysis (Checksum:761ca1e1) REAL time: 24 secs 

ERROR:Pack:1654 - The timing-driven placement phase encountered an error.

 

 

what can be the problem here?

Thanks!

 

0 Kudos
Reply