litex-hub / litehyperbus Goto Github PK

Please visit https://github.com/enjoy-digital/litex/wiki/Feedback-Contribution-Support.

The Lattice CrossLink-NX VIP board has two S27KS0641DPBHI020 HyperRAM chips on it; it would be nice to support them.

It looks like, by coincidence or purpose, one of the two chips is wired in such a way that DQS primitives could be used to get a legal 4:1 (or 8:1) bidirectional gearing.

Otherwise, for Radiant support, the PHY can only be 2:1 as, without using DQS, only the simple DDR primitives can be used on bidirectional pins (based on the bitdocs I have so far, it is similar to ECP5 so once nextpnr is up and running that would support bidirectional 4:1/8:1.)

Hi everyone!
I am trying to use litehyperbus to access the HyperRAM of the ecp5-mini board. I successfully implemented the board in Litex ecosystem, creating target and platform files, to provide the BaseSOC class and I am able to use base things of Litex.
Unfortunately, trying to add the onboard HyperRAM and enabling the required submodule, the mem_test always fails.
I am struggling with that from months but I don't have the necessary expertise in Litex to correctly debug the issue.

This is the result of a mem_test I tried to execute:

litex> mem_test 0x4000000 1000
Memtest at 0x00000g (08B)...
  Write: 0x0g-0x0g 08B   
   Read: 0x0g-0x0g 08B   
  bus errors:  00/00
  addr errors: 0a/0a
  data errors: 0a/0a
Memtest KO

The HyperRAM is a 1.8v Cypress S27KS0641. As per datasheet, it supports only differential clocking when using 1.8v part.
As the clock pin is not on a left nor a right IO, I have to use pseudo-differential output of the ECP5 LVCMOS18D and that should be easy because the two clock pins are on a pseudo-differential pair.

Unfortunately I do not have the required instruments to debug the hardware (no oscilloscope nor a decent logic analyzer), so I am blaming my wrong implementation for now. I have also taken reference from some other implementations of HyperRAM with ECP5 but I haven't noticed significant differences beside the IO side where the memory is connected, so this is why I am assuming that the hardware is correct.

This is the schematic of the HyperRAM part:

Some implementation bits of the board in Litex ecosystem follows:

Platform pads of HyperRAM:

    # HyperRAM
    ("hyperram", 0,
        Subsignal("clk",    Pins("A2"), IOStandard("LVCMOS18D"), Misc("SLEWRATE=FAST")),
        # Subsignal("clk_n",  Pins("B3"), IOStandard("LVCMOS18")),
        Subsignal("rst_n",  Pins("B4"), IOStandard("LVCMOS18")),
        Subsignal("dq",     Pins("A6 C4 A7 B7 A8 B6 D4 A5"), IOStandard("LVCMOS18")),
        Subsignal("cs_n",   Pins("A3"), IOStandard("LVCMOS18")),
        Subsignal("rwds",   Pins("A4"), IOStandard("LVCMOS18")),
    ),

Submodule instantiation:

        self.submodules.hyperram  = HyperRAM(platform.request("hyperram"))
        self.add_wb_slave(self.mem_map["hyperram"], self.hyperram.bus)
        self.add_memory_region("hyperram", self.mem_map["hyperram"], 8*1024*1024) #8MB HyperRAM

Memory map with hyperram entry:

    mem_map = {
        "hyperram": 0x04000000,
    }

What I am doing wrong? Can you suggest me how to investigate further that issue?
I have no idea on how to identify the root cause of the issue as now, but maybe someone can point me toward the right way.

Thank you so much for the help in advance!