sy2002
commented
7 months ago @MJoergen All good things come to those who wait :-) Sorry that it took me three weeks to test this! Today I did it and I did it very thoroughly. Result:
Everything works as expected
Details:
✅ I tested all resolutions of the demo core, including the new resolutions, on my HDMI monitor. ✅ While doing so, I validated, if the monitor's "diagnosis" reports back the same resolution and frequency as intended by the M2M framework ✅ The flickering phenomenon / glitch described above - which only happens in 720p @ 60 Hz - also was there in version 1.0.0 of the M2M framework, so no reason to fix anything at this moment.
I am closing this issue as "completed".
Use the demo core and test:
1) Does 800x600 work?
2) About the glitches in 720p @ 60 Hz mode:
Feedback from @MJoergen:
======
Re: glitches in the 720p @ 60 Hz mode.
The (minimum) HyperRAM bandwidth required by the ascaler can be calculated as follows:
The ascal'er first writes the entire frame (at the core frame rate), then reads the entire frame (at the HDMI output frame rate).
In the case of the democore, the frame size is 720x576x3 bytes (24 bits per pixel), i.e. 1.24 MB. This must be written 50 times a second and read 60 times a second. I.e. a total of 110 times a second. The total memory bandwidth required is therefore: 1.24 MB (50 + 60) = 137 MB/s. The total available HyperRAM bandwidth is 200 MB/s. The utilization is therefore 137/2002 = 68%.
In practice there is some overhead (the ascaler actually stores a bit more data, and there is a transaction overhead with the HyperRAM). So in practice the HyperRAM is approx 75% busy in this configuration. This is an average amount, and the HyperRAM accesses can/will/do overlap occasionally. I'm guessing this explains the glitches.
I'm adding a statistics module, that can "analyze" the HyperRAM accesses and measure the time it's busy. But what is more relevant is how much time is spent waiting to get access. Both average waiting time and maximum waiting time is of interest.
======
The major question about this glitch is: Has it always been there? I.e. even in 1.0.0. Needs to be validated on an R3 board.
Feedback @sy2002 to @MJoergen:
====
3) Re Glitch in 720p @ 60Hz Mode: OK I will put this on my list to test: If it has been always there, then there would be no need to fix it now. Might also be an interference / moiré-ish pattern due to 50Hz core interfering with 60Hz screen mode?
====