- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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):
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:
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:
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:
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
Regards,
Stefan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page