Intel® SoC FPGA Embedded Development Suite
Support for SoC FPGA Software Development, SoC FPGA HPS Architecture, HPS SoC Boot and Configuration, Operating Systems
567 Discussions

Agilex 5 GTS to HPS CDC/STA issue: help request!

K606
New Contributor III
2,380 Views

I am trying to bring-up the GTS component on the A5.

The general idea is: Oscillator -> GTS -> FIFO -> DMA -> HPS -> Application.

The Qsys diagram looks as followed (HPS section omitted for brevity):

K606_0-1753778136640.png

It's also worth noting that the Osc -> FIFO -> DMA-> HPS design has been tested and works ok.

Furthermore, the only changes I have made to the GTS and FIFO IP are as followed:

 
GTS FEC/PMA PHY settings changed from factory:
------------------------------
Datapath clocking mode                   : PMA
TX/RX PMA interface FIFO mode   : Register
TX/RX clock options                          : Word Clock
 
Avalon DC FIFO settings changed from factory:
------------------------------
Symbols per beat    : 4
Bits per symbol        : 8
FIFO depth                : 32
Channel width          : 0
Error width                : 0

I have compiled two different designs:
 

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

1: Reduced test

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

Clock domain A: Oscillator -> GTS -x

Clock domain B: 32'b1 -> FIFO -> DMA -> HPS

 

The linking HDL in the top level (HPS section omitted for brevity):

module top(...);
...
// GTS signals
wire gts_i_rx_cdr_refclk;
wire gts_i_tx_pll_refclk;
reg gts_i_tx_reset, gts_i_rx_reset;
wire gts_o_tx_reset_ack, gts_o_rx_reset_ack;
wire gts_i_tx_coreclkin, gts_i_rx_coreclkin;
wire gts_o_tx_clkout, gts_o_rx_clkout;
wire gts_o_tx_serial_data, gts_o_tx_serial_data_n;
wire gts_i_rx_serial_data, gts_i_rx_serial_data_n;
wire [79:0] gts_i_tx_parallel_data;
wire [79:0] gts_o_rx_parallel_data;

wire osc_clk, raw2s_clk, fifo_clkin;
wire osc_rst, raw2s_rst, fifo_reset;
wire [31:0] osc_pattern_o;
wire [31:0] raw2s_data_i;

// reset
always @(posedge system_clk_100) begin
      if (system_reset) begin
            gts_i_tx_reset <= 1'b1;
            gts_i_rx_reset <= 1'b1;
      end else begin
            if((gts_o_tx_reset_ack==1'b1) && (gts_o_rx_reset_ack==1'b1)) begin
                  gts_i_tx_reset <= 1'b0;
                  gts_i_rx_reset <= 1'b0;
            end
      end
end

// GTS internal clocks
assign gts_i_tx_coreclkin = gts_o_tx_clkout;
assign gts_i_rx_coreclkin = gts_o_rx_clkout;

// serial data
assign gts_i_rx_serial_data = gts_o_tx_serial_data;
assign gts_i_rx_serial_data_n = gts_o_tx_serial_data_n;

// GTS to DMA
assign fifo_clkin = system_clk_100;
assign fifo_reset = ~system_reset;
assign raw2s_clk = system_clk_100;
assign raw2s_rst = ~system_reset;
assign raw2s_data_i = 32'b1;

// Oscillator to GTS
assign osc_clk = gts_o_tx_clkout;
assign osc_rst = gts_i_tx_reset;
assign gts_i_tx_parallel_data[31:0] = osc_pattern_o;

// Qsys Top module
qsys_top soc_inst (
.clk_100_clk                               (system_clk_100),
.ninit_done_ninit_done                     (ninit_done),
.intel_directphy_gts_0_i_rx_cdr_refclk_p_clk                     (REFCLK),
.intel_directphy_gts_0_i_tx_pll_refclk_p_clk                     (REFCLK),
.intel_directphy_gts_0_i_tx_reset_tx_reset                       (gts_i_tx_reset),
.intel_directphy_gts_0_i_rx_reset_rx_reset                       (gts_i_rx_reset),
.intel_directphy_gts_0_o_tx_reset_ack_tx_reset_ack               (gts_o_tx_reset_ack),
.intel_directphy_gts_0_o_rx_reset_ack_rx_reset_ack               (gts_o_rx_reset_ack),
.intel_directphy_gts_0_i_tx_coreclkin_clk                        (gts_i_tx_coreclkin),
.intel_directphy_gts_0_i_rx_coreclkin_clk                        (gts_i_rx_coreclkin),
.intel_directphy_gts_0_o_tx_clkout_clk                           (gts_o_tx_clkout),
.intel_directphy_gts_0_o_rx_clkout_clk                           (gts_o_rx_clkout),
.intel_directphy_gts_0_o_tx_serial_data_o_tx_serial_data         (gts_o_tx_serial_data),
.intel_directphy_gts_0_o_tx_serial_data_n_o_tx_serial_data_n     (gts_o_tx_serial_data_n),
.intel_directphy_gts_0_i_rx_serial_data_i_rx_serial_data         (gts_i_rx_serial_data),
.intel_directphy_gts_0_i_rx_serial_data_n_i_rx_serial_data_n     (gts_i_rx_serial_data_n),
.intel_directphy_gts_0_i_tx_parallel_data_i_tx_parallel_data     (gts_i_tx_parallel_data),
.intel_directphy_gts_0_o_rx_parallel_data_o_rx_parallel_data     (gts_o_rx_parallel_data),
.intel_srcss_gts_0_i_src_rs_priority_src_rs_priority             (1'b1),
.oscillator_0_clk_clk                                            (osc_clk),
.oscillator_0_rst_reset                                          (osc_rst),
.oscillator_0_oscillator_pattern_o_new_signal                    (osc_pattern_o),
.raw_to_stream_0_conduit_end_1_new_signal                        (raw2s_data_i),
.raw_to_stream_0_rst_reset                                       (raw2s_rst),
.raw_to_stream_0_clk_clk                                         (raw2s_clk),
.st_dc_fifo_0_in_clk_clk                                         (fifo_clkin),
.st_dc_fifo_0_in_clk_reset_reset_n                               (fifo_reset),
...
);
...
endmodule

The STA output:

K606_3-1753781325297.pngK606_4-1753781335627.png

And the system boot (SUCCESS):

Downloading FPGA bitstream...
Using ethernet@10830000 device
TFTP from server **bleep**.**bleep**.**bleep**.**bleep**; our IP address is **bleep**.**bleep**.**bleep**.**bleep**
Filename 'fpga/soc_system_base.rbf'.
Load address: 0x90000000
Loading: #################################################################
         #################################################################
         ######
         2 MiB/s
done
Bytes transferred = 1994752 (1e7000 hex)
..FPGA reconfiguration OK!

 

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

2: Full test

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

Clock Domain A+B: Oscillator -> GTS -> FIFO -> DMA -> HPS

 

The changes made to the linking HDL:

module top();
...
// GTS to DMA
assign fifo_clkin = gts_o_rx_clkout;
assign fifo_reset = gts_i_rx_reset;
assign raw2s_clk = gts_o_rx_clkout;
assign raw2s_rst = gts_i_rx_reset;
assign raw2s_data_i = gts_o_rx_parallel_data[31:0];
...
endmodule;

Note that the reason for connecting the tx_out and rx_out can be seen in this comment

The STA output:

K606_2-1753779566912.png

K606_1-1753779550104.png

The system boot (HANG): 

Downloading FPGA bitstream...
Using ethernet@10830000 device
TFTP from server **bleep**.**bleep**.xx.x; our IP address is **bleep**.**bleep**.xx.x
Filename 'fpga/soc_system_base.rbf'.
Load address: 0x90000000
Loading: #################################################################
         #################################################################
         #######
         2 MiB/s
done
Bytes transferred = 2011136 (1eb000 hex)
........
FPGA reconfiguration failed!Command 'load' failed: Error -110
FPGA not ready. Bridge reset aborted!

 

Conclusion:

=========

The above has led me to believe that the issue with the design occurs at the CDC between the GTS and the HPS.

I am not experienced with these sort of issues where the STA files seem to hold the key to debugging, and so would appreciate some help navigating how to approach this kind of problem!

Many thanks

0 Kudos
10 Replies
StefanG_Altera
Employee
2,336 Views

Hi,

Have you tried to configure the bitstream ("Full Test") via JTAG or at boot prompt (fpga load)?
What Quartus Pro version and u-boot/linux branch versions are you using? Thanks.

Regards,
Stefan

K606
New Contributor III
2,092 Views

Hi - unfortunately with JTAG programming, this error occurs:

...
Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1...
Loading Environment from UBI... "Synchronous Abort" handler, esr 0x96000010, far 0x108d2000
elr: 0000000080263ce8 lr : 0000000080263ef4 (reloc)
elr: 00000000ffd54ce8 lr : 00000000ffd54ef4
x0 : 00000000108d2000 x1 : 0000000000003228
...
Code: 32000021 d5033fbf b9000001 d65f03c0 (b9400001)
Resetting CPU ...
### ERROR ### Please RESET the board ###

Here the u-boot and linux branches are:

git clone -b atuma5_v1.1 https://github.com/terasic/u-boot-socfpga u-boot-socfpga 
git clone --filter=tree:0 -b atuma5_v1.2 https://github.com/terasic/linux-socfpga linux-socfpga 

It is worth also noting, that:

1: It seems doing it this way does let the bitstream load onto the FPGA (based on LED responses)

2: Doing it this way with a base HPS bitstream (with no GTS component) lets the boot sequence finish successfully

0 Kudos
StefanG_Altera
Employee
2,047 Views

Hi,

 

Ok I understand the "full test" image also failed to configure over JTAG but we lack more detailed information why.

Can you please confirm the Quartus version you use?

 

I assume you are using the HPs 1st mode configuration, please confirm.
In this case can you stop at u-boot prompt and manually run fpga load, e.g. according to the u-boot bootcmd (CONFIG_BOOTCOMMAND environment example) in https://altera-fpga.github.io/rel-25.1/embedded-designs/agilex-5/e-series/modular/boot-examples/ug-linux-boot-agx5e-modular/#boot-from-sd-card 

 

CONFIG_BOOTCOMMAND="load mmc 0:1 \${loadaddr} ghrd.core.rbf; fpga load 0 \${loadaddr} \${filesize};bridge enable;..

In case of failure it should report an error code and related details, see an example capture below:

StefanG_Altera_0-1753907229748.jpeg

 

Regards,
Stefan

K606
New Contributor III
1,822 Views

It is Quartus 24.3. Yes it is in HPS First mode.

When executing the command you mentioned, I get this result: 

SOCFPGA_AGILEX5 # fpga load 0 ${fpgadata} ${fpgadatasize}
.............................................................FPGA reconfiguration failed!
Command 'load' failed: Error -110

 

0 Kudos
StefanG_Altera
Employee
1,711 Views

Hi,

 

Could you try "bridge disable" before "fpga load" at u-boot prompt?

 

My understanding is that the configuration error reporting feature is incorporated in v25.1 embedded SW package (need to confirm).

Could you try to compile your FPGA design (GHRD) with Quartus Pro 25.1 and build u-boot from our v25.1 fork?

git clone -b QPDS25.1_REL_GSRD_PR https://github.com/altera-fpga/u-boot-socfpga

As in the Agilex 5 Premium Development Kit Example in https://altera-fpga.github.io/rel-25.1/embedded-designs/agilex-5/e-series/premium/boot-examples/ug-linux-boot-agx5e-premium/#boot-from-sd-card

 

You would need to include your defconfig (configs/socfpga_agilex5_atuma5_defconfig, include/configs/socfpga_agilex5_atuma5.h) and device trees in arch/arm/dts (socfpga_agilex5_atuma5.dts, socfpga_agilex5_atuma5-u-boot.dtsi).

 

Regards,

Stefan

K606
New Contributor III
1,192 Views

Hi

I have discovered that replacing the line:

.intel_directphy_gts_0_o_rx_parallel_data_o_rx_parallel_data     (gts_o_rx_parallel_data)

 with

.intel_directphy_gts_0_o_rx_parallel_data_o_rx_parallel_data     (32'b0)

Lets the system boot - based on this; what would you recommend? 

0 Kudos
Jeet14
Employee
1,251 Views

Hi K606,


Any update on this case?

Also, please update that you are using the same .jic and .rbf files which are generated from the same Quartus Programming File Generator version.


Regards

Tiwari


K606
New Contributor III
1,194 Views

Hi yes I am using the same .jic and .rbf

0 Kudos
RolandoS_Altera
Employee
772 Views

Hello K606

 

I am wondering if the issue could be related to IO HASH compatibility documented in https://www.intel.com/content/www/us/en/docs/programmable/813762/25-1/hps-io-hash-compatibility.html

 

There are several factors that could create this problem that affect the HPS Boot First  boot mode. The main factors that could cause this issue is that the Quartus version used to create the PHASE 1  should be the same than the one used in PHASE2. The other factor that could cause this issue is that this IO HASH calculated from the configuration in the HPS Banks (including the HPS EMIF) mismatches between the PHASE1 and PHASE 2. So it's always recommended that if you rebuild the hardware design, you use the PHASE1(loaded from your jic image or transfered through JTAG) and PHASE2 (transfer with TFTP) from this new build.

There are many other causes that generate this issue, these are described in the document above. Please take a look to this to confirm or disscard that this could be the problem you are facing.

 

Thanks

Rolando

 

0 Kudos
JingyangTeh_Altera
173 Views

Hi


As we do not receive any response from you on the previous question/reply/answer that we have provided. Please login to ‘https://supporttickets.intel.com/s/?language=en_US’, view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you on your follow-up questions.


Regards

Jingyang, Teh


0 Kudos
Reply