litepcie
litedram
litepcie | litedram | |
---|---|---|
2 | 6 | |
436 | 359 | |
- | - | |
8.5 | 6.4 | |
13 days ago | about 1 month ago | |
Python | Python | |
GNU General Public License v3.0 or later | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
litepcie
-
A Linux Evening
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:
-
Suggest advance project ideas
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.
litedram
-
How Much Would It Cost For A Truly Open Source RISC-V SOC?
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.
-
I am trying to avoid AXI Bus for DDR3 access on Arty A7
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.
- LiteDRAM – A fully open-source memory controller targeting LPDDR4/5 for FPGA
-
Suggest advance project ideas
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.
-
How many more years until we have a completely open source RISC-V SOC?
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.
What are some alternatives?
SpinalHDL - Scala based HDL
litex - Build your hardware, easily!
SaxonSoc - SoC based on VexRiscv and ICE40 UP5K
cva6 - The CORE-V CVA6 is an Application class 6-stage RISC-V CPU capable of booting Linux
VexRiscv - A FPGA friendly 32 bit RISC-V CPU implementation
OpenSERDES - Digitally synthesizable architecture for SerDes using Skywater Open PDK 130 nm technology.