Fullscreen with series of nops -> memory access saturation

[zerkman]

This problem is the worst case scenario for memory access management. Some fullscreen codes are only running nop instructions, meaning we are having long periods in which the CPU and the Shifter are loading data from memory at a rate of 4 bytes in 4 cycles (2 bytes for the CPU - the nop instructions, 2 bytes for the Shifter - the bitplanes to be displayed).

The specific bus management on zeST comes from the fact that the only available memory chips on cheap Zynq boards is DDR, that is shared between the CPU/PS and the FPGA/PL. All accesses are done through a shared memory controller, with significant, non-uniform latency. CPU cycles can run slower or faster, depending on if a memory access is pending or not. Memory accesses introduce some global delay (slow cycles) and the bus management tries to "catch up" with the delay by using fast cycles when possible. The bus management is explained in detail in this article.

Here since we are running fullscreen, there are not many cycles between two scanlines in which the bus management system can "catch up" with the accumulated delay, resulting in not enough cycles executed in the required time. This results in wrong video timings (longer delay between two hsyncs), and the video output does not work correctly anymore.

This problem occurs for instance on the intro of the O-Demo by Oxygene.

It may be solved by implementing a cache mechanism on DDR accesses, so most accesses will be faster, and only a small portion of them will remain long.

[zerkman]

The fullscreen part in Little -ME- Demo by Overlanders has the same problem.