RVALID is high after reset on Agilex 7 M-series F2H bridge

[Mikhail_a]

Hello
I work with Agilex 7 M-series device and I see a strange behavior of F2H bridge. I see that after deasserting f2h rst_n RVALID and BVALID signal go high, also I see some data coming from RDATA bus:

 

I see it even when f2h bridge is not connected to anything. Here are settings for HPS:

I use Quartus 23.4.

So probably you know what can be wrong here? 

[EBERLAZARE_I_Intel]

Hi,

Are you using this board?:

https://www.intel.com/content/www/us/en/products/details/fpga/development-kits/agilex/agm039.html

May I know how you boot up the board, using SD card etc?

Can you explain briefly how you perform the reset, is it thourgh the signal tap?

Also, if you do a power cycle of the board does the signal also behave the same?

If you are using the above aforementioned board, we have the GSRD for it:

https://www.rocketboards.org/foswiki/Documentation/AgilexSoCGSRDDEVAGM039F

[Mikhail_a]

Hi!

You are right I use the exact same board.

I used this GSRD from the rocketboards as a reference. But as I found out its u-boot doesn't enable FPGA-HPS bridges, so I have to build u-boot as described here https://www.rocketboards.org/foswiki/Documentation/BuildingBootloaderAgilex7 while using the same kernel and fsbl binary as in mentioned GSRD.

I have a custom module that holds asserted reset for couple of minutes so I have time to enable signaltap and observe its deasserting. But even without this module I see that after ninit_done is asserted i have RVALID high. I see this issue every time I boot the board. 

[EBERLAZARE_I_Intel]

Hi,

Just want to check if you are also using the latest versions of the source code releases, U-boot = socfpga_v2023.10 etc..?

Okay, so using the GHRD from Rocketboards, the FPGA configuration is done right before "starting the kernel", including enabling the FPGA bridges:

Is it possible that you check again the signals behavior after booting to Linux as root in the signal tap? That would confirm that the bridge and FPGA enable and configured and the signal should behave as it should.

If you still see otherwise, let us know.

[Mikhail_a]

I use 

U-Boot SPL 2023.07-rc6 (Nov 20 2023 - 08:40:20 +0000) - got from GSRD
and  

U-Boot 2023.10-31805-g69d5338be0-dirty - built by myself according to rocketboards guide

---

---

and boot log looks like this:

CPU: Intel FPGA SoCFPGA Platform (ARMv8 64bit Cortex-A53)
Model: SoCFPGA Agilex SoCDK
DRAM: 2 GiB
Core: 28 devices, 23 uclasses, devicetree: separate
WDT: Started watchdog@ffd00200 with servicing every 1000ms (10s timeout)
MMC: dwmmc0@ff808000: 0
Loading Environment from FAT... OK
In: serial0@ffc02000
Out: serial0@ffc02000
Err: serial0@ffc02000
Net: eth0: ethernet@ff800000
Hit any key to stop autoboot: 0
10739712 bytes read in 499 ms (20.5 MiB/s)
FPGA not ready. Bridge reset aborted!
...........FPGA reconfiguration OK!
38816256 bytes read in 1817 ms (20.4 MiB/s)
32237 bytes read in 5 ms (6.1 MiB/s)
RSU: Firmware or flash content not supporting RSU
RSU: Firmware or flash content not supporting RSU
RSU: Firmware or flash content not supporting RSU
RSU: Firmware or flash content not supporting RSU
## Flattened Device Tree blob at 08000000
Booting using the fdt blob at 0x8000000
Working FDT set to 8000000
Loading Device Tree to 000000007eafb000, end 000000007eb05dec ... OK
Working FDT set to 7eafb000

Starting kernel ...

Deasserting all peripheral resets
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]

[Mikhail_a]

Some update

I've upgraded Quartus to 24.1, upgraded u-boot fsbl to 2023.10

and now I see that RVALID signal is low after reset, but It looks like ARLEN signal is not connected to where it should be. So on any read request the bridge returns only one transfer of data with RLAST high irrespective to any ARLEN I send. It looks like ARLEN is always zero right now.

[EBERLAZARE_I_Intel]

Hi,

I see in the old boot logs, the FPGA bridges are not setup yet:

How's the latest boot log using the latest Quartus and U-boot? Is the bridge configured properly now?

In the new U-boot, the bridge enable is added as per line 15 & 54:
u-boot-socfpga/drivers/fpga/altera.c at socfpga_v2023.10 · altera-opensource/u-boot-socfpga · GitHub

Okay, for these signal is more related to the HBM2 IP and how the AXI interface is defined(HBM2 IP UG):

https://www.intel.com/content/www/us/en/docs/programmable/683189/23-4-19-6-1/axi-user-interface-signals.html

As I couldn't find these signals in the HPS TRM for Agilex 7, for the ARLEN it is the burst length transaction (you may find it in the above link, "axi_0_0_arlen"). How is the HBM2 IP's setting on the burst length value?

Anyway, I am a bit caught up on my side and the HBM2 IP is new to me too, so I may provide my responses late.

Thanks for your patience.

[Artavazd]

Hi

This piece of log

FPGA not ready. Bridge reset aborted!
...........FPGA reconfiguration OK!

goes from U-Boot as it tries to disable bridges before programming FPGA, after that it enables them and as enabling bridges was successful there are no more messages about it.

As I see bridges are configured alright, at least I'm able to use HPS to FPGA bridge with no issues. 

To be honest I see no connection between HBM and FPGA2HPS bridge, they are completely separated IP and I don't think HBM can somehow help me here. 

I haven't seen any AXI settings for FPGA2HPS bridge such as burst length, I thought it is just supposed to support lengths more than one.