Issue with BSP Creation for Nios-V/m Using LPDDR4 on Agilex-5 (Quartus 24.1 & 24.3.1)

Hello,

Thanks for the reply.

The main problem is that the Address Span Extender is not visible as the processor's memory.

We found a workaround to make the Address Span Extender visible as memory for the processor by following the procedure described in the thread below:

Link to Intel Community Thread

Although the solution was provided almost 10 years ago, it surprisingly remains unresolved in the latest Quartus version. We successfully tested a similar approach on an Agilex-7 FPGA, though that was some time ago.

Also, in Quartus 24.1, in the Nios V Processor parameter editor, we could not find the Exception Agent section under "Vectors". Do we need to follow a special process to enable it? We are using "Nios V/m Microcontroller Intel FPGA IP".

Current Issue: BSP Generation Error

Now, we are facing another issue when creating the BSP. In our main QSYS module, we have QSYS submodules, each containing a Triple Speed Ethernet (TSE) IP core. The control ports of these TSE cores are exported to the top-level QSYS module and connected to the Avalon-MM interface of the processor.

When generating the BSP in Quartus 24.1, we receive this error:
SEVERE: There is duplication of connected device name "eth_tse_sgmii_avalon_arbiter_av_slave".

"eth_tse_sgmii" is the name of the TSE IP core included in the QSYS submodules. We did not face this issue in Quartus 23.4 when using a similar system for Agilex-7. The processor in both cases is Nios-V.

Observations & Workarounds

• The issue does not occur when TSE IP cores are instantiated directly in the main QSYS module.
• The error only appears when TSE IP cores are inside QSYS submodules.
• If we disconnect all the QSYS submodules from the Avalon-MM interface except one, the issue does not occur.
• Since we use multiple instances of the submodules, placing all TSE IP cores directly in the main QSYS module is not an ideal solution.
• We also have Modular Scatter-Gather DMA IP cores inside our QSYS submodule, but we did not face a similar issue corresponding to their Avalon-MM interface.

Request for Help

Could you suggest a workaround or a proper solution to resolve this issue while keeping the TSE IP cores inside QSYS submodules?

Thanks in advance for your support.

Best regards.