Refactor the core to use SDRAM instead of HyperRAM (R6 machines only)

[sy2002]

The R6 board that is in the hands of the 2024 MEGA65 customers (aka 2024 batch) behaves differently than the R5 board. While the M2M HyperRAM implementation was rock solid on R3/R3A, R4 and R5, it became unstable on R6 leading to HyperRAM lock-ups that manifest themselves for example as HDMI stopping to work (as ASCAL needs HyperRAM). The problem would also be visible when one uses the REU or CRTs.

Here is a high level problem description that I sent to Trenz:

Von: <sy2002, E-MAIL REDACTED>
Betreff: MEGA65 R6 HyperRAM vs. R5?
Datum: 14. Juni 2024 um 20:09:17 MESZ
An: <TRENZ-TEAM, E-MAILS REDACTED>
Kopie: <MEGA-65-TEAM, EMAILS-REDACTED>

Hello Team Trenz,

The following is applicable only to the C64 core on the MEGA65 and to all cores that are using the "MiSTer2MEGA65" framework. The problem is not affecting the MEGA65 core as it runs the HyperRAM with slower speeds: We are a heavy-user/power-user of the HyperRAM and run it with 100 MHz.

Here is my question: Did anything change regarding HyperRAM between the R5 board and the R6 board such as:

* Chip revision (or maybe mixed chip revisions on R6? certain amount of R6 with revsion XYZ and certain amount with abc)? I am asking this because not all users are seeing this problem.
* Routing / conductor path, etc?
* Anything else?

Why I am asking: We are currently debugging a phenomenon that only occurs on R6 boards on not on R5 boards. The phenomenon has something to do with our HDMI scaler called "ASCAL" which uses HyperRAM heavily. 

Michael Jørgensen had invested an unreal amount of time in the last 6 months to make the HyperRAM controller rock solid on R3/R3A/R4/R5 boards which also included very diligent clock domain crossing, clever and intentional signal sampling and of course constraining the signal paths correctly (as seen here: https://github.com/MJoergen/C64MEGA65/blob/V5.1-release/M2M/common.xdc#L49). The M2M framework has been optimized for IS66WVH8M8DBLL-100B1LI.

We are currently contemplating multiple solutions / workarounds etc. For example just sampling the HyperRAM's RWDS one clock cylcle later (as shown here: https://github.com/MJoergen/C64MEGA65/commit/a2279443257d5c937a7353dc636b4b5079f1545d) reduced the frequency of the bug. But it did not resolve it. But this also shows: OK, we are on to something here, because as said: No bugs on R5 but on R6 we run into challenges. If the chip revisions are guaranteed to be identical between all R5 boards and all R6 boards/batches, then maybe the routing/conductor path changed on R6 or or things that affect the above-mentioned constraints might be helpful hints.

Any ideas are welcome.

Best,
  <NAME REDACTED>

After a discussion, @MJoergen and I decided this road ahead, which will also impact the M2M framework:

@paich64: FYI so that you have this issue on your radar. I will suggest tests for you as soon as time is ripe.

[AnttiLukats]

Please consider adding BUFR on RWDS strobe signal, it should fix the HyperRAM issue on R6 and be safe to use on other rev also,

[sy2002]

@AnttiLukats Thank you for your support! We are now testing your solution proposal with a "Release Candidate 3A", here is the commit: ce927cb

@paich64 I will approach you via Skype on this to please do some very thorough testing.

[paich64]

@sy2002 ***@***.***> testing is in progress ;) Le ven. 21 juin 2024 à 12:18, sy2002 ***@***.***> a écrit :

…

@AnttiLukats <https://github.com/AnttiLukats> Thank you for your support! We are now testing your solution proposal with a "Release Candidate 3A", here is the commit: ce927cb <ce927cb> @paich64 <https://github.com/paich64> I will approach you via Skype on this to please do some very thorough testing. — Reply to this email directly, view it on GitHub <#141 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABROXOCLMGZWAMCIBDOPCVLZIP4XHAVCNFSM6AAAAABJL6SL2SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBSGQ3DEMBSHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>