Cyclone V - BlockRAM read port stops working when HPS SoC is added to the project

1

Hello,

I am working on a project where I use:

  1. 1-port (or 2-port) on-chip RAM (Block RAM) with data width 128b and size of 360960B, running at 160MHz.
  2. A process for capturing camera data (DCMI interface) running at 26.67MHz and storing 752x480 monochrome images into the BRAM (by 16px chunks, when needed) using the port A.
  3. A process for VGA output (to HDMI transceiver ADV7513 on DE10-Nano) running at 40MHz, loading the image by 16px chunks from the BRAM (when needed) using the port B.
  4. Clock 160MHz is generated by PLL from the 50MHz input clock, frequencies 40MHz (160/4) and 26.67MHz (160/6) are generated from the 160MHz using second PLL.

Everything works fine both with the built-in 1-port RAM (Altera Megafunction IP) and with custom inferred 2-port BRAM (using this VHDL code). (I don’t use Altera’s 2-port RAM because I was not able to get it working with SignalTap, which was complaining about size limit of 553 blocks.)

The SignalTap recording of the ports of the custom 2-port BRAM is in the next image:

bram_2port_withoutHPS
bram_2port_withoutHPS1832×255 55.6 KB

And the resulting image on the HDMI output looks as expected:

frame_withoutHPS
frame_withoutHPS1910×1196 229 KB

Because I would like to use also HPS, I tried to add soc_system.qip generated by the Platform Designer. I used the working DDR configuration from the GHRD, removed all GPIOs, peripherals, kept only Clock source IP component (connected to the 50MHz clock) and the HPS IP block to have a minimal configuration of the HPS.

But for some reason when the soc_system component in the top module is initialized, the BlockRAM read (dout) port starts behaving weird (even it is completely separate from the soc_system component):

bram_2port_withHPS
bram_2port_withHPS1822×247 56.4 KB

And it results in the following artifacts in the HDMI output:

frame_withHPS
frame_withHPS1910×1188 340 KB

I really don’t understand why this is happening. I tried to feed the clock source with the derived 40MHz clock (I thought it could be a timing issue) but it behaves the same. The same problem happens with the Altera’s 1-port RAM. When I comment out the system_soc component and remove the qip file from the project, it starts working correctly again…

Thanks for any suggestions on what I am doing wrong and how this can be solved.

2

Are you setting timing of the external interface to BRAM?

The bad pixels imply that it’s on one particular data or possibly address bit because of the vertical lines.

It looks to me like a setup timing is being violated. That could happen if the added logic required by the SOC is causing routing delays of your logic.

I suggest you make an sdc file and set all the timing parameters associated with BRAM interface related to off chip signals.

Usually the tool does a good job setting requirements for internal logic to internal logic, but you need to create an sdc file that sets the timing for external logic to internal logic.

I don’t know how slow it would be, but you could simulate with timing to see the violation.

3

Thanks for the response. Yesterday I have solved the issue, it was indeed caused by the SDC file. I did not know it must be added to the file list in Quartus, it is ignored by the Fitter otherwise. Also my input/output delays for the HDMI and DCMI interfaces were wrong.