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

Related tags

Miscellaneous litex

                          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]

  • 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
  • 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
  • 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
  • FemtoRV: Finish integration.

    FemtoRV: Finish integration.

    The upstream versions does not compile correctly with Verilator with ADDR_WIDTH set to 32. So the following patched version is currently used: femtorv32_quark.v.txt.

    opened by enjoy-digital 38
  • issues with the picolibc switch?:  Use this issue to share issues/get information/help

    issues with the picolibc switch?: Use this issue to share issues/get information/help

    My CI just broke on the latest litex, and there's a new note that this library seems to be required:

    Traceback (most recent call last):
      File "/home/bunnie/code/betrusted-soc/", line 1974, in <module>
        ret = main()
      File "/home/bunnie/code/betrusted-soc/", line 1901, in main
        vns =
      File "/home/bunnie/code/betrusted-soc/deps/litex/litex/soc/integration/", line 276, in build
        new_variables_contents = self._get_variables_contents()
      File "/home/bunnie/code/betrusted-soc/deps/litex/litex/soc/integration/", line 143, in _get_variables_contents
        picolibc_directory = get_data_mod("software", "picolibc").data_location
      File "/home/bunnie/code/betrusted-soc/deps/litex/litex/", line 14, in get_data_mod
        raise ImportError("""\
    ImportError: pythondata-software-picolibc module not installed! Unable to use picolibc software.
    No module named 'pythondata_software_picolibc'
    You can install this by running;
     pip install git+

    However, at least in my view of litex-hub, I don't see a pythondata-software-picolibc:


    (In the image above, I'm only finding software-compiler-rt in litex-hub, and that is the only search result)

    I have a feeling I'm missing something really obvious -- could someone please give me a clue on where to find this new dependency?

    opened by bunnie 36
  • 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
  • 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
  • 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
  • How does Litex expect 32bit reads/writes to be handled by 64bit CPUs?

    How does Litex expect 32bit reads/writes to be handled by 64bit CPUs?

    Unfortunately I'm still stuck on when updating Blackparrot support to the most recent Litex version.

    The current wishbone adapter in Blackparrot only handles 64bit reads/writes which means sel (corresponding to AXis strb) will always be 0xFF. If I do understand what is breaking for Blackparrot is the reliance on sel in which requires sel to be set to either 0x0F or 0xF0 when doing 32bit accesses.

    However I'm not sure what Litex expects exactly from the CPUs Wishbone/AXI adapter. I also read the discussion behind and the CSR bus wiki but when it comes to 64bit CPUs it doesn't seem very clear to me.

    Maybe @gsomlo can chime as Rocket does support 32bit read/writes for CSR access and I saw he asked how Rocket handles 32bit read/writes here.

    question bug? 
    opened by developandplay 24
  • Where is the CVA6 wrapper?

    Where is the CVA6 wrapper?

    CVA6 support requires a couple of files:

    An attempt to run litex_sim --cpu-type=cva6 reports Flist.cv64a6_imafdc_sv39 as missing - this is easy to fix by prefixing its path with core/ - but Flist.cva6_wrapper is missing completely and I can not find any trace of it anywhere. It is not in; not in either; also not in PyPi built packages; links to it in are broken. I can not find it even in the history of the repos. What is the story with it?

    @suppamax @mithro

    opened by sergachev 4
  • Issue with an Instance

    Issue with an Instance


    I am trying to integrate the following frequency divider into my system. The FPGA is an ECP5N lattice.

         self.clock_domains.cd_dclk = ClockDomain()
         self.specials += [
                        i_CLKI  = ClockSignal("transfer"),
                        i_RST  = 0,
                        o_CDIVX = ClockSignal("dclk"),

    However, when I compile the code, the process gets stuck at this point and nothing else happens.

                    Info: Placed 134 cells based on constraints.
                    Info: Creating initial analytic placement for 10573 cells, random placement wirelen = 704316.
                    Info:     at initial placer iter 0, wirelen = 10949
                    Info:     at initial placer iter 1, wirelen = 8071
                    Info:     at initial placer iter 2, wirelen = 7253
                    Info:     at initial placer iter 3, wirelen = 7045
                    Info: Running main analytical placer.

    If I remove the divider the process completes correctly. What am I doing wrong? Thank you

    opened by ramalmar 1
  • DSP disable option for yosys+nextpnr toolchain

    DSP disable option for yosys+nextpnr toolchain

    When yosys is called with DSP enabled for xilinx target, nextpnr-xilinx gives this error: ERROR: Clocked DSP48E1s are currently unsupported

    Solution: add -nodsp option in 'yosys -p "synth_xilinx -flatten -abc9 -nobram -nodsp -arch xc7 -top $(TOP); write_json $(TOP).json" $(VERILOG) > /dev/null'

    (ideally those options should be seteable in class YosysNextpnrToolchain)

    test image after multiplier-in-fabric solution: image

    opened by suarezvictor 0
  • SDROutput and nextpnr+xilink platform

    SDROutput and nextpnr+xilink platform

    When using nextpnr+xilinx, ODDR instances for VideoGenericPHY keeps being generated even when SDROutput is requested

    a temporary solution found was to replace the SDROutput with direct assignment (in

    class VideoGenericPHY_SDR(Module):
        def __init__(self, pads, clock_domain="sys"):
            self.sink = sink = stream.Endpoint(video_data_layout)
            # # #
            # Always ack Sink, no backpressure.
            self.comb += sink.ready.eq(1)
            # Drive Clk.
            if hasattr(pads, "clk"):
                self.comb += pads.clk.eq(ClockSignal(clock_domain))
            # Drive Controls.
            if hasattr(pads, "de"):
                self.comb +=
            if hasattr(pads, "hsync_n"):
                self.comb += pads.hsync.eq(~sink.hsync)
                self.comb += pads.hsync.eq(sink.hsync)
            if hasattr(pads, "vsync_n"):
                self.comb += pads.vsync.eq(~sink.vsync)
                self.comb += pads.vsync.eq(sink.vsync)
            # Drive Datas.
            cbits  = len(pads.r)
            cshift = (8 - cbits)
            for i in range(cbits):
                self.comb += pads.r[i].eq(sink.r[cshift + i] &
                self.comb += pads.g[i].eq(sink.g[cshift + i] &
                self.comb += pads.b[i].eq(sink.b[cshift + i] &
    enhancement question 
    opened by suarezvictor 1
  • Undefined refrence to C liberaries

    Undefined refrence to C liberaries

    Hello @enjoy-digital, I have tried before using the function clock() (which is a built in function in C libraries) it gives me undefined reference to clock() also, I have tried generating CSV file to get my outputs out of a C file in memtest.c file but it also gives me : /home/fathymd/litex2/riscv64-unknown-elf-gcc-8.3.0-2019.08.0-x86_64-linux-centos6/bin/../lib/gcc/riscv64-unknown-elf/8.3.0/../../../../riscv64-unknown-elf/bin/ld: /home/fathymd/litex2/litex-boards/litex_boards/targets/build/xilinx_vc707/software/libc/../../../../../../../pythondata-software-picolibc/pythondata_software_picolibc/data/newlib/libc/picolib/picosbrk.c:49: undefined reference to__heap_end' /home/fathymd/litex2/riscv64-unknown-elf-gcc-8.3.0-2019.08.0-x86_64-linux-centos6/bin/../lib/gcc/riscv64-unknown-elf/8.3.0/../../../../riscv64-unknown-elf/bin/ld: ../libc/libc.a(libc_picolib_picosbrk.c.o):/home/fathymd/litex2/litex-boards/litex_boards/targets/build/xilinx_vc707/software/libc/../../../../../../../pythondata-software-picolibc/pythondata_software_picolibc/data/newlib/libc/picolib/picosbrk.c:41: undefined reference to __heap_start' /home/fathymd/litex2/riscv64-unknown-elf-gcc-8.3.0-2019.08.0-x86_64-linux-centos6/bin/../lib/gcc/riscv64-unknown-elf/8.3.0/../../../../riscv64-unknown-elf/bin/ld: ../libc/libc.a(libc_tinystdio_fopen.c.o): in functionfopen': /home/fathymd/litex2/litex-boards/litex_boards/targets/build/xilinx_vc707/software/libc/../../../../../../../pythondata-software-picolibc/pythondata_software_picolibc/data/newlib/libc/tinystdio/fopen.c:51: undefined reference to open' /home/fathymd/litex2/riscv64-unknown-elf-gcc-8.3.0-2019.08.0-x86_64-linux-centos6/bin/../lib/gcc/riscv64-unknown-elf/8.3.0/../../../../riscv64-unknown-elf/bin/ld: ../libc/libc.a(libc_tinystdio_fdopen.c.o): in functionfdopen': /home/fathymd/litex2/litex-boards/litex_boards/targets/build/xilinx_vc707/software/libc/../../../../../../../pythondata-software-picolibc/pythondata_software_picolibc/data/newlib/libc/tinystdio/fdopen.c:56: undefined reference to close' /home/fathymd/litex2/riscv64-unknown-elf-gcc-8.3.0-2019.08.0-x86_64-linux-centos6/bin/../lib/gcc/riscv64-unknown-elf/8.3.0/../../../../riscv64-unknown-elf/bin/ld: /home/fathymd/litex2/litex-boards/litex_boards/targets/build/xilinx_vc707/software/libc/../../../../../../../pythondata-software-picolibc/pythondata_software_picolibc/data/newlib/libc/tinystdio/fdopen.c:62: undefined reference toread' /home/fathymd/litex2/riscv64-unknown-elf-gcc-8.3.0-2019.08.0-x86_64-linux-centos6/bin/../lib/gcc/riscv64-unknown-elf/8.3.0/../../../../riscv64-unknown-elf/bin/ld: /home/fathymd/litex2/litex-boards/litex_boards/targets/build/xilinx_vc707/software/libc/../../../../../../../pythondata-software-picolibc/pythondata_software_picolibc/data/newlib/libc/tinystdio/fdopen.c:62: undefined reference to read' /home/fathymd/litex2/riscv64-unknown-elf-gcc-8.3.0-2019.08.0-x86_64-linux-centos6/bin/../lib/gcc/riscv64-unknown-elf/8.3.0/../../../../riscv64-unknown-elf/bin/ld: /home/fathymd/litex2/litex-boards/litex_boards/targets/build/xilinx_vc707/software/libc/../../../../../../../pythondata-software-picolibc/pythondata_software_picolibc/data/newlib/libc/tinystdio/fdopen.c:62: undefined reference towrite' /home/fathymd/litex2/riscv64-unknown-elf-gcc-8.3.0-2019.08.0-x86_64-linux-centos6/bin/../lib/gcc/riscv64-unknown-elf/8.3.0/../../../../riscv64-unknown-elf/bin/ld: /home/fathymd/litex2/litex-boards/litex_boards/targets/build/xilinx_vc707/software/libc/../../../../../../../pythondata-software-picolibc/pythondata_software_picolibc/data/newlib/libc/tinystdio/fdopen.c:62: undefined reference to write' /home/fathymd/litex2/riscv64-unknown-elf-gcc-8.3.0-2019.08.0-x86_64-linux-centos6/bin/../lib/gcc/riscv64-unknown-elf/8.3.0/../../../../riscv64-unknown-elf/bin/ld: /home/fathymd/litex2/litex-boards/litex_boards/targets/build/xilinx_vc707/software/libc/../../../../../../../pythondata-software-picolibc/pythondata_software_picolibc/data/newlib/libc/tinystdio/fdopen.c:62: undefined reference tolseek' /home/fathymd/litex2/riscv64-unknown-elf-gcc-8.3.0-2019.08.0-x86_64-linux-centos6/bin/../lib/gcc/riscv64-unknown-elf/8.3.0/../../../../riscv64-unknown-elf/bin/ld: /home/fathymd/litex2/litex-boards/litex_boards/targets/build/xilinx_vc707/software/libc/../../../../../../../pythondata-software-picolibc/pythondata_software_picolibc/data/newlib/libc/tinystdio/fdopen.c:62: undefined reference to lseek' /home/fathymd/litex2/riscv64-unknown-elf-gcc-8.3.0-2019.08.0-x86_64-linux-centos6/bin/../lib/gcc/riscv64-unknown-elf/8.3.0/../../../../riscv64-unknown-elf/bin/ld: /home/fathymd/litex2/litex-boards/litex_boards/targets/build/xilinx_vc707/software/libc/../../../../../../../pythondata-software-picolibc/pythondata_software_picolibc/data/newlib/libc/tinystdio/fdopen.c:62: undefined reference toclose' `

    So, can someone tell me what is the linkage problem I am doing?

    opened by FATHY174 1
BSD-licensed Yamaha FM sound cores (OPM, OPN, OPL, and others)

ymfm ymfm is a collection of BSD-licensed Yamaha FM sound cores (OPM, OPN, OPL, and others), written by Aaron Giles Supported environments This code s

Aaron Giles 146 Aug 7, 2022
This repo contains source code of our paper presented in IROS2021 "Single-Shot is Enough: Panoramic Infrastructure Based Calibration of Multiple Cameras and 3D LiDARs"

Single-Shot is Enough: Panoramic Infrastructure Based Calibration of Multiple Cameras and 3D LiDARs Updates [2021/09/01] first commit, source code of

Alibaba 62 Jul 23, 2022
DICOM images and volumes viewer with advanced processing infrastructure (WPF, ITK, VTK)

DicomViewer DICOM images and volumes viewer with advanced processing infrastructure Stack: WPF (C#) ITK (C++) VTK (C++) Structure: DicomViewer - WPF a

Paweł Piorun 0 Jul 1, 2022
Hierarchical Engine for Large-scale Infrastructure Co-Simulation (HELICS)

A multi-language, cross-platform library that enables different simulators to easily exchange data and stay synchronized in time. Scalable from two si

GMLC-TDC 81 Jul 21, 2022
A collection of command line tools for ARM devices with Allwinner SoCs.

sunxi-tools Copyright (C) 2012 Alejandro Mery [email protected] For a full list of contributors, see this link or use the command git shortlog -se --no-m

Free/Open Source Software for Allwinner SoCs (A10/A13/A10s/A20/A31/...) 442 Aug 7, 2022
A simple library that helps Android developers to execute JavaScript code from Android native side easily without using Webview.

AndroidJSModule A simple library that helps Android developers to execute JavaScript code from Android native side easily without using Webview. Insta

Hung Nguyen 5 May 24, 2022
Arduino core for GD32 devices, community developed, based on original GigaDevice's core

GD32 Arduino Core (New) This is a Arduino core is based off of the original GigaDevice core that was provided by the company in early June 2021 (see h

null 37 Jul 20, 2022
64-bit LKM Rootkit builder based on yaml prescription

1337kit - LKM Rootkit Builder About project 1337kit is 64-bit LKM Rootkit builder based on yaml prescription Fully tested on: Linux 5.11.0-34-generic

Lukas Balazik 16 Jul 17, 2022
Tiny FEL tools for allwinner SOC, support RISC-V D1 chip

XFEL Tiny FEL tools for allwinner SOC, support RISC-V D1 chip. How to build The xfel tools depends on the libusb-1.0 library, you need to install libu 107 Aug 10, 2022
Port of MIT's xv6 OS to the Nezha RISC-V board with Allwinner D1 SoC

xv6 is a re-implementation of Dennis Ritchie's and Ken Thompson's Unix Version 6 (v6). xv6 loosely follows the structure and style of v6, but is impl

Michael Engel 38 Jul 15, 2022
Porting RT-Thread for Gowin GW1NSR-4C Soc GCC version

Porting RT-Thread for Gowin GW1NSR-4C Soc GCC version Hello everyone, this project based on RT-THREAD NANO 3.1.5 and GOWIN GW1NSR-4C Soc chip. The com

Ray 3 Apr 23, 2022
Advanced discord token grabber builder with GUI

Token-Grabber-Builder Advanced discord token grabber builder with GUI Screenshot Features Hidden console High execution speed Grab discord tokens Stea

RadonCoding 2 Dec 2, 2021
Kernel with ARM/KVM for SM-A600G (Samsung Galaxy A6) with Exynos7870 SoC

Kernel source for SM-A600G (Samsung Galaxy A6 with exynos7870) with KVM support. Warning: Super long text ahead, be careful not to mess up your brain

@raspiduino 4 Aug 1, 2022
Risc-V RV32IMAFC + 80s ERA SoC (bitmap + GPU, sprites, tilemaps)

A simple (no interrupts or exceptions/traps), Risc-V RV32IMAFC CPU, with a pseudo SMT (dual thread) capability. The display is similar to the 8-bit era machines, along with audio, SDCARD read support, UART and PS/2 keyboard input.

Rob S 17 Jun 3, 2022
Buffer reader/builder for C

ubuf ubuf is a simple interface for reading/writing binary data. It handles automatically expanding the buffer and byte order for you, but that's abou

adrian 2 Jan 10, 2022
This repository is meant to host the core files needed to create a Beacon Object File for use with Cobalt Strike

BOF Template This repository is meant to host the core files needed to create a Beacon Object File for use with Cobalt Strike. A Beacon Object File (B

Cobalt Strike 29 Jul 19, 2022
Create a calculator of any kind in any language, create a pr.

calculators Create a calculator of any kind in any language, create a pr. Create a calculator of any type using the programming language of your choic

Akshay Gautam 2 Dec 1, 2021
Pty for Flutter. Provides the ability to create processes with pseudo terminal file descriptors.

flutter_pty This is an experimental package to explore the possibilities of using native code to implement PTY instead of pure FFI and blocking isolat

null 4 Jul 6, 2022
Easily hook WIN32 x64 functions

About Library for easy hooking of arbitrary functions in WIN32 x64 executables. Only requires target function address. Disassembles the function prolo

tcpie 17 Jun 12, 2022