Import Libre-SOC/Raptor Computing System patches #55
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
to see what is going on
add some more names on dfi.Interface instances, again to see what is going on in gtkwave traces of SocTest nmigen simulation
control pins have to be requested "xdr:4"
the burstdet and read-delay get read and written, do nothing, but it is better than having to modify the dram firmware
…neral. the icarus verilog simulation now passes where previously it did not
update icarus simulation to match, and rename dfi.Interface reset signal to reset_n
has to have a minor workaround to adjust for DFI Interface being named "cs_n" but nmigen-boards convention being "cs"
add ras.reset=1
* use MT4164M16 instead of MT41256M16 * add a Chip-Select line (dram_cs_n) which is currently inverted * reduce the number of address lines in the simulated platform
same frequency as the main one, for now
Starting to get (corrupt) data out of the memory...
UART bridge now gives a valid memtest
Memtest pass using external UART bridge
phy/ecp5ddrphy: simplify using new get_sys_phase.
The rank decoder inversion was incorrectly removed in commit 03e79da Tested to give valid memtest output over UART bridge
Swap DELAYF for DELAYG on DQ lines
This reverts commit 11d7297. Inadvertently added debug garbage in this commit.
driving the 4x from dramsync2x, but from sync2x instead.
which is completely wrong when trying to do asynchronous DRAM PHY
for when synchronous is done (the default right now) this requires a matching
drs = DomainRenamer({"sync": "dramsync",
"sync2x": "dramsync2x"})
this had to be done because otherwise the IOPads are unstable. next experiment is to hook ResetSignal(dramsync) with the firmware-driven reset, which should allow the IOpads - and DQS - to fully stabilise (oh, and also allow retries on setting them up)
The only difference was a different location of the ECP5 model files and the use of python3. Make it so that both locations work, and use python3 exclusively.
They were swapped, at some point, but simulation was not kept in sync.
It seems that IcarusECPIX5Platform does handle PinsN correctly.
The headless examples do not use an embedded CPU. Instead, the host computer commands the Gram controller via a Wishbone-UART bridge.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Some code introduced here is tainted by LGPLv2. We should remove it before merging.