I am using the "mem_if_ddr3_emif_0 - DDR3 SDRAM Controller with UniPHY Intel FPGA IP" to acces the DDR3 external memory. In Platform Designer (QSys), Quartus 18.1.
I have my own readmaster connected to one of the IP's avalon channel. In the master I have signals for the simple single read acces (address, data, waitreq, read).
However the IP's avalon slave channels have also the burst signals (burstCount, readDataValid, beginBurstTransfer) which I didnt connect with my simple master.
I'm trying to read in the simple waitReq mode, but it seems to act like the burst mode anyway (on SignalTap)... So is it a mistake to not connect the burst signals, when the slave has them? I supposed the slave IP or rather QSys would understand that when I dont connect them.
You don't need to add them to your master if you don't want/need to do burst accesses. However, the interconnect will get generated automatically with logic to handle this burst signaling.
Well, I thought just so, but when I connect just: read, readData, waitRequest and address, the waitRequest goes up with read and never ends. However, if I hold read just for one cycle ignoring the waitRequest, the waitRequest then goes down together with read and the data appears a few cycles after - just like pipeline reading... (and my master didnt have readDataValid signal here)
Slave is just that one DDR3 SDRAM Controller and there are 6 avalon channels. 3 masters to write data, 1 read/write for pci_debug from ARM MCU and 1 for DMA also for the ARM MCU.
It's very likely that one of those other interfaces is holding onto the DDR interface (not clear from your response if any other master is connected to this memory), preventing your master from having access. Can you temporarily disable other components or increase the arbitration priority for this master's access to the memory?