Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Addon in validation] Add Ram-Pak support #483

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

whitequark
Copy link
Member

@whitequark whitequark commented Oct 29, 2023

WIP: This PR will remain a draft until 1bitSquared finalizes a production design for Ram-Pak.

Ram-Pak schematic: https://github.com/esden/glasgow-addons/blob/master/hardware/ram-pak/ram-pak-sch.pdf

Current status of the controller gateware:

  • PHY that uses DDR output registers to phase-shift clock
  • sequencer that shifts command/address and controls flow of data
  • manual testing of all kinds of register writes
  • manual testing of small memory writes
  • large scale testing by writing the entire bee movie script into the RAM 48 times and then reading it back
  • glasgow run selftest addon-ram-pak
  • gateware.hyperram.Arbiter
    • performs arbitrage of a sequencer between several controllers
    • switches between controllers when one sends o.last
    • also switches between controllers and sends i.last prematurely to ensure fairness
  • gateware.hyperram.Reader
    • convert address input stream into data output stream
    • reading from consecutive addresses performs a burst
    • prefetches one address and sends o.last if there is a jump
    • reacts to i.last (premature or not) by restarting command/address
  • gateware.hyperram.Writer
    • same thing but for address, data tuples
  • gateware.hyperram.Queue
    • first-in first-out queue
    • ~same interface as amaranth.lib.fifo.SyncFIFOBuffered
    • very efficient for bursts, less efficient for one-off fetches

Details of the above aren't really clear. Fairness and correct handling of bursts seems difficult.

@whitequark whitequark requested a review from esden October 29, 2023 16:27
@whitequark whitequark changed the title [Draft; Addon in development] Add Ram-Pak support [Addon in development] Add Ram-Pak support Oct 29, 2023
@whitequark whitequark force-pushed the ram-pak branch 2 times, most recently from 2ca535d to 07029c4 Compare October 29, 2023 20:27
@whitequark whitequark force-pushed the ram-pak branch 3 times, most recently from 8889903 to 334cc33 Compare March 28, 2024 01:12
whitequark and others added 2 commits March 28, 2024 03:07
Verified on hardware for both memory chips.
@whitequark whitequark mentioned this pull request Apr 20, 2024
@whitequark whitequark changed the title [Addon in development] Add Ram-Pak support [Addon in validation] Add Ram-Pak support Apr 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant