MDA 70Hz RAM issues

[schlae]

MDA (70Hz VGA compatible) on some boards has issues with the attribute byte getting corrupted by the previously-read character byte. This shows up as spurious underlines, inverse video, etc on the screen. Likely this is a marginal timing issue as it works fine on some boards but not others.

[spark2k06]

I have investigated and discovered something about this issue, and that is that the final timing resulting from the build plays an important role. The most curious thing is that this final timing can be manipulated by inserting or extracting modules not required by the project.

So, for example, a build only with the modules required by the project:

yosys -p 'synth_ice40 -top mda70_top -json build/mda70_top.json' mda70_top.v mda.v crtc6845.v mda_vgaport.v mda_vram.v mda_attrib.v mda_sequencer.v mda_pixel.v -E mda70_top.d

Total path delay: 12.21 ns (81.89 MHz)

This timing seems that it would not be compatible with any board, causing artifacts.

Now, with the build used by the Makefile, based on the latest changes that would affect only the CGA project:

yosys -p 'synth_ice40 -top mda70_top -json build/mda70_top.json' mda70_top.v mda_top.v mda.v crtc6845.v mda_vgaport.v mda_vram.v mda_attrib.v mda_sequencer.v mda_pixel.v cga_top.v cga.v cga_vgaport.v cga_sequencer.v cga_pixel.v cga_attrib.v cga_vram.v cga_composite.v cga_scandoubler.v -E mda70_top.d

Total path delay: 12.66 ns (78.98 MHz)

This timing is what causes underlines to occur on some boards, and only show some artifacts. However, if we repeat the command but with the old CGA project files, we get the following result:

Total path delay: 13.12 ns (76.24 MHz)

Now yes, this timing could be friendlier with all boards, at least it is with mine:

And the most curious thing is that adding repeated modules does not always cause a lower timing, sometimes the opposite happens ... in the tests I have done, I have obtained different timings:

In conclusion, timings higher than 80 Mhz could affect any board, and the main symptom is artifacts, which would increase as the frequency is higher. On the other hand, there is a point at which, the timings could be stable on any board, 77Mhz and lower.

[schlae]

Thanks for going through this, it's a good clue about the root cause of the problem, which is probably the bus timing of the SRAM chip. The fetching of the character and attribute byte are in successive cycles, but perhaps there's not enough time allowed for the address to stabilize before the byte gets latched.

[spark2k06]

With the latest version of yosys (0.11+1) this issue is also corrected, without the need to make changes to the code.