Add support for Etron RPC DRAM

[jedrzejboczar]

We should be able to add support for RPC DRAM in LiteDRAM.

RPC DRAM reduces DDR3 pin count by removing all the command/address lines, data mask and CKE, ODT pins. It adds a single serial STB pin. Commands are transfered on data pins (CD) at the beginning of a transaction and then STB is used. Both CD and STB are DDR.

Here on the last page is a nice depiction of the RPC DRAM operation.

We should probably be able to support RPC DRAM without modifying the controller and just do the adaptation in PHY. Perhaps it would be good to split the PHY into DFI->RPC signals adapter and the rest of the PHY, then we could reuse the adapter. We could then easily test the adapter in simulation.

The command encoding seems to be different depending on whether we send the command on CD pins or on STB. CD uses 32-bits for encoding (DDR 16-bit) and STB uses 16-bits (8 clocks, DDR 1-bit).

To start simple, it would probably be the easiest to ignore the STB pin and transfer all the commands using the CD. If I am not missing something, this approach should work just fine. We would increase column-to-column latency to ensure we always get the commands when the transfer has already been finished. And maybe just add "auto-precharge" by sending precharge on STB.

Later, after verifying that it works we could decrease the latency, and add the logic that would select where to output the command (CD/STB) depending on transfer state. This would probably require some additional latency to decide if "Toggle RW" is needed.

RPC DRAM requires BL=16 with 16-bit CD, so we would probably use dfi.Interface(databits=4*databits, nphases=4, ...) for 256-bit alignment. I would probably first start implementing the DFI->RPC pins adapter part.

Do you think this would be a good approach? @enjoy-digital

[daveshah1]

This would be very nice. Do you know of any available RPC hardware yet?

[jedrzejboczar]

As far as I know there are no official boards available yet, unfortunately.

[enjoy-digital]

Thanks @jedrzejboczar, i will have a closer look in the next days, but the approach seems fine. We should indeed avoid changes on the controller itself if possible (or at least minimize them) and doing a DFI -> RPC adapter is indeed a good idea, so you can go in this direction.

[rdcrisp]

the parallel command set has the full set of commands for the DRAM including the mode register set. The Serial Commands are the ones needed to manage rows and columns and refresh & read/write toggle primarily.

I was thinking you could make a queue of metacommands off of the DFI traffic to send to the DRAM and would have a multiplexer in the path that sends the metacommand to either the parallel or serial command formatters before transmitting to DRAM.

[jedrzejboczar]

Yes, this sounds like a good approach. I'm currently working on a simplified version with parallel-only commands and single-WORD reads/writes, that uses STB only to start a parallel command and during power-up reset. The current development version can be found here in etronrpcphy.py with an implementation for Artix7 here in s7rpcphy.py. Later, when we get the simple version working on hardware, we should do as you suggested, but it may be a bit problematic to get all the timings right.

[WaymanH]

This is WM from Etron Tech. We are trying to install RPC Code in LiteX on an Xilinx ARTY 35T board. We follow the installation guide but encounter error at the last step (shown in red). Could you kindly help to provide recommendation. Thanks in advance.

Below are the procedure we followed and the error happened on the last step.

1. Install Python 3.6+ and FPGA vendor's development tools and/or Verilator.
2. Install Migen/LiteX and the LiteX's cores: $ wget https://raw.githubusercontent.com/enjoy-digital/litex/master/litex_setup.py $ chmod +x litex_setup.py $ ./litex_setup.py --init --install --user (--user to install to user directory) Later, if you need to update all repositories: $ ./litex_setup.py --update Release tag can also be specified to update/install specific release of LiteX, ex: $ ./litex_setup.py --tag=2022.04 --update Note: On MacOS, make sure you have HomeBrew installed. Then do, brew install wget. Note: On Windows, make sure you have make and/or GnuWin installed and it's possible you'll have to set SHELL environment variable to SHELL=cmd.exe.
3. Install a RISC-V toolchain (Only if you want to test/create a SoC with a CPU): $ pip3 install meson $ ./litex_setup.py --gcc=riscv
4. Build the target of your board...: Go to litex-boards/litex_boards/targets and execute the target you want to build.
5. ... and/or install Verilator and test LiteX directly on your computer without any FPGA board:

On Linux (Ubuntu): $ sudo apt install libevent-dev libjson-c-dev verilator $ litex_sim --cpu-type=vexriscv

litex_sim_error.log

[jedrzejboczar]

@WaymanH I'm not working on this project anymore and this response is probably too late, but anyway: judging from the log error as: unrecognized option '--gdwarf-5' it's probably an old version of gcc toolchain, or specifically as. Just tried to follow the steps on Ubuntu 22.04 and I didn't get the error, so you should try to upgrade your toolchain version. For reference, here are the versions I used:

# cc --version
cc (Ubuntu 11.2.0-19ubuntu1) 11.2.0
# as --version
GNU assembler (GNU Binutils for Ubuntu) 2.38