cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
mistercoffee
Scholar
Scholar
7,898 Views
Registered: ‎04-04-2014

Including an IBERT core with my project, for testing

Hi,

 

So, maybe what I am trying to do is unusual. I have a design thats uses the GTX transceivers on a Kintex 7. It works, but there have been issues with jitter on the MGT clock (in summary, we have implemented it incorrectly, but need to stick with it for now, see here) .

 

In order to do a comparison with various different strategies I want to do an IBERT test and compare eye diagrams. So, I added the IBERT core to my design. I have run the IBERT test successfully before, but only as a standalone project, not within another project.

 

My plan is to connect the IBERT tester to my fibre out pins so that I can test the signal integrity and route my design output to some different pins. I am only interested in preserving the design on chip so I have to route it somewhere otherwise it will optimise out...

 

I can then try the various clocking strategies (which will produce different amounts of jitter on the MGT clock) and see which give the better eye diagrams.

 

However, a problem. I am effectively trying to share GTX_COMMON_X0Y1 for my PCS/PMA design core and the one for the IBERT, because I am using the same MGTREFCLK pins for each. This gives a mapping error, along the lines of the IBERT core is trying to map to GTX_COMMON_X0Y3 (which shouldn't exist as I have an FFG676 package hmm...) and can't connect to the GTXE2_CHANNEL_X0Y6 (correct).

 

I think in summary, what I need to know is, can I use the same MGTREFCLK for both an IBERT core and the PCS/PMA core in my design?

 

Thanks

 

0 Kudos
9 Replies
mcgett
Xilinx Employee
Xilinx Employee
7,894 Views
Registered: ‎01-03-2008

You would need to bring the IBUFDS_GTE2 out of both the IBERT and your PHY to the top level and route the output of these to both cores.

------Have you tried typing your question into Google? If not you should before posting.
Too many results? Try adding site:www.xilinx.com
0 Kudos
mistercoffee
Scholar
Scholar
7,887 Views
Registered: ‎04-04-2014

Ok, I assumed the IBUFDS_GTE2 is already out of the IBERT as the inputs, Q1_CLK0_MGTREFCLK_I and Q1_CLK1_MGTREFCLK_I, are single ended, not differential. In my working standalone example I instantiate an IBUFDS_GTE2 and connect the output to these pins.

 

In my main project I have taken the IBUFDS_GTE2 output (q1_clk0_refclk_i) in the PCS core and connected it to the two clk pins of the IBERT. This gives me the mapping error. 

 

I suppose it could be a pin planning, constraints problem. 

 

I have try to out a LOC on the following:

my main project: GTXE_CHANNEL_X0Y7, GTXE2_COMMON_X0Y1

IBERT: GTXE_CHANNEL_X0Y6, GTXE2_COMMON_X0Y1

 

My pins are:

both:

mgt_clk_in_p     Pin K6

mgt_clk_in_n     Pin K5

(I realise this is bank 115, that's how the project has it currently and it's fine...)

 

 

my main project:

MGT_BANK_116

MGT3

Fibre_out     Pins A4, A3

Fibre_in       Pins B6, B5

 

IBERT project:

MGT_BANK_116

MGT2

Fibre_out     Pins B2, B1

Fibre_in       Pins C4, C3

 

Have I missed anything?

 

0 Kudos
mcgett
Xilinx Employee
Xilinx Employee
7,880 Views
Registered: ‎01-03-2008

Please post the full error messages that are reported.

------Have you tried typing your question into Google? If not you should before posting.
Too many results? Try adding site:www.xilinx.com
0 Kudos
mistercoffee
Scholar
Scholar
7,863 Views
Registered: ‎04-04-2014

Ok, here is my MAP error message:

 

ERROR:Place:1390 - Unroutable Placement! A GTXE_COMMON / GT clock component pair have been found that are not placed at
a routable site pair. The GTXE_COMMON component
<IBERT_INST/U0/U_IBERT_CORE/U_GTCCPX_QUAD1/U_GTXE2_COMN_QUAD1/gtxe2_comm> is placed at site <GTXE2_COMMON_X0Y0>. The
corresponding GT component <IBERT_INST/U0/U_IBERT_CORE/U_GTCPX_X0Y6/U_GT_CHANNEL_X0Y6/gtxe2_i_x0y6> is placed at site
<GTXE2_CHANNEL_X0Y6>. The pair can use the fast path between them if the GTXE_COMMON and GT are both placed in the
same clock region. You may want to analyze why this problem exists and correct it. 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 "IBERT_INST/U0/U_IBERT_CORE/U_GTCCPX_QUAD1/U_GTXE2_COMN_QUAD1/gtxe2_comm.QPLLOUTCLK" CLOCK_DEDICATED_ROUTE =
FALSE; >
< PIN "IBERT_INST/U0/U_IBERT_CORE/U_GTCPX_X0Y6/U_GT_CHANNEL_X0Y6/gtxe2_i_x0y6.QPLLCLK" CLOCK_DEDICATED_ROUTE = FALSE;
>

 

I didn have an error in my code. After I corrected this it is now trying to place the IBERT GTXE2_COMMON at X0Y0. This is expected as the main project uses GTXE2_COMMON_X0Y1. This is my problem I think. Ideally they would both use the same GTXE2_COMMON but as the IBERT has it's own internally that I can't bring out, I end up using two.

 

0 Kudos
mistercoffee
Scholar
Scholar
7,861 Views
Registered: ‎04-04-2014

I think my solution may be to accept I have to use two separate quads with a common clock input. I'll try that now...

0 Kudos
venkata
Moderator
Moderator
7,856 Views
Registered: ‎02-16-2010

This issue cannot be worked around since QPLL output clocks cannot be brought out of the core.

To start with, IBERT is not recommended to be stitched along with custom designs. Please use it standalone.
------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
0 Kudos
mistercoffee
Scholar
Scholar
7,854 Views
Registered: ‎04-04-2014

Ok, well I have used it standalone before. Unfortunately in this instance it does not give useful information on the effect I am trying to measure. As I am trying to determine the effect of my other logic on clock jitter the test is only valid if that logic is present.

 

I wasn't aware of a reason why I could put them together in one design, so it seemed like a logical approach. I can understand not being able to bring QPPL clocks out of the core, I hadn't anticipated that. But, I would have thought using two QPLLs separates as I last suggested would be a valid solution.

 

Thanks

0 Kudos
venkata
Moderator
Moderator
7,840 Views
Registered: ‎02-16-2010

Given the possibilities, I think you could use a GT wizard example to do the testing you want to do. You could use pattern generator/checker combination to check for the errors.
------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
0 Kudos
concattocarol
Visitor
Visitor
3,115 Views
Registered: ‎09-02-2016

I am trying to use the GTX channels as well. I have two IP cores and I would like them to sent data one to another

So I am using: 

Core 1 :

Fiber_out: b1,b2

Fiber_in : d6,d5

 

Core 2:

Fiber_out c4, c3

Fiber_in: B6,B5

 

But when I try it says to locate the pins b1 and b2 and c4 and c3 it says site location is not valid. 

I am using a kintex 7(xc7k325tffg900-2 with a FM-S14 Board)

 

Tags (1)
0 Kudos