LiteX is a Migen/MiSoC based Core/SoC builder that provides the infrastructure to easily create Cores/SoCs (with or without CPU).

Related tags


                          Copyright 2012-2020 / Enjoy-Digital


Welcome to LiteX!

LiteX is a Migen/MiSoC based Core/SoC builder that provides the infrastructure to easily create Cores/SoCs (with or without CPU). The common components of a SoC are provided directly: Buses and Streams (Wishbone, AXI, Avalon-ST), Interconnect, Common cores (RAM, ROM, Timer, UART, etc...), CPU wrappers/integration, etc... and SoC creation capabilities can be greatly extended with the ecosystem of LiteX cores (DRAM, PCIe, Ethernet, SATA, etc...) that can be integrated/simulated/build easily with LiteX. It also provides build backends for open-source and vendors toolchains.

Think of Migen as a toolbox to create FPGA designs in Python and LiteX as a SoC builder to create/develop/debug FPGA SoCs in Python.

Want to get started and/or looking for documentation? Make sure to visit the Wiki!

A question or want to get in touch? Our IRC channel is #litex at

Typical LiteX design flow:

                                      |FPGA toolchains|
                                           |     |
                       +-------+        |           |
                       | Migen +-------->           |
                       +-------+        |           |        Your design
                                        |   LiteX   +---> ready to be used!
                                        |           |
              +----------------------+  |           |
              |LiteX Cores Ecosystem +-->           |
              +----------------------+  +-^-------^-+
               (Eth, SATA, DRAM, USB,     |       |
                PCIe, Video, etc...)      +       +
                                         board   target
                                         file    file

LiteX already supports various softcores CPUs: VexRiscv, Rocket, LM32, Mor1kx, PicoRV32, BlackParrot and is compatible with the LiteX's Cores Ecosystem:

Name Build Status Description
LiteX-Boards Boards support
LiteEth Ethernet
LiteSDCard SD card
LiteICLink Inter-Chip communication
LiteVideo VGA, DVI, HDMI
LiteScope Logic analyzer

By combining LiteX with the ecosystem of cores, creating complex SoCs becomes easier than with traditional tools while providing better portability and flexibility. Here are some projects created recently with the tools:

A Multi-core Linux Capable SoC based on VexRiscv-SMP CPU, LiteDRAM, LiteSATA and integrated with LiteX: For more info, have a look at Linux-on-LiteX-Vexriscv project and try running Linux on your FPGA board!

A custom PCIe SDI Capture/Playback board built around LitePCIe and integrated with LiteX, allowing full control of the SDI flow and very low latency. To discover more products/projects built with LiteX, visit the projects page on the Wiki.

Papers, Presentations, Tutorials, Links

FPGA lessons/tutorials:

Migen tutorial:

OSDA 2019 paper/slides:

Linux on LiteX-Vexriscv:

RISC-V Getting Started Guide:

LiteX vs. Vivado First Impressions:

35C3 - Snakes and Rabbits - How CCC shaped an open hardware success:

Tim has to many projects - LatchUp Edition:


litex.gen Provides specific or experimental modules to generate HDL that are not integrated in Migen. Provides tools to build FPGA bitstreams (interface to vendor toolchains) and to simulate HDL code or full SoCs.

litex.soc: Provides definitions/modules to build cores (bus, bank, flow), cores and tools to build a SoC from such cores.

Quick start guide

  1. Install Python 3.6+ and FPGA vendor's development tools and/or Verilator.
  2. Install Migen/LiteX and the LiteX's cores:
$ wget
$ chmod +x
$ ./ init install --user (--user to install to user directory)

Later, if you need to update all repositories:

$ ./ update

Note: On MacOS, make sure you have HomeBrew installed. Then do, brew install wget.

Note: On Windows, it's possible you'll have to set SHELL environment variable to SHELL=cmd.exe.

  1. Install a RISC-V toolchain (Only if you want to test/create a SoC with a CPU):
$ ./ gcc
  1. Build the target of your board...:

Go to litex-boards/litex_boards/targets and execute the target you want to build.

  1. ... 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
$ lxsim --cpu-type=vexriscv

On MacOS:

$ brew install json-c verilator libevent
$ brew cask install tuntap
$ lxsim --cpu-type=vexriscv
  1. Run a terminal program on the board's serial port at 115200 8-N-1.

You should get the BIOS prompt like the one below.


LiteX has been initially developed by EnjoyDigital to create custom SoCs/Systems for our clients (and we are still using it for that purpose :)); but over the years a friendly community has grown around LiteX and the ecosystem of cores. Feedbacks and contributions have already greatly improved the project, EnjoyDigital still leads the development but it is now a community project and collaborative projects created around/with LiteX can be found at


E-mail: [email protected]

  • Import the microwatt PowerPC core

    Import the microwatt PowerPC core

    A tiny Open POWER ISA softcore written in VHDL 2008. It aims to be simple and easy to understand.

    enhancement help-wanted 
    opened by mithro 62
  • RFC: Split LiteX CPU cores into their own Python modules

    RFC: Split LiteX CPU cores into their own Python modules

    With the increasing number of CPU cores supported by LiteX, cloning the LiteX repository means cloning a large number of submodules which can get very big.

    I think we should convert each of the supported LiteX CPUs into their own Python packages.

    litex/soc/cores/cpu becomes a "namespace module" which other Python packages can provide modules under. See

    The CPUs can be split into;

    • [ ] litex-cpu-lm32
    • [ ] litex-cpu-mor1k
    • [ ] litex-cpu-vexriscv
    • [ ] litex-cpu-blackparrot
    • [ ] litex-cpu-microwatt
    • [ ] litex-cpu-chiselwatt
    • [ ] litex-cpu-rocket
    • [ ] litex-cpu-picorv32
    • [ ] litex-cpu-minerva

    This allows projects which are only using a single CPU like VexRISCV to only pay the cost of that CPU.

    The setup process then becomes;

    git clone git+ssh://
    (cd litex; python install)
    git clone git+ssh://
    (cd litex-cpu-vexriscv; python install)

    People can also submodule the repository in using the normal method of;

    git submodule add third_party/litex git+ssh://
    (cd third_party/litex; python -e install)
    git submodule add third_party/litex-cpu-vexriscv git+ssh://
    (cd third_party/litex-cpu-vexriscv; python -e install)

    Or specify a Python requirements file using;


    We can easily set up Travis CI so that any push to the LiteX repository causes each of the CPU packages to be tested in combination with the based LiteX.

    As VexRISCV is currently the most popular CPU to use with LiteX, we could also make VexRISCV the "default" CPU that is included with LiteX by default and just move the other CPU cores into their own modules. I personally don't think we should preference VexRISCV like that, but it could be a possible compromise?


    enhancement question 
    opened by mithro 51
  • LiteX 2020 roadmap and new LiteX SoC class

    LiteX 2020 roadmap and new LiteX SoC class

    LiteX has evolved a lot and the current SoCCore, SoCSDRAM inheritated from MiSoC have evolved quite a bit in the last years and could be greatly improved now that we have a better idea of the SoCs we want to be able build with LiteX and the features we want to support.

    A new refreshed LiteXSoC class could be created and could be flexible enough to: In the short term:

    • [ ] allow SoCCore/SoCSDRAM/SoCZynq to inherit from it for retro-compatibility with existing designs.
    • [x] support different types of main SoC bus (Wishbone, AXI, etc...) with different data-widths.
    • [x] support automatic bridging between bus types and data-width adaptation when adding a bus Master or Slave to the main bus (ex: AXI 64-bit to Wishbone 32-bit, Wishbone 32-bit to AXI 32-bit, etc...)
    • [x] support AXI-Lite ROM/SRAM/Interconnect when main bus is AXI (requires adding AXI-Lite ROM, SRAM, Interconnect components to LiteX).
    • [x] support mixed dynamic/static CSRs regions allocation (some CSR regions could be user-defined or reserved by the CPU (and then static), the others could dynamically allocated).
    • [x] support AXI-Lite to CSRs direct bridging when the main bus is AXI. (we are currently doing AXI->Wishbone->CSR which is not efficient).
    • [ ] support mixed dynamic/static CSRs allocation within a CSR region. (It's currently difficult to use static CSRs regions since CSRs can move within a module when a new CSR is added).
    • [x] support mixed dynamic/static IRQs numbering (some IRQs could be user-defined or reserved by the CPU (and then static), the others could dynamically allocated).
    • [x] support mixed dynamic/static Memory regions allocation (some Memory regions could be user-defined or reserved by the CPU (and then static), the others could dynamically allocated).
    • [x] support properties on Memory regions: IO/Cached/Linker, allow the CPU (or main Master of the bus) to define the IO/Cached regions and checks regions properties when adding a new peripheral to the memory map.
    • [ ] ease multiple instances of a similar component (SDRAM, Ethernet, etc...): It's already possible, but requires workarounds.
    • [x] ease instance of standard SoC components/cores: we currently have redundancies in the targets when adding an Ethernet, SDRAM core and as prototyped in Linux-on-LiteX-Vexriscv ( we could probably have add_ethernet, add_sdram, ... methods to easily add standard components. With only a few parameters, the method would be able to find the right core/primitive/implementation to use and then simplify integration and reduce redundancy.
    • [ ] improve the .csv/.json exports of the SoC informations to allow external tools to easily reuse this.

    In the long term:

    • [x] add logging of all the steps of the SoC elaboration to ease SoC creation/debug. (ex: information on the CPU (type, data width, parameters), main bus (type, data width), about all the automatic operations happening during the SoC creation (bridge additions, data-width adaptation, automatic allocation of CSR regions/IRQ/Memory regions, PLL parameters computations, etc... so that the user can be aware of this more easily: looking at the generated csr.h/soc.v or just receive an error message is often to limited to really understand what is going on).
    • [ ] add AMP/SMP support for multi-CPU.
    • [ ] add multi-SoC support with NoC interconnection between SoCs.
    • etc...

    Also, even if using Migen vs nMigen is not really limiting LiteX for now, we should see if it's possible to switch easily between Migen and nMigen compat mode to generate the verilog (would allow testing progressively nMigen while still allowing Migen use) and then see if it's interesting to start creating new cores in nMigen or/and adapt existing ones.

    I'll start prototyping this in the next weeks/months and that would be great to discuss or/and have feedback/ideas from the main contributors/users: @mithro, @xobs, @gsomlo, @mateusz-holenko, @jersey99, @bunnie, @gregdavill or anyone having ideas on the direction LiteX should take.

    Edit: Feedbacks/Suggestions:


    • [ ] Using CSRs as a bus by themselves. We had some people wanting to put a 6502 on Fomu, and being able to use CSRs natively would be a neat trick.
    • [x] BIOS on SPI. Currently this is very clunky, as litex appears to be designed around the assumption that instruction 0 must be in a ROM somewhere in a region called "rom", and must have a program called "bios.elf". This is the case for most large FPGAs, but for smaller ICE40 boards being able to boot directly from XIP SPI would be nice.
    • [ ] Documented Caching. There appears to be a cache that we're seeing on Betrusted (L2 cache?) that we're not seeing on Fomu. As such, accesses are bursty on Betrusted but super slow on Fomu. It'd be nice to know how that's done, and how to enable it on Fomu.
    • [ ] Nicer IP Library. I'm still not sure how to handle this one. Over time, we've been building up a library of IP modules that tend to live in various repositories. These are self-contained files, usually Modules, such as a random number generator, touchpad, or RGB LED.


    • [x] it would definitely be good to have the litedram/eth init code in the same repo as the cores by putting them all in one repo or making the BIOS more modular.
    • [x] Apropos external CSR bus, it would be nice to support systems where the main processor is actually a hard core (Zynq etc) and LiteX just provides peripherals.
    opened by enjoy-digital 44
  • Litex BIOS SD Card Booting via SPI (bitbanging)

    Litex BIOS SD Card Booting via SPI (bitbanging)

    I've generated code, shown to work on a de10nano with a MiSTer SDRAM board that will load EMULATOR.BIN, IMAGE, ROOTFS~1.CPI and RV32.DTB from a SD Card connected to GPIO pins in SPI mode.

    Demonstration below:

    `--============= Console ================-- litex> gpiospisdboot SD Card via SPI Initialising Reading MBR Partition Information: Active=0x00, Type=0x06, LBAStart=0x00000800

    Read FAT16 Boot Sector Jump Code: 0xeb 0x3c 0x90 OEM Code: [mkfs.fat] Sector Size: 512 Sectors Per Cluster: 128 Reserved Sectors: 128 Number of Fats: 2 Root Dir Entries: 2048 Total Sectors Short: 0 Media Descriptor: 0xf8 Fat Size Sectors: 128 Sectors Per Track: 32 Number of Heads: 64 Hidden Sectors: 2048 Total Sectors Long: 4194304 Drive Number: 0x80 Current Head: 0x01 Boot Signature: 0x29 Volume ID: 0xebdc1fad Volume Label: [RISCV ] Volume Label: [FAT16 ] Boot Sector Signature: 0xaa55

    sdCardFatTable = 0xc7ff0000 Reading Fat16 Table (128 Sectors Long)

    sdCardFat16RootDir = 0xc7fe0000 Reading Root Directory (128 Sectors Long)

    Root Directory File 0 [RISCV . ] @ Cluster 0 for 0 bytes File 2 [EMULATOR.BIN] @ Cluster 3 for 9600 bytes File 4 [IMAGE . ] @ Cluster 4 for 4545524 bytes File 6 [ROOTFS~1.CPI] @ Cluster 74 for 8029184 bytes File 8 [RV32 .DTB] @ Cluster 197 for 1837 bytes

    Reading File [IMAGE.] into 0xc0000000 : File starts at Cluster 4 length 4545524 Clusters: 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73

    Reading File [ROOTFS~1.CPI] into 0xc0800000 : File starts at Cluster 74 length 8029184 Clusters: 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196

    Reading File [RV32.DTB] into 0xc1000000 : File starts at Cluster 197 length 1837 Clusters: 197

    Reading File [EMULATOR.BIN] into 0x20000000 : File starts at Cluster 3 length 9600 Clusters: 3

    Executing booted program at 0x20000000

    --============= Liftoff! ===============-- VexRiscv Machine Mode software built Jan 10 2020 11:39:55 --========== Booting Linux =============--`

    Code is available at

    opened by rob-ng15 39
  • Porting LiteX to the Crosslink-NX eval board

    Porting LiteX to the Crosslink-NX eval board

    I've just started working on getting LiteX working on the Crosslink-NX evaluation board, basically copying the Versa ECP5 target, stripping out the Trellis stuff, adapting it for Radiant, and working on some of the device specific details that need to be figured out (like the PLL block configuration). Figured I'd start a thread here on it in case anyone else has played with this, or has some pointers on the process.

    opened by davidcorrigan714 39
  • Converting LiteX to use Python modules.

    Converting LiteX to use Python modules.

    This is the start of converting LiteX to use the litex-data-XXX python modules.

    It hasn't been tested and probably doesn't work yet, but wanted you to see the direction it is going.

    opened by mithro 34
  • CSR accessor performance / feature / build Regressions

    CSR accessor performance / feature / build Regressions

    Due to a recent change, the CSR accessor methods have undergone a large performance regression. Additionally, the Etherbone library is now incompatible.

    Performance Regression

    Previously, CSRs were defined similarly to:

    static inline void csr_writel(uint32_t value, uint32_t addr)
    	*((volatile uint32_t *)addr) = value;

    This allowed the compiler to inline writes very easily. For example, in Fomu we have the following function:

    static void spi_single_tx(uint8_t out) {
    	int bit;
    	for (bit = 7; bit >= 0; bit--) {
    		if (out & (1 << bit)) {
    			lxspi_bitbang_write((0 << PIN_CLK) | (1 << PIN_MOSI));
    			lxspi_bitbang_write((1 << PIN_CLK) | (1 << PIN_MOSI));
    			lxspi_bitbang_write((0 << PIN_CLK) | (1 << PIN_MOSI));
    		} else {
    			lxspi_bitbang_write((0 << PIN_CLK) | (0 << PIN_MOSI));
    			lxspi_bitbang_write((1 << PIN_CLK) | (0 << PIN_MOSI));
    			lxspi_bitbang_write((0 << PIN_CLK) | (0 << PIN_MOSI));

    This would get compiled down to the following function:

    (gdb) disassemble spi_single_tx
    Dump of assembler code for function spi_single_tx:
       0x0000014c <+0>:     li      a4,7
       0x00000150 <+4>:     lui     a5,0xe0008
       0x00000154 <+8>:     li      a6,2
       0x00000158 <+12>:    li      a2,1
       0x0000015c <+16>:    li      a7,3
       0x00000160 <+20>:    li      a1,-1
       0x00000164 <+24>:    sra     a3,a0,a4
       0x00000168 <+28>:    andi    a3,a3,1
       0x0000016c <+32>:    beqz    a3,0x188 <spi_single_tx+60>
       0x00000170 <+36>:    sw      a2,-2048(a5) # 0xe0007800
       0x00000174 <+40>:    sw      a7,-2048(a5)
       0x00000178 <+44>:    sw      a2,-2048(a5)
       0x0000017c <+48>:    addi    a4,a4,-1
       0x00000180 <+52>:    bne     a4,a1,0x164 <spi_single_tx+24>
       0x00000184 <+56>:    ret
       0x00000188 <+60>:    sw      zero,-2048(a5)
       0x0000018c <+64>:    sw      a6,-2048(a5)
       0x00000190 <+68>:    sw      zero,-2048(a5)
       0x00000194 <+72>:    j       0x17c <spi_single_tx+48>
    End of assembler dump.

    With the most recent changes to the CSR accessors, this is now expanded to:

    (gdb) disassemble spi_single_tx
    Dump of assembler code for function spi_single_tx:
       0x000001dc <+0>:     addi    sp,sp,-16
       0x000001e0 <+4>:     sw      s0,8(sp)
       0x000001e4 <+8>:     sw      s1,4(sp)
       0x000001e8 <+12>:    sw      s2,0(sp)
       0x000001ec <+16>:    sw      ra,12(sp)
       0x000001f0 <+20>:    mv      s2,a0
       0x000001f4 <+24>:    li      s0,7
       0x000001f8 <+28>:    li      s1,-1
       0x000001fc <+32>:    sra     a5,s2,s0
       0x00000200 <+36>:    andi    a5,a5,1
       0x00000204 <+40>:    beqz    a5,0x240 <spi_single_tx+100>
       0x00000208 <+44>:    li      a0,1
       0x0000020c <+48>:    jal     ra,0x1c8 <lxspi_bitbang_write>
       0x00000210 <+52>:    li      a0,3
       0x00000214 <+56>:    jal     ra,0x1c8 <lxspi_bitbang_write>
       0x00000218 <+60>:    li      a0,1
       0x0000021c <+64>:    addi    s0,s0,-1
       0x00000220 <+68>:    jal     ra,0x1c8 <lxspi_bitbang_write>
       0x00000224 <+72>:    bne     s0,s1,0x1fc <spi_single_tx+32>
       0x00000228 <+76>:    lw      ra,12(sp)
       0x0000022c <+80>:    lw      s0,8(sp)
       0x00000230 <+84>:    lw      s1,4(sp)
       0x00000234 <+88>:    lw      s2,0(sp)
       0x00000238 <+92>:    addi    sp,sp,16
       0x0000023c <+96>:    ret
       0x00000240 <+100>:   li      a0,0
       0x00000244 <+104>:   jal     ra,0x1c8 <lxspi_bitbang_write>
       0x00000248 <+108>:   li      a0,2
       0x0000024c <+112>:   jal     ra,0x1c8 <lxspi_bitbang_write>
       0x00000250 <+116>:   li      a0,0
       0x00000254 <+120>:   j       0x21c <spi_single_tx+64>
    End of assembler dump.
    (gdb) disassemble lxspi_bitbang_write
    Dump of assembler code for function lxspi_bitbang_write:
       0x000001c8 <+0>:     mv      a1,a0
       0x000001cc <+4>:     lui     a0,0xe0008
       0x000001d0 <+8>:     li      a2,0
       0x000001d4 <+12>:    addi    a0,a0,-2048 # 0xe0007800
       0x000001d8 <+16>:    j       0x20 <_csr_wr>
    End of assembler dump.
    (gdb) disassemble _csr_wr
    Dump of assembler code for function _csr_wr:
       0x00000020 <+0>:     sw      a1,0(a0)
       0x00000024 <+4>:     ret
    End of assembler dump.

    Each single-instruction store is turned into two function calls and a load, which increases the instruction count 9x (ignoring penalties for jumps and returns).

    Feature regression

    It can be extremely useful to use libeb-c with the wishbone bridge in order to prototype and debug code on a local machine before porting it to an embedded softcore. Previously, the functions csr_(read|write)[bwl]() were conditionally defined if CSR_ACCESSORS_DEFINED was not defined. This allowed for C code to be compiled both for the device itself, as well as on a host system connected to a wishbone bridge simply by defining the macro CSR_ACCESSORS_DEFINED and providing replacement functions.

    With the most recent patch, this can no longer be done. Instead it inserts an unconditional call to _csr_(rd|wr) which does direct array indexing.

    Build regression

    The new function appears to require a new symbol when compiling with 8-bit CSRs:

    d:/software/fomu-toolchain-windows-v1.5.3/bin/../lib/gcc/riscv64-unknown-elf/8.3.0/../../../../riscv64-unknown-elf/bin/ld.exe: C:\Users\smcro\AppData\Local\Temp\ccK4Ba47.ltrans0.ltrans.o: in function `.L0 ':
    D:\Code\Fomu\foboot\hw\build\software\bios/../../../../sw/include/hw/common.h:78: undefined reference to `__lshrdi3'
    collect2.exe: error: ld returned 1 exit status

    This appears to be due to the use of 64-bit parameters on a 32-bit system. Changing the argument to a 32-bit parameter (i.e. static inline void _csr_wr(unsigned long *a, uint32_t v, int csr_bytes)) fixes this build issue, but it's not clear why this needs to be a 64-bit value.

    enhancement question 
    opened by xobs 30
  • picorv32 doesn't check (nor use) the

    picorv32 doesn't check (nor use) the "variant" argument.

    Was looking at that "variants" the picorv32 supported and found out it is not checking (or using) the variant CPU config at all.


    opened by mithro 27
  • Software only compiles on Windows when V=1

    Software only compiles on Windows when V=1

    Something changed, and now

    [email protected]   yosys-bld  D:\Code\HaD\valentytest   master ≢                                                                                                                                                                                 [09:36]
    ❯ make -C D:\Code\HaD\valentytest\build2\software\libcompiler_rt -f D:\Code\HaD\valentytest\deps\litex\litex\soc\software\libcompiler_rt\Makefile
    make: Entering directory 'D:/Code/HaD/valentytest/build2/software/libcompiler_rt'
     CC       umodsi3.o
    riscv64-unknown-elf-gcc.exe: error: D:CodeHaDvalentytestdepslitexlitexsoc/software/compiler_rt/lib/builtins/umodsi3.c: No such file or directory
    riscv64-unknown-elf-gcc.exe: fatal error: no input files
    compilation terminated.
    make: *** [D:\Code\HaD\valentytest\deps\litex\litex\soc\software\libcompiler_rt\Makefile:27: umodsi3.o] Error 1
    make: Leaving directory 'D:/Code/HaD/valentytest/build2/software/libcompiler_rt'
    [email protected]   yosys-bld  D:\Code\HaD\valentytest   master ≢                                                                                                                                                                                 [09:36]
    ❯ make -C D:\Code\HaD\valentytest\build2\software\libcompiler_rt -f D:\Code\HaD\valentytest\deps\litex\litex\soc\software\libcompiler_rt\Makefile V=1
    make: Entering directory 'D:/Code/HaD/valentytest/build2/software/libcompiler_rt'
    riscv64-unknown-elf-gcc -std=gnu99 -c -MD -MP -Os -march=rv32ima    -mabi=ilp32 -D__vexriscv__ -g3 -fomit-frame-pointer -Wall -fno-builtin -nostdinc -ID:\\Code\\HaD\\valentytest\\deps\\litex\\litex\\soc/software/include/base -ID:\\Code\\HaD\\valentytest\\deps\\litex\\litex\\soc/software/include -ID:\\Code\\HaD\\valentytest\\deps\\litex\\litex\\soc/common -ID:\\Code\\HaD\\valentytest\\build2\\software\\include -fexceptions -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -D_YUGA_LITTLE_ENDIAN=1 -D_YUGA_BIG_ENDIAN=0 -Wno-missing-prototypes  D:\\Code\\HaD\\valentytest\\deps\\litex\\litex\\soc/software/compiler_rt/lib/builtins/umodsi3.c -o umodsi3.o
    riscv64-unknown-elf-gcc -std=gnu99 -c -MD -MP -Os -march=rv32ima    -mabi=ilp32 -D__vexriscv__ -g3 -fomit-frame-pointer -Wall -fno-builtin -nostdinc -ID:\\Code\\HaD\\valentytest\\deps\\litex\\litex\\soc/software/include/base -ID:\\Code\\HaD\\valentytest\\deps\\litex\\litex\\soc/software/include -ID:\\Code\\HaD\\valentytest\\deps\\litex\\litex\\soc/common -ID:\\Code\\HaD\\valentytest\\build2\\software\\include -fexceptions -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -D_YUGA_LITTLE_ENDIAN=1 -D_YUGA_BIG_ENDIAN=0 -Wno-missing-prototypes  D:\\Code\\HaD\\valentytest\\deps\\litex\\litex\\soc/software/compiler_rt/lib/builtins/udivsi3.c -o udivsi3.o

    I'm unsure of what changed, or why it's not working. The && appears to be causing the problem now.

    My current workaround is to hardcode V=1 in

    Edited: Corrected how I'm hardcoding verbose mode.

    opened by xobs 27
  • Mor1kx support broken by #517

    Mor1kx support broken by #517

    #517 changes the way accesses are done on the CSRs and broke Mor1kx support: lxsim is not responding to user commands.

    Command reproduce it: rm -rf build && lxsim --cpu-type=mor1kx --opt-level=O0

    Works before

    opened by enjoy-digital 24
  • software/bios: Add option to obtain IP address from DHCP server

    software/bios: Add option to obtain IP address from DHCP server

    That PR allows to obtain IP address automatically from DHCP server using eth_dhcp command. That command is only available when with_dhcp argument is set in litex/soc/integration/ dhcp_get_ip function in litex/soc/software/bios/boot.c invokes dhcp_resolve function with MAC address as parameter. That PR is associated with litex-hub/litex-boards#206.

    opened by MateuszKosmala 2
  • soc/integration: generate and add list of peripherals

    soc/integration: generate and add list of peripherals

    This PR adds --generate-peripherals parameter. Using that parameter causes generating a list of peripherals in the csv format which is then changed into an array in C (using xxd). The array is being added by the linker script but instead of just adding it to the ROM, there's being added peripherals_rom right after the ROM (self.soc.mem_regions['rom'].origin + 2**log2_int(self.soc.mem_regions['rom'].size, False)) to put the array in. The peripherals_rom size matches the array size. In future, there could be an option to put that new peripherals_rom in a specific place but currently, setting an address was causing problems with the ROM resizing.

    The main aim for now is checking if a DTS is correct if it comes from other build then the binary itself but there are also possible other use cases.

    opened by AleksandraSwierkowska 3
  • Custom Function Unit (CFU) integration

    Custom Function Unit (CFU) integration

    I have been experimenting with custom function units (CFUs) added to VexRiscv (using VexRiscv since it provides a CfuPlugin option, and it's also awesome, although eventually we hope more CPUs support the interface). The CFU connects ONLY to the CPU, not to the system bus, and it has no CSRs of its own. I've been using CPU+CFU in LiteX systems for quite a while now, but I've been hiding the CFU from LiteX --- I make a wrapper containing the CPU+CFU, and the wrapper exports just the normal CPU signals, so LiteX doesn't even know the CFU is there.

    But now I think it makes sense to hook up the CFU in LiteX, so I'd like to ask your advice. I've mocked up a couple of ways of doing it. I have the code for connecting the CFU to the VexRiscv in cores/cpu/vexriscv/ --- it creates and hooks the signals, creates the CFU instance, and optionally adds the CFU source. But it might make more sense to have the CPU just create its interface when needed, and move the CFU instantiation and CFU<->CPU hookup out of the CPU

    I've had a suggestion to create a Record for the CFU<->CPU connections.

    The interface will be fairly stable. It is basically one cmd stream CPU-->CFU with a payload of an opcode and two data arguments, and a rsp stream CFU-->CPU with a payload of one data result and a ok status bit. There will likely also be a context_id field in the cmd payload, although that is still being finalized.

    opened by tcal-x 11
  • Litex_sim not working on GitHub Actions

    Litex_sim not working on GitHub Actions

    Describe the bug When running litex_sim in CI environments like GitHub Actions it will fail due to missing stdin.

    To Reproduce Execture litex_sim on GitHub Actions or have a look at this log.

    Expected behavior When running on a non interactive environment we should have an option to disable stdin.

    Log output

    Traceback (most recent call last):
      File "/home/runner/.local/bin/litex_sim", line 11, in <module>
        load_entry_point('litex', 'console_scripts', 'litex_sim')()
      File "/home/runner/work/linux-on-litex-blackparrot/linux-on-litex-blackparrot/litex/litex/tools/", line 374, in main, threads=args.threads, sim_config=sim_config,
      File "/home/runner/work/linux-on-litex-blackparrot/linux-on-litex-blackparrot/litex/litex/soc/integration/", line 214, in build
        vns =, **kwargs)
      File "/home/runner/work/linux-on-litex-blackparrot/linux-on-litex-blackparrot/litex/litex/soc/integration/", line 911, in build
        return, *args, **kwargs)
      File "/home/runner/work/linux-on-litex-blackparrot/linux-on-litex-blackparrot/litex/litex/build/sim/", line 44, in build
        return, *args, **kwargs)
      File "/home/runner/work/linux-on-litex-blackparrot/linux-on-litex-blackparrot/litex/litex/build/sim/", line 216, in build
        _run_sim(build_name, as_root=run_as_root)
      File "/home/runner/work/linux-on-litex-blackparrot/linux-on-litex-blackparrot/litex/litex/build/sim/", line 161, in _run_sim
        termios_settings = termios.tcgetattr(sys.stdin.fileno())
    termios.error: (25, 'Inappropriate ioctl for device')

    Proposed Solution Add a --non-interactive flag or environmental variable to litex_sim which then propagates to: Similar to win32 the interactive should be used to determine whether stdin should be enabled. I created a draft pull request with the proposed interactive parameter for _run_sim. However I'm looking for your feedback on how this information should be passed to _run_sim.


    • CI: GitHub Actions
    • OS: Ubuntu 20.04

    Additional context I'm trying to automate testing for the linux-on-litex-blackparrot project.

    enhancement ideas question 
    opened by developandplay 0
  • litex/vexriscv boot problem

    litex/vexriscv boot problem

    Hello, I am working on a custom board based on Artix xc7a100tcsg324-1, Litex/vexriscv, code flash memory and DDR RAM. System is properly working, but in some rare builds I am getting the following behavior (from debug UART):

    Copying 0x90500000 to 0x40000000 (59241 bytes)...
    Executing booted program at 0x40000000
    --============= Liftoff! ===============--

    Nothing wrong about that, but unluckily user software is not starting at all, as something wrong is happening just after BIOS liftoff. Additional note: I have a static initialized variable in my C code, something like static uint8_t my_var = 1;. If I change it to uninitialized, so static uint8_t my_var;, then boot problem disappears. No problem at all also if I change variable from initialized uint8_t to initialized uint32_t, while initialized uint16_t bevavior is same as for initialized uint8_t.

    Thanks in advance for the help


    [EDIT] just noticed many similarities to #856: changing variable from initialized to uninitialized is actually moving it from .DATA to .BSS, and this solves the issue. Anyway, I would still not understand why changing from initialized uint8_t to initialized uint32_t is also working

    opened by andreapas-ap 2
  • add the following modification

    add the following modification

    Dear Sir:

    I had done the following modification.

    1. add wave share 7" hdmi lcd monitor video setting in litex/soc/cores/
    2. add video framebuffer memory base in add_video_framebuffer() to make config easier in litex/soc/integration/
    3. add video framebuffer memory clear code in main() in litex/soc/software/bios/main.c.
    4. add simple progress indication during sd card boot flow in init_progression_bar() / show_progress() in litex/soc/software/libbase/progress.c.
    5. change fixed video framebuffer memory base to the base of add_video_framebuffer() in litex/tools/

    If it is ok, please add these modification. Many Thanks.

    BR, Sanada

    opened by SanadaShinken 0
  • demo hangs on boot if it contains more than 16 bytes of .data

    demo hangs on boot if it contains more than 16 bytes of .data

    In the demo application, when defining a global array like this:

    #define CRASHME 1
    uint8_t some_random_data[] = {
    	0xd0, 0x0f,
    	0xd0, 0x0f,
    	0xd0, 0x0f,
    	0xd0, 0x0f,
    	0xd0, 0x0f,
    	0xd0, 0x0f,
    	0xd0, 0x0f,
    	0xd0, 0x0f
    #if CRASHME

    Then the application will hang on boot if CRASHME == 1 and successfully run, if CRASHME == 0. In other words, if there are more than 16 bytes of global data allocated, the application will fail to boot (freeze at liftoff). Reproduction: DECA board with integrated_main_ram_size = 0x4000

    opened by hansfbaier 0
  • dts: gpio: interrupt controller definition for switches

    dts: gpio: interrupt controller definition for switches

    This commit adds support for enabling interupts in switches module. Declaring switches as GPIOIn module with with_irq=True will make dts generation add correct interrupt controller definition. Also, if SWITCHES_NGPIO constant is defined it will be used to specify correct number of gpios in dts.

    example: self.submodules.switches = GPIOIn(pads=switches_pads, with_irq=True) self.add_csr("switches") self.irq.add("switches", use_loc_if_exists=True) self.add_constant("SWITCHES_NGPIO", len(switches_pads))

    Linux driver related changes are in

    opened by mczerski 0
  • litespi: fix cs handling for bulk transfers

    litespi: fix cs handling for bulk transfers

    For bulk transfers it is essential to keep cs asserted for all transfers in a block. CS register must directly drive the cs pin for the software to be able to control the CS pin.

    Linux driver related changes are in

    opened by mczerski 1
RemixDB: A read- and write-optimized concurrent KV store. Fast point and range queries. Extremely low write-amplification.

REMIX and RemixDB The REMIX data structure was introduced in paper "REMIX: Efficient Range Query for LSM-trees", FAST'21. This repository maintains a

Xingbo Wu 20 Mar 29, 2021
Powerful automated tool for reverse engineering Unity IL2CPP binaries

Powerful automated tool for reverse engineering Unity IL2CPP binaries

Katy 1k Apr 26, 2021
null 29 Mar 2, 2021
Opencore-based Hackintosh EFI and guide for Lenovo Thinkpad X1 Carbon Gen 7

macOS on Thinkpad X1 Carbon 7th Generation OpenCore-based Hackintosh EFI and guide for Lenovo Thinkpad X1 Carbon Gen 7. This guide has been generated

Aidan Chandra 13 Apr 19, 2021
Allwinner V3S Opensource

KS_V3S • Bilibili Video Introduction: I have designed this PCB, because the sheer power of this SoC, at ver

Kevincoooool 53 Feb 25, 2021
A laser cut Dreamcast Pop'n Music controller and integrated memory card using the Raspberry Pi Pico's Programmable IO

Dreamcast Pop'n Music Controller Using Raspbery Pi Pico (RP2040) Intro This is a homebrew controller for playing the Pop'n Music games on the Sega Dre

null 10 Mar 14, 2021
🪴💧 A Bluetooth Low Energy (BLE) soil moisture sensor.

b-parasite b-parasite is an open source Bluetooth Low Energy (BLE) soil moisture and ambient temperature/humidity sensor. Features Soil moisture senso

null 55 Apr 3, 2021
Minimal tool for measuring cost of mode switch

CPU mode switch statistics The mode-switch-stat tool measures the cost of CPU mode switch, the round trip between user and kernel mode. At present, th

Steven Cheng 10 Apr 11, 2021
Compiler Optimizations Playground

This is (hopefully) the simplest implementation of the classic register-machine intermediate representation (IR) to undertake data and control flow analysis in a compiler middle-end.

null 26 Feb 23, 2021
a small C library for x86 CPU detection and feature extraction

libcpuid libcpuid provides CPU identification for the x86 (and x86_64). For details about the programming API, you might want to take a look at the pr

Veselin Georgiev 266 Feb 18, 2021
Simple Dynamic Strings library for C

Simple Dynamic Strings Notes about version 2: this is an updated version of SDS in an attempt to finally unify Redis, Disque, Hiredis, and the stand a

Salvatore Sanfilippo 3.4k Feb 18, 2021
Typesense is a fast, typo-tolerant search engine for building delightful search experiences.

Fast, typo tolerant, fuzzy search engine for building delightful search experiences ⚡ ??

Typesense 5.2k Mar 17, 2021
built-in CMSIS-DAP debugger tailored especially for the RP2040 “Raspberry Pi Pico”

RP2040 has two ARM Cortex-M0+ cores, and the second core normally remains dormant. pico-debug runs on one core in a RP2040 and provides a USB CMSIS-DAP interface to debug the other core. No hardware is added; it is as if there were a virtual debug pod built-in.

null 20 Feb 20, 2021
Raspberry Pi Pico Arduino core, for all RP2040 boards

Arduino-Pico Raspberry Pi Pico Arduino core, for all RP2040 boards This is a port of the RP2040 (Raspberry Pi Pico processor) to the Arduino ecosystem

Earle F. Philhower, III 94 Mar 30, 2021