SDRAM Controller bug: missed data word

[adrianf0]

I have a project (attachment) using an open source 32-bit RISC-V processor connected in Qsys through 32-bit AXI bus and SDRAM Controller (v 18.1) to 16-bit SDRAM memory. Due to width mismatch, each AXI read request involves two access to the SDRAM memory. My problem is that on each AXI access, I receive 32-bits word consisting of two identical 16-bit sub-words. I believe there is a bug related to the za_valid signal of the automatically generated sdram_emif module, which seems to be asserted one clock cycle too late:

In the enclosed screenshot from the SignalTap tool, one can see in the bottom, that first valid data word ('h5a5a) on za_data bus is missed, and the za_valid spawns through two clock cycles of the second word ('ha5a5) eventually leading to a fake word on the AXI bus.

[BoonT_Intel]

Dear Sir,

Which SDRAM protocol that you are using (DDR3, DDR4)? As per my understanding, the EMIF IP used in Intel FPGA are access using Avalon-MM bridge instead of AXI bridge. Can you also signaltap the Avalon-MM bridge and see if the issue really occur from the IP AMM port?

[BoonT_Intel]

Also see if this statement is match with your observation:

https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/manual/mnl_avalon_spec.pdf#page=36

If the master data width is wider than the slave data width, words in the master address space map to multiple locations in the slave address space. For example, a 32-bit master read from a 16-bit slave results in two read transfers on the slave side. The reads are to consecutive addresses.

[adrianf0]

Dear BCT_Intel,

It's a regular Synchronous DRAM (IS42VM16160K-75BLI). However, I enclosed the full project to my original post, so you can easily check the configuration and the Avalon-MM to AXI bridge connection. Moreover, I pointed directly the cause of the problem already. Unfortunately, I can't invest more time in debugging the bug (apparently) of the Intel IP core. I expect it will be fixed soon as it's critical in my project.

[BoonT_Intel]

Due to US and other countries’ export regulations, any questions, technical support, services, feedback, guidance, optimization, training, assistance, or other work performed by Intel that are directed toward the incorporation and/or implementation of Intel’s product in a military, defense intelligence, nuclear/biochemical or space item may result in a defense service or the transfer of technical data and require authorization from the US or other applicable governments. For these reasons, Intel is unable to support any such requests in this forum.

[adrianf0]

@BoonT_Intel​ : I received a private message from you, advising me to contact a local distributor from whom the devices were bought. Unfortunately, they don't have a field application engineer which could support us with this case. I informed you about that by a private message asking for further support, however, I haven't received any reply in the last two weeks.

[adrianf0]

I am surprised by your reply. Why did you link me with the implementation of military, defense intelligence, nuclear/biochemical or space products? If you can't support my problem, because somebody else could misuse it, then it questions the existence of this forum at all.

Finally, what is the official channel, for clients who bought and use your devices and tools (Lite edition), debugged your core and would like to report a potential bug (pointing explicitly to the suspected signal causing the problem on top of that)?