Sunday, 2019-06-02

*** tpb has joined #litex00:00
*** acathla has quit IRC00:22
*** futarisIRCcloud has joined #litex02:09
*** RedMercury has joined #litex04:22
RedMercuryI'm trying to play with litex, building for mimasv2, but I'm getting this error:  OSError: no version directory for Xilinx tools found in /opt/Xilinx/04:23
*** futarisIRCcloud has quit IRC04:28
RedMercuryjust tried my arty instead, ran into an issue and that's how I created my first litex pull request :p05:20
*** RedMercury has quit IRC06:10
*** futarisIRCcloud has joined #litex06:40
tpbTitle: Open source Zephyr RTOS featured in RISC-V Getting Started Guide (at
*** acathla has joined #litex07:48
*** acathla has quit IRC07:54
*** acathla has joined #litex07:54
*** futarisIRCcloud has quit IRC09:40
*** futarisIRCcloud has joined #litex11:02
*** futarisIRCcloud has quit IRC13:12
*** ambro718 has joined #litex16:42
ambro718Hi. Could someone explain the ethernet config in dts?
tpbTitle: linux-on-litex-vexriscv/litex_vexriscv_arty.dts at master · enjoy-digital/linux-on-litex-vexriscv · GitHub (at
ambro718I don't understand where the address f0009800 comes from or where interrupts = <0x3>; comes from.16:43
ambro718According to, the ethernet is at address 0x30000000, and I can't find any setting of the interrupt number16:44
_florent__ambro718: sorry, the ethernet support is still not finished, there are probably some incoherencies, i need to have a closer look17:05
ambro718Okay, no problem.17:09
ambro718I am wondering what's all the infrastructure around CSRs? I read these are special registers built into the risc-v instruction set but I don't get what is happening in litex with the csr mapping and WB2CSR17:11
_florent__ambro718: for your arty a7-100:
tpbTitle: boards/platform/arty: add Arty A7-100 variant · enjoy-digital/[email protected] · GitHub (at
ambro718_florent__: That's cool, though how can it be used from linux-on-litex-vexriscv?17:21
somloambro718: RISC-V CSRs are orthogonal to LiteX CSRs (I know, confusing at first) :)17:22
ambro718somlo: so what are LiteX CSRs?17:22
somloLiteX CSRs are essentially MMIO registers17:22
somlofor various hardware provided by the SoC, external to the CPU itself17:23
ambro718somlo: That's the same thing peripherals are typically accessed from?17:23
ambro718Ah so this is all about the address space of the peripherals?17:23
somloLiteX gives you a bunch of peripherals, and you configure them via MMIO - they're referred to as CSRs in the LiteX vernacular17:23
ambro718So how is access to CSRs routed to peripherals?17:24
_florent__the CSR of LiteX are different than CSR of RISC-V, that's the Control Status Registers you create in your SoC17:25
_florent__In LiteX, a specific Wishbone region is allocated for CSRs and there is a Wishbone to CSR bridge to control the CSR bus (and then registers)17:26
ambro718Is there any documentation for the litex CSR system?17:26
ambro718what is the Wishbone to CSR bridge used for, is this between the CPU and the CSR system?17:27
ambro718... and then it goes to different cores?17:28
somloambro718: I recently had to tinker with it, and you might find the commit log of this candidate patch helpful:
tpbTitle: [RFC - Do NOT Pull] Align MMIO/CSRs on 64-bit address boundary · enjoy-digital/[email protected] · GitHub (at
ambro718I am looking at in linux-on-litex-vexriscv and I am confused how both the csr numbers (csr_map) and memory addresses (mem_map) are specified.17:30
ambro718I would expect only memory addresses to be defined for each core and the framework would take care of the rest.17:31
somloambro718: not having seen linux-on-litex-vexriscv yet, I'll defer to _florent__ on that one; however, MMIO regions (specifically the CSR region) in the overarching map is or-ed with 0x80000000, so any memory (cacheable) accesses happen below that, and any MMIO (uncached) accesses happen above that address17:36
somlowithin the CSR region (which ends up starting at 0xe0000000) each device gets a "bank" (i.e. a sub-range), and individual registers for that peripheral are grouped within that bank, in slices of up to 8bits that are addressable by an individual store or load CPU opcode17:37
ambro718"below" you mean "at higher addresses"?17:39
somlobelow == at lower addresses17:40
somlo0...0x8000_0000 is assumed to be cached, 0x8000_0000 and above == uncached17:40
ambro718Ok thanks for the explanation. But I am not connecting it with the soc_linux definitions at all, it seems to contradict what you said.
tpbTitle: linux-on-litex-vexriscv/ at master · enjoy-digital/linux-on-litex-vexriscv · GitHub (at
somlobut the only uncached thing above 0x8000_0000 is the CSR (MMIO) register area starting at 0xE000_0000 (that I know of)17:41
somlooh, that appears to be a different allocation scheme than what the litex repository uses by default17:43
somlomy numbers and examples use the defaults from here:
tpbTitle: litex/ at master · enjoy-digital/litex · GitHub (at
ambro718somlo: why does the eth_max appear with its own address, why isn't it part of csr?17:45
somloI *think* those are some sort of hardware tx/rx buffer space, different from actual config registers (but I invite _florent__ to kick me if what I just said is monumentally stupid :)17:46
ambro718Yeah it has a separate wishbone interface for reading/writing packets.17:56
_florent__ambro718: cores can have registers but also use memory regions17:58
_florent__ambro718: the csr memory regions is shared for the CSRs of all cores17:58
ambro718But why, why not have just one uniform way for CPU to access cores?17:59
_florent__that's an architecture choice, to have a simple bus to control the cores18:06
ambro718The CPU always uses wishbone for non-memory accesses, which then goes through the WB2CSR or core-specific WB interfaces?18:11
_florent__that's correct to access CSRs, for core-specific WB interfaces, it's directly on the wishbone bus18:13
ambro718Makes sense, thanks for explaining.18:14
ambro718What is the simplest core that uses DMA?18:16
ambro718I want to understand how DMA works in litex18:16
_florent__ambro718: not sure i have an example to share for wishbone, but for litedram, you can look at that:
tpbTitle: litedram/ at master · enjoy-digital/litedram · GitHub (at
ambro718_florent__: I mean making a core write to or read from DRAM, is there not a single right way to do that?18:24
_florent__ambro718: you can look at that:
tpbTitle: litedram/ at fifo · enjoy-digital/litedram · GitHub (at
_florent__ambro718: sorry, i have to go18:26
ambro718okay thanks18:26
*** tinyfpga_ has quit IRC19:01
ambro718I'm thinking about how to do DMA for Ethernet. I've come to the following schema: Ethernet core --(WB)--> L2 arbiter --> L2 cache --> DRAM.  (L2 arbiter and L2 cache are part of
ambro718Alternative way would be to go directly to DRAM with any of the available options bypassing the L220:47
ambro718But that seems like a no-go due to cache incoherency problems.20:47
ambro718I mean via calling sdram.crossbar.get_port()20:49
ambro718Or is there some way to solve cache incoherency?20:49
ambro718The non-ideal thing of going through L2 is that its WB interface has 32-bit data width which would result in suboptimal performance (the raw DRAM interfaces are wider e.g. 128-bit)20:50
*** ambro718 has quit IRC22:05
*** tinyfpga has joined #litex22:33

Generated by 2.13.1 by Marius Gedminas - find it at!