Bug 801 - ls2/gram DDR3 controller not working on hardware
Summary: ls2/gram DDR3 controller not working on hardware
Status: RESOLVED FIXED
Alias: None
Product: Libre-SOC's first SoC
Classification: Unclassified
Component: Source Code (show other bugs)
Version: unspecified
Hardware: Other Other
: --- critical
Assignee: Luke Kenneth Casson Leighton
URL:
Depends on:
Blocks: 813
  Show dependency treegraph
 
Reported: 2022-04-07 23:22 BST by tpearson
Modified: 2022-07-07 19:33 BST (History)
1 user (show)

See Also:
NLnet milestone: NLNet.2019.10.043.Wishbone
total budget (EUR) for completion of task and all subtasks: 6000
budget (EUR) for this task, excluding subtasks' budget: 6000
parent task for budget allocation: 249
child tasks for budget allocation:
The table of payments (in EUR) for this task; TOML format:
tpearson={amount=6000,submitted=2022-04-09,paid=2022-06-21}


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description tpearson 2022-04-07 23:22:46 BST
On at least ECP5 hardware the ls2/gram DDR3 controller does not function.
Comment 1 tpearson 2022-04-07 23:28:09 BST
This has been traced to multiple defects in the gram HDL along with the ls2 coldboot (libgram) firmware and pin setup.

DDR3 is basically functional on the Raptor custom Versa 85 board (with some caveats, see below) as of the following commits:

https://gitlab.com/nmigen/nmigen-boards/-/merge_requests/2

https://git.libre-soc.org/?p=gram.git;a=commit;h=ffdcef6b591e73932a97278e011834c8303731cc

https://git.libre-soc.org/?p=ls2.git;a=commit;h=8b208495536795b629c72a3d06ef3cd77aab73a0

Status:

memtest passes overall, but sometimes the FPGA/DDR3 PLLs/DLLs will fail to lock correctly after programming (noted as significant DQS burst detect shifts during read levelling).  This causes memtest to immediately fail with a slew of errors, but repeatedly reprogramming the same bitstream will eventually allow the DDR3 to come up again with no errors at all during either memtest or further operations.

My best guess is that the above behavior is due to a questionable DLL lock inside the DDR3 device, and is likely the result of running the device way outside of its specifications (50MHz clock vs. a minimum of 100MHz per the specifications).  Efforts to run the DDR3 device at 100MHz and the core at a lower clock frequency will be moved to a new bug report.