Forum Discussion
Agilex 5 GTS to HPS CDC/STA issue: help request!
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
10 Replies
- StefanG_Altera
Occasional Contributor
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
Contributor
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-socfpgaIt 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
- StefanG_Altera
Occasional Contributor
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-cardCONFIG_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
- Jeet14
Frequent Contributor
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
Contributor
Hi yes I am using the same .jic and .rbf
- RolandoS_Altera
Occasional Contributor
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
- tehjingy_Altera
Regular Contributor
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