Frame Buffer IP stops output during first frame. No EOP

[Altera_Forum]

Hi! 

 I haven't found any posts describing my problem, which is :   I have a Frame Buffer IP. In QSYS, it's configured to support maximum 1280x720 pixels. I actually transmit 640x480 pixels for simulation purposes. Each pixel is 24 bits.  - During simulation, I can see all pixels arriving OK into the Av-ST din port.  - They are all stored OK in external RAM model via the write_master port, and  - they are all read OK from the external RAM model.   problem :  All pixels are output OK, except that the last three pixels are never sent. No EOP is transmitted. The Frame Buffer doesn't ever continue, even though more frames are incoming.   - I have verified that the Frame Buffer receive a correct control packet before this frame. - I can see that there is no backpressure problem, the dout_ready is always high. - I can see that the last 3 pixels are read out from memory. They have the values 0x000BFE, 0x000BFF and 0x000C00.   Has anyone else found that their Frame buffer IP stops before finishing the first frame?   Best regards,  Steffen

[Altera_Forum]

Some more observations. Possibly the solution:  

 I tried forcing the read_master_av_readdatavalid signal to '1', emulating that the RAM feeds more data to the Frame Buffer reader process. (Although it doesn't request any more data). With this readvalid kept high, the frame buffer outputs 67 more pixels, and then finally asserts EndOfPacket!  I examined the read_master interface some more, and found that at the beginning of the frame, the second burst request towards the RAM appears before the first read burst is done. I guess that the Frame buffer is expecting the RAM to deliver this data, but my home-made RAM model doesn't buffer multiple read burst requests. I guess the interface requires it, although it seems like a strange feature in a protocol...?   The attachement shows the two burst requests towards my RAM model. These requests are generated by Frame Buffer IP and some glue logic in .vho files made by QSYS.

[Altera_Forum]

OK, I can confirm that the avalon-MM interface requires the RAM model to support pipelined read transfers. (Chapter 3.5.4.2 in Avalon Interface Specifications)