litedram VS litepcie

I could be wrong, but I don't think the LiteX DRAM PHY is using the UG586 block. Here's the Litex Series 7 DRAM PHY source code - it appears to be hardcoding the PHY logic. The Lattice ECP5 code in that directory does the same thing.

Try https://github.com/enjoy-digital/litedram with a RAW or FIFO interface. It is in Migen, a python DSL HDL, but you could just use the output.

You could try to implement a PCIe root complex for FOSS SoCs, connecting to e.g. Wishbone as the main bus. There's already some DDR3 controller (or this one) and USB Host controller out there, and even device-side PCIe, but no FOSS host-side PCIe that I know of. Probably quite a difficult job though, even sticking to the lower-speed PCIe 1.

So for instance (and AFAI understand...) the DDR2 sdram controller uses a generic PHY (https://github.com/enjoy-digital/litedram/blob/master/litedram/phy/gensdrphy.py) , but the DDR3 one has to talk to some vendor-specific PHY (e.g. https://github.com/enjoy-digital/litedram/blob/master/litedram/phy/s7ddrphy.py ). The controller itself is vendor-agnostic (https://github.com/enjoy-digital/litedram/blob/master/litedram/core/controller.py). On Xilinx FPGA it doesn't rely on MIG at all.

Hi folks. :)

I'm so glad that my hit-and-run post has been so useful. After seeing Fabien's blog post I did a quick search and it turns out that the solution has spread fairly broadly to other forums. My choice of 0x33 was arbitrary so makes a nice canary for seeing it spread out.

My use case was (and remains) having a Xilinx Artix 7 FPGA in an external Thunderbolt 3 enclosure for testing the development of DSP accelerators using open source tooling. I didn't want to have the FPGA board inside the PC to be able to swap it to my laptop easily, because it produces a lot of heat, and so when I misused the PCIe soft core (litePCIe: https://github.com/enjoy-digital/litepcie/) it doesn't take down the OS. Being able to reload the FPGA and effectively hotplug the device has been very helpful.

Since I knew my issue was around hotplugging I searched for information around PCIe hotplugging and I think (it was two years ago...) that I found the answer from one of these two threads. Both mention the option of reserving PCIe addresses for hotplug busses as a workaround, and a workaround was all I needed.

https://www.spinics.net/lists/linux-pci/msg64841.html

https://review.coreboot.org/c/coreboot/+/35946

dmesg and the various kernel logs are my first stop for any odd behavior on Linux. Especially with any state change to a device (plugging in, turning on, removing, reconfiguring etc) the kernel logs tend to give invaluable info.

I had already been looking at eGPU forums to choose the Thunderbolt 3 enclosure (ended up with the ORI-SCM2T3-G40-GY) and there were various discussions of hotplugging issues there, but I don't think I found the specific kernel options to fix it there.

Check out this docs page for the kernel parameters:

You could try to implement a PCIe root complex for FOSS SoCs, connecting to e.g. Wishbone as the main bus. There's already some DDR3 controller (or this one) and USB Host controller out there, and even device-side PCIe, but no FOSS host-side PCIe that I know of. Probably quite a difficult job though, even sticking to the lower-speed PCIe 1.