cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
stefangriebel
Observer
Observer
1,220 Views
Registered: ‎11-09-2011

Kintex Ultrascale ku060 In-System IBERT with SRIO v4.2

Jump to solution

I added the In-System IBERT cores to debug why some of my 4-lane 3.125 GSPS SRIO cores do not achieve Link Init and/or Port Init when configured in Near-End PMA Loopback per UG576. I have a 156.25 MHz clock coming in on mgt127_0. The SRIO core on quad127 has the shared logic in the core and provides the log, buf, phy, etc clock/resets to the other SRIO cores on quad126 and quad128 that are configured without shared logic. The In-System IBERTs connected to SRIO cores on quad 126 and 128 work correctly, but the IBERT connected to SRIO core on quad 127 will not produce any plots. It is recognized in the Vivado HW manager and I can create the Serial I/O Links in quad127, but any attempts to scan them result in a time-out where the Progress bar remains at 0% the entire time.

The exact same is true for quads 224, 225, 226, 227 where I bring in the mgt_clk to the SRIO Core on quad 226. The IBERT works on quad 224, 225, and 227, but not 226.

All In-System IBERT Cores connect up 1-to-1 with the SRIO cores. For the drp_clk_i, I am using an independent 125 MHz clock, the same clock that is connected to the freerun_clk inputs of the SRIO cores (126, 128) without shared logic. The SRIO core (127) with shared logic does not have a freerun_clk input.

I can provide logs, screenshots, Vivado BD TCL scripts as needed. Please advise.

Thanks,
Stefan

---

Tool Versions

  • Vivado 2019.1
  • Serial RapidIO Gen2 (4.1) 
  • In System IBERT (1.0)

 

0 Kudos
1 Solution

Accepted Solutions
jhua
Xilinx Employee
Xilinx Employee
974 Views
Registered: ‎06-01-2017

Hi @stefangriebel 

You can make all instances with shared logic in the example design, and for the one which you used to have shared logic in the core (quad 127), open the IP in example design. The example design will instantiate the auxiliary blocks that were moved from the core to the example design. The other quads can then be instantiated to the example design and make the necessary connections.

Thanks,
Jessica
------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
If starting with Versal take a look at our Versal Design Process Hub and our
Versal Blogs
------------------------------------------------------------------------------------------------

View solution in original post

8 Replies
jhua
Xilinx Employee
Xilinx Employee
1,207 Views
Registered: ‎06-01-2017

Hi @stefangriebel 

Can you describe what clocks are used for drpclk_i, clk, and the DRPCLK port of the corresponding GTs? See these screenshots from PG246 - https://www.xilinx.com/support/documentation/ip_documentation/in_system_ibert/v1_0/pg246-in-system-ibert.pdf.

jhua_0-1604097839043.pngjhua_1-1604097856582.pngjhua_2-1604097869579.pngjhua_3-1604097933757.png

 

 

Thanks,
Jessica
------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
If starting with Versal take a look at our Versal Design Process Hub and our
Versal Blogs
------------------------------------------------------------------------------------------------
0 Kudos
stefangriebel
Observer
Observer
1,190 Views
Registered: ‎11-09-2011

Thanks for the quick response!

All clk inputs to the In-System IBERT cores are connected to a free-running 125 MHz clock that never resets. This clock is highlighted in "ibert_quad126.png"

This is the same clock attached to the freerun_clk inputs of the SRIO cores with shared logic outside the core (quads 126 & 128). Clock is highlighted in "srio_core0_quad126.png"

There seems to be no place to connect this clock to the SRIO core that has shared logic inside the core (quad 127). See "srio_core1_quad127_with_clock.png"

ibert_quad126.png
srio_core0_quad126.png
srio_core1_quad127_with_clock.png
0 Kudos
jhua
Xilinx Employee
Xilinx Employee
1,182 Views
Registered: ‎06-01-2017

Internally, can you see which clock is Quad 127 DRPCLK connected to?

Thanks,
Jessica
------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
If starting with Versal take a look at our Versal Design Process Hub and our
Versal Blogs
------------------------------------------------------------------------------------------------
0 Kudos
stefangriebel
Observer
Observer
1,120 Views
Registered: ‎11-09-2011

I don't know how to look further inside the SRIO IP core that what Vivado displays in the bd! That would be great, how do I do that?

0 Kudos
stefangriebel
Observer
Observer
1,117 Views
Registered: ‎11-09-2011
... *than* what Vivado displays ...
0 Kudos
stefangriebel
Observer
Observer
1,009 Views
Registered: ‎11-09-2011

After generating output products and tracing signals in my simulation, I was able to locate the source of freerun_clk for the SRIO core with the shared logic in the core. It is created in the srio_clk.v and originates on the ODIV2 port of the IBUFDS_GTE3 primitive, and is run through a BUFG before being connected to the internal freerun_clk signals, then eventually to the drpclk_in of the gt_wrapper_inst. See attached screenshot.

This would explain why the In-System IBERT on quad 127 is not working: its drpclk is an async 125 MHz free-running clock, while the GT drpclk is 156.25/4 MHz clock.

Unfortunately, this freerun_clk from srio_clk.v is not promoted up through the IP block instantiation in Vivado so I cannot connect it to my other SRIO cores. Is there a solution to this other than making ALL cores without shared logic, and adding the srio_clk.v and srio_rst.v separately?

I also wonder if this discrepancy could be the source of my SRIO internal loopbacks not locking, but that is really a separate topic.

 

srio_clk_inst_and_freerun_clk.png
0 Kudos
jhua
Xilinx Employee
Xilinx Employee
975 Views
Registered: ‎06-01-2017

Hi @stefangriebel 

You can make all instances with shared logic in the example design, and for the one which you used to have shared logic in the core (quad 127), open the IP in example design. The example design will instantiate the auxiliary blocks that were moved from the core to the example design. The other quads can then be instantiated to the example design and make the necessary connections.

Thanks,
Jessica
------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
If starting with Versal take a look at our Versal Design Process Hub and our
Versal Blogs
------------------------------------------------------------------------------------------------

View solution in original post

stefangriebel
Observer
Observer
934 Views
Registered: ‎11-09-2011

This was a solution. Issue was my external freerun_clk (125 MHz independent osc) was fine when used for all the other cores and their IBERTs, but it wouldn't work with the IBERT on quad127 because it had an internal freerun_clk derived from the 156.25 MHz clock. Ensuring that both the IBERT and the GT get the same freerun_clk fixed the problem.

0 Kudos