Thursday, 2019-04-25

*** tpb has joined #litex00:00
*** futarisIRCcloud has joined #litex01:10
xobs_florent_: is there any way to fix the CSR offsets?  I'd like to make sure they don't move around.02:21
futarisIRCcloud_florent_ : Looks like antmicro were using a hacked version of u-boot (32bit) for Linux RISC-V.02:24
tpbTitle: Commits · antmicro/RV32_U-Boot · GitHub (at
futarisIRCcloud_florent_ / mithro: So I modified litex-buildenv/scripts/ to build qemu-v4.0.0 for vexriscv & riscv32.  I just need to pull the models for litex into that tree, and we should be able to boot BIOS & zepyhr in qemu...05:28
_florent_xobs: yes it's possible, i also have the same need for some projects (for example keep software compatibility on pcie boards)05:31
_florent_xobs: i'll give you that in ~1hour when i'll be at the office05:31
xobs_florent_: thanks! no hurry.05:31
_florent_futarisIRCcloud: thanks for links! (and the previous one), great for qemu05:33
_florent_futarisIRCcloud: i'll work on getting Linux working today05:34
mithrofutarisIRCcloud: we really should get a lot of that qemu stuff upstream...05:35
futarisIRCcloudmithro: Yeah. Probably worth adding a valentyusb model too...05:36
keesjqemu is a fast moving target05:36
mithrofutarisIRCcloud: can you send the patches to the as a pull request so I can merge?05:37
futarisIRCcloudmithro: Will do, as soon as I get the BIOS running.05:37
mithroShould poke shenki and stafford more about the qemu upstreaming stuff...05:38
_florent_xobs: if you want to have fixed CSR offsets, you can define you CSRs like that:
xobs_florent_: ah, I see!  I didn't realize it was a dict of ints.  That makes much more sense.07:35
futarisIRCcloudWell, I got qemu 4.0.0 compile. Can't seem to get litex machine to appear in the "-machine help" list though...08:15
futarisIRCcloudOops. left litex.o out of hw/riscv/Makefile.objs ...08:54
futarisIRCcloud_florent_ : How are interrupts hooked up to vexriscv?09:15
tpbTitle: litex/ at master · enjoy-digital/litex · GitHub (at
_florent_it's using a specific plugin (externalInterruptArray) that is not used by the others configurations09:23
futarisIRCcloud - lm3209:36
tpbTitle: litex/ at master · enjoy-digital/litex · GitHub (at
futarisIRCcloud - openrisc09:36
tpbTitle: litex/ at master · enjoy-digital/litex · GitHub (at
futarisIRCcloudand in qemu:09:39
tpbTitle: qemu-litex/litex.c at master · timvideos/qemu-litex · GitHub (at
tpbTitle: qemu-litex/litex.c at master · timvideos/qemu-litex · GitHub (at
futarisIRCcloudmithro: - litex-buildenv side is fairly straightforward10:00
tpbTitle: Commits · futaris/litex-buildenv · GitHub (at
futarisIRCcloud - still needs some work10:00
tpbTitle: GitHub - futaris/qemu at v4.0.0-litex (at
tpbTitle: litex/irq.h at master · enjoy-digital/litex · GitHub (at
futarisIRCcloudSo RISC-V just uses the machine interrupt, and triggers off an external PIC / PLIC ...10:23
futarisIRCcloudI guess we should make separate qemu models for each of the RISC-V processors that litex supports.10:23
futarisIRCcloud does look like fun.10:40
tpbTitle: litex/crt0-picorv32.S at master · enjoy-digital/litex · GitHub (at
keesjARRGGG this serdes is to complicated for my knowledge13:59
keesjI am mostly been looking at serwb (liteiclink) perhaps I need to get that one working first on arty or xsim14:02
somloso for wishbone .adr, there are only 30 bits, and the least significant two extra bits are implicitly assumed to be 0 -- is that correct?14:28
somlo* in LiteX's version of wishbone, specifically. The third-party IP I'm using has 32 bits, so I'd need to wire the least significant two of them to 0 myself, if I'm right about the above14:29
keesjwell. that would sounds ackward if 2 bits are not used why would you need to write them?14:31
somlokeesj: assuming w/o having thoroughly RTFM-ed: if a fully "agnostic" wb interface would have to allow individual bytes to be addressed, it would need 32 bits for the address; however, if our application (CPUs accessing 32 bits at once) guarantees that the least significant two will always be 0, we can just implicitly assume what they'd be, and not carry them around as explicit wires14:34
_florent_somlo: in LiteX wishbone adr is in words14:34
_florent_(4 bytes)14:34
somlo_florent_: thanks, just wanted to be 100% sure :)14:35
keesj is nice for learning about wishbone14:36
tpbTitle: Building a simple wishbone slave (at
keesjhmm same site but other page .. let me search14:36
somlokeesj: so since I'm using a third-party IP block for axi2wb, its wb side has 32 wires, since it's probably generic and can't assume 4-byte granularity14:36
somlokeesj: so I have to hard-wire those two bits to 0, and connect the rest of them to LiteX's 30 bits, and (fingers crossed), things will magically start working (famous last words) :)14:38
keesjlast words before the stuff exploded14:39
xobsThat 30-bit bus idea is weird.  I see why it's done that way, but it still throws me off a lot of the time.15:27
somloHmmm... Using to wrap Rocket before down-converting wishbone from 64->32 bits fails exactly the same as when I was using LiteX's own native axi2wb bridge :(16:22
tpbTitle: danstrother / dls_cores / source / axi / rtl / dlsc_axi_to_wb.v Bitbucket (at
somloand Dan Strother's bridge claims support for INCR bursting, so it's not that16:23
somlothe assertion is from deep within Rocket's sources: "Assertion failed at UserYanker.scala:54 assert (!out.r.valid || r_valid) // Q must be ready faster than the response"16:24
somlonow if only I could find some way to understand WTF "UserYanker" does in Rocket's AXI implementation :)16:24
keesjperhaps this was somebody else his last lines of code.. who knows19:14

Generated by 2.13.1 by Marius Gedminas - find it at!