search

MJoergen / C64MEGA65

Commodore 64 core for the MEGA65 based on the MiSTer FPGA C64 core
GNU General Public License v3.0
23 stars 4 forks source link

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

Open sy2002 opened 2 weeks ago

sy2002 commented 2 weeks ago

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:

grafik

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

AnttiLukats commented 2 weeks ago

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 commented 2 weeks ago

@AnttiLukats Thank you for your support! We are now testing your solution proposal with a "Release Candidate 3A", here is the commit: https://github.com/MJoergen/C64MEGA65/commit/ce927cb387150162837e71112ffe995fd870a561

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

paich64 commented 2 weeks ago

@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 https://github.com/MJoergen/C64MEGA65/commit/ce927cb387150162837e71112ffe995fd870a561

@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 https://github.com/MJoergen/C64MEGA65/issues/141#issuecomment-2182462028, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABROXOCLMGZWAMCIBDOPCVLZIP4XHAVCNFSM6AAAAABJL6SL2SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBSGQ3DEMBSHA . You are receiving this because you were mentioned.Message ID: @.***>