FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
6659 Discussions

GTS PMA/FEC Direct Transceiver Streaming

K606
New Contributor III
8,749 Views

I have been trying to set up the GTS PMA/FEC Direct on the Agilex 5 and would like to know how to stream parallel data to/from the GTS when the GTS does not expose a AV-Sink/Source on the parallel data interfaces?

 

A pic of the IP for reference:

 

K606_0-1752755709073.png

 

Thanks!

0 Kudos
25 Replies
CheePin_C_Intel
Employee
7,916 Views

Hi,


Thank you for filing this case and sharing the details. I appreciate your patience. Please allow me some time to review the information, and I’ll get back to you as soon as possible.


CheePin_C_Intel
Employee
7,821 Views

Hi,


Thank you for your question regarding streaming parallel data to/from the GTS PMA/FEC Direct PHY in Agilex 5.


As I understand it, you're working with the GTS PHY, which provides a native parallel data interface. To stream data, you’ll need to directly interface with the i_tx_parallel_data and o_rx_parallel_data buses. These are accompanied by their respective parallel clocks: i_tx_coreclkin for transmit and o_rx_clkout for receive. I believe you are using Platform Designer to instantiate this PHY IP. Please note that parallel data are conduit ports, and you’ll need to export them and connect at the top-level RTL of your design manually.


For more detailed information on how the parallel data is mapped for both TX and RX paths, I recommend referring to the GTS Transceiver PHY User Guide under the section titled “Parallel Data Mapping Information for TX and RX.”


Please let me know if you have any further questions. Thank you!


K606
New Contributor III
7,803 Views

Thanks @CheePin_C_Intel 

 

This is super useful - much appreciated. Actually yes, I do have a question on both the input and output parallel data lines for the GTS:

 

CLOCKING:

If I wanted to feed/read the input parallel data line (i_tx_parallel_data/o_rx_parallel_data) with, for instance, some basic oscillating component (feed) or some basic sampling component (read) - what clock should I power the oscillating/sampling unit with? Should it be with the same refclock that clocks the GTS (cdr_refclk, pll_refclk, refclk_xvcr)? Or should it be with the system clock that clocks the HPS? Or something else?

 

BIT MAPPING:
In this configuration map, I assume that the Lower and Upper Data bits are up to the user to set - so I am wondering how to use the 79 and 38 bits?

K606_0-1753176422286.png

 

Many thanks!

Kai

0 Kudos
CheePin_C_Intel
Employee
7,787 Views

Hi,


Regarding your inquiry about the appropriate clock signals for sampling parallel data into and out of the GTS PHY, please refer to the following recommendations:


1. o_tx_clkout

Connect this clock to the component that provides data to i_tx_parallel_data. Additionally, connect o_tx_clkout to i_tx_coreclkin to ensure that both the input data and the internal parallel logic of the GTS PHY operate within the same clock domain.


2. o_rx_clkout

Connect this clock to the component responsible for sampling data from o_rx_parallel_data. Also, connect o_rx_clkout to i_rx_coreclkin to maintain clock domain consistency on the receive path.


Please let me know if you have any further questions or concerns. Thank you.


K606
New Contributor III
7,741 Views

Ah ok I understand now - thanks!

On the o_rx_clkout side:

K606_0-1753188676138.png

 

It seems that the mSGDMA is required to be on the same clock domain as the component which is sampling from o_rx_parallel_data (named here as raw_to_stream) and so I have set it up as shown - will this cause issues when issuing the DMA commands from the HPS?

0 Kudos
CheePin_C_Intel
Employee
7,767 Views

Hi,


Just to add on, you may refer to the GTS Transceiver PHY User Guide: Agilex 5 FPGAs and SoCs -> "Table 55. Recommended Connection and Source" for further details on the coreclkin & clkout connection.


K606
New Contributor III
7,739 Views

Ah - thank you again! Does there also include a place to explain how to connect resets for the o_tx_clkout o_rx_clkout components?

 

0 Kudos
CheePin_C_Intel
Employee
7,766 Views

Hi,


By the way, just wonder if you have had a chance to take a look at the example designs supported by the GTS XCVR PHY? You may refer to the GTS Transceiver PHY User Guide: Agilex 5 FPGAs and SoCs -> "Table 87. Example Design Options", for the list of available example designs. Then generate one which is closest to your target configuration to check on the PHY configuration and interconnection.


Please let me know if you have any further questions or concerns. Thank you.


K606
New Contributor III
7,727 Views

Hi yes I did see this - after compilation, you can see here that after performing these commands in section 6.6:

% run_test_silb
-----------------------------------------------------------
-----------------------------------------------------------
Link is not UP
-----------------------------------------------------------
Apply RX reset: 0x00000022 
Number of lanes : 1
 1.  0x6A040
 2. 0x0006a040
Polling Successfull Bit 15: 0x000001 , Bit 14: 0x000000
 1. 0x62040
 2. 0x00062040
Polling Successfull Bit 15: 0x000000 , Bit 14: 0x000000
Release reset: 0x00000000 
Number of lanes : 1
 Serial loopback on Lane# 0 is enabled 

PHY IP Setting	: 0x0002c067 
Scratch Register	: 0x00000000 
Soft Rst Crtl	: 0x00000000 
TX/RX/AVMM Ready	: 0x00000010 
TX PLL Locked	: 0x00000001 
CDR LTR & LTD	: 0x00000001 
RX ignore LTD	: 0x00000000
Alarm status	: 0x00000000
-----------------------------------
Value from issp reset probe is 0x45/0b1000101
--------------------------
 Test Fail : Check the Link Status 
--------------------------
--------------- SILB TEST DONE ---------------- 

Apply RX reset: 0x00000022 
Number of lanes : 1
 1.  0x0A040
 2. 0x0000a040
Polling Successfull Bit 15: 0x000001 , Bit 14: 0x000000
 1. 0x02040
 2. 0x00002040
Polling Successfull Bit 15: 0x000000 , Bit 14: 0x000000
Release reset: 0x00000000 
Number of lanes : 1
 Serial loopback on Lane# 0 is disabled 

Maybe you have seen such an error before?

Many thanks!

0 Kudos
CheePin_C_Intel
Employee
7,426 Views

Hi,


Regarding your specific question about whether this might cause issues when issuing DMA commands from the HPS:


"will this cause issues when issuing the DMA commands from the HPS?"


I’m afraid this falls outside my area of expertise, so I’m unable to provide a reliable answer.


Would you mind opening a new thread on the Forum specifically for this inquiry? That way, our relevant experts can take a closer look and assist you more effectively.


Please let me know if you have any concerns. Thank you.


K606
New Contributor III
7,384 Views
0 Kudos
CheePin_C_Intel
Employee
7,425 Views

Hi,


Regarding your following question about the reset, would you mind to further elaborate on what is referred by o_tx_clkout or o_rx_clkout components?


"Does there also include a place to explain how to connect resets for the o_tx_clkout / o_rx_clkout components?"


Please let me know if you have any concerns. Thank you.


K606
New Contributor III
7,363 Views

So for instance, as you expained earlier in the thread, the component that is sampled by the GTS would be clocked by o_tx_clkout, and the component that samples from the GTS would be clocked by o_rx_clkout.

In a diagram:

K606_0-1753366823208.png

Now, there are also resets which I assume are controlled via these components, or am I incorrect?

Thanks!

0 Kudos
CheePin_C_Intel
Employee
7,424 Views

Hi,

Regarding your run with the example design, could you please let me know which specific design from Table 87: Example Design Options you are using? I’d like to ensure we’re on the same page before providing further comments.

Please feel free to reach out if you have any concerns. Thank you.


K606
New Contributor III
7,405 Views

Hi @CheePin_C_Intel 

So for this test output, I instantiated the following example design: 

Screenshot 2025-07-24 140851.png

0 Kudos
CheePin_C_Intel
Employee
7,380 Views

Hi,


Thanks for your update. Regarding the example design, just wonder if you could test with a simpler example design ie "1 x 1G PMA Direct Mode (System PLL Clocking) with Custom Cadence" to facilitate debugging. This design is running at lower data rate. You can first try running the simulation and then only on hardware.


Please let me know if you have any concern. Thank you.


K606
New Contributor III
7,368 Views

Hi @CheePin_C_Intel 

 

I just recompiled and tested this example, and found the same error!

0 Kudos
CheePin_C_Intel
Employee
5,747 Views

Hi,


Thanks for your update. As I compared your Terminal printout when running the example design, I notice some discrepancies between yours vs the one shown in the user guide.


Yours:

% run_test_silb

-----------------------------------------------------------

-----------------------------------------------------------

Link is not UP

-----------------------------------------------------------

Apply RX reset: 0x00000022 

Number of lanes : 1

 1. 0x6A040

 2. 0x0006a040

Polling Successfull Bit 15: 0x000001 , Bit 14: 0x000000

 1. 0x62040

 2. 0x00062040

Polling Successfull Bit 15: 0x000000 , Bit 14: 0x000000

Release reset: 0x00000000 

Number of lanes : 1

 Serial loopback on Lane# 0 is enabled 


PHY IP Setting : 0x0002c067 

Scratch Register : 0x00000000 

Soft Rst Crtl : 0x00000000 

TX/RX/AVMM Ready : 0x00000010 

TX PLL Locked : 0x00000001 

CDR LTR & LTD : 0x00000001 

RX ignore LTD : 0x00000000

Alarm status : 0x00000000


The one from user guide:


I observed:

Few discrepancies that I observed:

1. Your test starts with "Apply RX reset: 0x00000022" seems only resetting the RX while the example in UG starts with "Apply TX-RX reset: 0x00000033 "


2. In your case, the TX/RX/AVMM Ready : 0x00000010 but the one in the UG = 0x00000030. As I understand it from the main.tcl, we will need the value of 0x00000030 to declare the link up.

puts "-----------------------------------------------------------"

if {$phy_reset_status_reg==0x30} {puts "Link is UP"} {puts "Link is not UP"}

puts "----


3. In your case, the "CDR LTR & LTD : 0x00000001 " but the one in the UG = 0x00010001. In your case, the CDR has not yet achieved LTD state, this is indicated by the bit[16] = 0.


Can you help to look into these discrepancies and cross check with your test case to see if can give further clue.


Another thing to double check with you is it that you are running the example design on Agilex 5 FPGA ESeries 065B Premium Development Kit (ES1) board? If not, then you may also need to double check on the pin assignment.


Please let me know if there is any concern. Thank you.


K606
New Contributor III
5,634 Views

Hi @CheePin_C_Intel,

 

I am running the example design on this board.

 

I have changed the pin assignments in parameter.tcl.

 

I have not changed any other pins - should I have?

 

Many thanks!

0 Kudos
CheePin_C_Intel
Employee
5,743 Views

Hi,


Just to add that in case you are not using the devkit as mentioned in the user guide, then you should also take note of the following steps from user guide before starting your own pin assignment:



Reply