Forum Discussion
Hi,
I am referring to DE10_NANO_SoC_GHRD from the DE10-Nano_v.1.3.8_HWrevC_SystemCD. To be specific I took the important settings and the pin assignments from the GHRD project to my own project.
I currently use the HPS only for camera initialization over I2C (of course this could be done in the fabric directly as I do it for the ADV7513 chip on-board). But I am planning to use the HPS to load camera recordings from the SD card to the DDR memory and load it to the BRAM from there instead of using the DCMI interface when needed (possibly using the DMA controller).
In the last experiment I used Altera's 1-port Megafunction RAM IP (entity bram0_128) with a process splitting the 1 RW port to separate read and write ports and remembering pending reads/writes. I have managed to record the HDMI output together with SignalTap (triggered on read request): here is the video with the HPS enabled and here is the video without the HPS (soc_system commented out and qip removed from the project files). I used button to increment additional hold cycles (cycles when the port splitting process waits until READ_DONE and WRITE_DONE are set), in the video there is also MEM_STATE (0=idle,1=reading,2=reading_end,3=writing) of that process, bram0_128 signals and the splitted read (running at 40MHz) and write (running at 26.67MHz) signals. Clearly there must be always at least 1 hold cycle.
I can send you the current version of the Quartus project, but without the camera board you probably won't be able to reproduce the results. Also, when the DCMI process is commented out and the VGA process reads static content of the 1-port memory (preloaded with single frame from MIF) then the problem disappears (with HPS enabled). Not sure why.
Thanks for your support!
EDIT: For completeness here is a video with 2-port BRAM (port A used for writing used by DCMI process with WREN always high), trigger at write address = 0001, without RDEN (always 1).
EDIT 2: There must be something terribly wrong with the HPS or with the project settings. The MEM_STATE signal defined as 2-bit STD_LOGIC_VECTOR representing all 4 possible states of BRAM accessing process sometimes unexpectedly changes to wrong state. When I used states defined as TYPE state IS (S0, S1, S2, S3) which are compiled into 4 STD_LOGIC wires and there should always be 1 of the wires active at one moment, then with the system_soc active in the project all of them suddenly were 0 from one point (so it was impossible to handle that state in VHDL) and the whole process stopped working..
EDIT 3: I decided to share the project here, qar file is attached.