Friday, 2019-04-19

*** tpb has joined #litex00:00
futarisIRCcloudmithro / _florent_ :
mithrofutarisIRCcloud: Yes, I talk to the AntMico team frequently01:28
futarisIRCcloudI want to get Linux and Zephyr running on my Arty board this weekend. _florent_ , Do I just have to update the Vexrisc.v like antmicro did? ...01:41
mithrofutarisIRCcloud: Not sure01:44
futarisIRCcloudmithro: Did the Zephyr stuff go into litex-buildenv?01:45
mithrofutarisIRCcloud: Not yet01:57
*** futarisIRCcloud has quit IRC05:16
xobsI mentioned this in #tomu, but I managed to a Wishbone bridge added to the Fomu USB stack, so now I'm adding USB support to litex_server. That's the last piece to getting real-time gdb support for the vexriscv softcore over USB.05:37
_florent_Hi xobs, i saw it yesterday in #tomu, great!05:38
keesjI Have a tomu ordered a fomu and finished my up5k based design yesterday.. I now need to implement flashing over usb. where .. is the fomu stack?06:24
tpbTitle: GitHub - im-tomu/foboot: Bootloader for Fomu (at
keesjI see.. the protocol is mostly implemented in c06:33
*** futarisIRCcloud has joined #litex09:21
_florent_futarisIRCcloud: here is the updated procedure to run Zephyr: (i created a pull request to merge it to antmicro's repo)09:27
tpbTitle: GitHub - enjoy-digital/zephyr-on-litex-vexriscv (at
futarisIRCcloud_florent_: Thanks. I assume it works fine for you? Did you try using ethernet to load the binary over tftp (in hardware)?09:46
tpbTitle: LiteEth driver · Issue #2 · antmicro/litex-linux-riscv · GitHub (at
xobskeesj I didn't see this here, sorry.  Yes, for now I just use DFU because it's easy and only requires one endpoint.10:07
xobsEventually we'd like to implement UF2, but first things first.10:08
xobsSpeaking of which, right now I'm running into this annoying thing in that the Wishbone bus locks up when I put the CPU into reset.  That shouldn't happen.10:08
_florent_futarisIRCcloud: i tested only tested in simulation with
tpbTitle: GitHub - enjoy-digital/zephyr-on-litex-vexriscv (at
_florent_futarisIRCcloud: do you have trouble getting netboot working on hardware?10:09
futarisIRCcloudI haven't tested it yet. I will let you know if it works (or not).10:09
xobsThis is strange.  I can write the "CPU HALT" bit all day, but as soon as I set "CPU HALT", I can read from Wishbone exactly once.  The second time I read, the connection hangs.11:25
xobsHowever, I /can/ halt the CPU, read exactly once, then unhalt the CPU, and it will keep on working.11:26
xobsPerhaps this is a vexriscv-related issue.  Weird, though, that I don't see this happen with the UART bridge.11:28
xobsHmm... I wonder if I'm not misunderstanding the vexriscv "cmd_ready" port.  Maybe that's only applicable to injected instructions, and not applicable to things like "halt".12:00
keesjWell. I am wondering what you should expect. the litex "system" only supports a single cpu (doing the wb master)12:14
keesjunless there is a multi-master wishbone crossbar it might just work as designed[tm].12:15
keesjSomewhere that would be a bit supprizing because it would mean dma or similar will be hard to implement but still.12:15
xobskeesj: it supports multiple masters, I thought. Or maybe I just got lucky in the past.12:34
xobsOrdinarily I use Ethernet or the UART to debug the CPU, both of which are Wishbone masters.12:34
_florent_xobs: yes it supports multi-masters12:35
_florent_xobs: are you able to run your code on a larger FPGA where you would be able to add debug in it around the SoC you are building? (standalone litescope for example)12:36
xobs_florent_: that would be wonderful. unfortunately that would mean moving to an Artix board, which would change an awful lot. It's really a shame that the top-of-the-line ICE40UP part only has 5K LUTs.12:37
futarisIRCcloudxobs / _florent_ : Is this ok?
tpbTitle: foboot/ at wishbone-debug · im-tomu/foboot · GitHub (at
futarisIRCcloudI didn't see anything like:
tpbTitle: litex/ at master · enjoy-digital/litex · GitHub (at
_florent_xobs: ah ok i see...12:40
xobsfutarisIRCcloud: I adapted that bit from
tpbTitle: litex-buildenv/ at master · timvideos/litex-buildenv · GitHub (at
_florent_xobs: so the issue only happens if you do your access while the CPU is running?12:41
xobs_florent_: no, weirdly, it only happens when I HALT the CPU.  I can read and write all of RAM just fine when the CPU is running.12:42
xobsI can manipulate CSRs all day and it works fine.  I can scribble over RAM and it's fine.  The instant I set the "haltIt" bit on the CPU debug bus, I get exactly one "read", and then I can't read any more.12:43
xobsIt seems as though I can write, though.12:43
_florent_xobs: sorry i'm not really aware of the architecture, but the CPU is not involved in the Wishbone bridge right?12:43
xobsIt looks like I can write because eventually I can set the "clearHaltIt" bit and it comes back to life.12:43
futarisIRCcloudI don't see anything about wishbone timeouts ...12:44
xobs_florent_: no, it's not involved in Wishbone, aside from the fact that it's a wishbone master.12:44
_florent_xobs: and when the wishbone is stuck, the CPU is still running fine?12:45
xobs_florent_: I think the CPU is halted.12:46
xobsOkay, I just verified: when the CPU is halted, it's only reads that break.  Writes still work fine.12:46
_florent_xobs: ok interesting, so it means ack are still generated for writes but no longer for reads12:47
xobsI can't debug the system yet, but I do have an LED that's using the ICE40 LED controller hard macro.  So it's pulsing.12:47
_florent_xobs: do you have external pins you can use? that would be intesting to look at the wishbone stb/ack pins12:47
xobsI have the "LED Enable" signal hooked up to a CSR, and I can still toggle that even when it's in this state.  So that's how I know that writes work but reads do not.12:48
xobs_florent_: I do have external pins.  That's a good idea.  I'll give that a try.12:48
_florent_ok, i'm just going to look at the code to see what signal we would output12:48
_florent_in the first time, that would be interesting to confirm that for write we still have the wishbone ack, but not for reads12:49
xobsWhoops.  I didn't realize I've been committing to my branch and not mithro's fork.12:51
xobsAnyway, the bridge in question is at
tpbTitle: valentyusb/ at master · xobs/valentyusb · GitHub (at
xobsI really like the "_ce" pattern that _florent_ uses in state machines.12:52
_florent_xobs: when you set the clearHaltIt, both CPU and wishbone come back to life or only the CPU?12:58
xobs_florent_: both come back to life.12:58
xobsMaking me think the CPU is doing something strange with Wishbone.  But it's odd that I'm only seeing it on the USB bridge, and not on the other bridges I've tried.12:58
_florent_ah yes, maybe the CPU is halt when doing a wishbone access13:01
_florent_so you'll be able to do only one access with the bridge, but then the round robin will lock...13:01
_florent_but that doesn't explain why writes are working...13:02
_florent_first thing would be to expose the stb/ack on this:
tpbTitle: valentyusb/ at master · xobs/valentyusb · GitHub (at
_florent_just to see if you really have the ack for writes, and not for reads, regarding the results we could connect the debug pins to something else13:05
xobs_florent_: that's good thinking! I have it hooked up now.  Let me get it into the failure state and see.13:06
xobsOkay, now /that/ is interesting.  Even in the "failed" state, STB/ACK still fire on reads.  Which means something else is holding it back.  That's good, and it points back to something in my bridge code.13:08
xobsMaybe it has something to do with the event/interrupts?13:09
_florent_good for the stb/ack results13:10
_florent_are you using event/interrupts in your wishbone bridge?13:11
xobsno event/interrupts in the wishbone bridge, but they are used in the module that it's attached to.13:12
_florent_can you point to the code for that?13:14
xobs_florent_: I don't entirely understand it, but the event stuff happens at
tpbTitle: valentyusb/ at master · xobs/valentyusb · GitHub (at
_florent_xobs: ah ok, but isn't the CPU managing that? (and halting it would stop this?)13:17
xobsThat's the theory.13:17
xobsThe idea is that the `debug_packet_detected` signal would override normal behavior.13:18
xobsAnd it's almost doing that.  Except when the CPU is halted.13:18
_florent_so when it's hanging,  the read commands still arrives to the wishbone?13:21
_florent_maybe we should focus on the difference between writes and reads13:22
_florent_for a write, do you have a respond from the USB? or is it just posted?13:22
xobsThat's a good point.  Actually, that's a super good point.13:26
xobsWhen the CPU is halted, bus traffic is cut in half.13:26
xobsSo it responds quicker.13:26
xobsWrites look for a USB packet start, but reads just look for the end.  Maybe if I change it so that it looks for a start first, that'll fix it.13:26
_florent_or maybe debug_packet_detected is not valid for the entire transaction?13:29
xobsAnd with that, it works.13:33
xobs_florent_: you're a genius.13:33
_florent_xobs: what have you changed? the duration of debug_packet_detected?13:34
xobsNo, all I did was change the state machine so that, after a successful read, it first waits for a USB packet to *start*.13:34
xobsPreviously it was waiting for the packet to *end*, which works just fine if your read took long enough that the previous packet finished.13:34
xobsIf the bus is busy, then the read can take long enough for the previous packet to finish.  Then we raise the "ACK" flag, and the next packet starts.13:35
xobsIf the bus is idle, then the response comes way before the packet finishes, so I was raising the "ACK" flag.  When I got the "end packet" flag, that flag was actually for the "address" packet, and not for the "did you get the address packet?" token.13:37
xobsI guess the moral of the story is that an idle bus is super fast.13:38
_florent_ok, cool if it works :)13:39
xobs_florent_: this is all I changed:
tpbTitle: usbwishbonebridge: fix the case where the bus is idle · xobs/[email protected] · GitHub (at
_florent_xobs: just curious, how much time does it take to generates your design?13:40
xobsLet's find out.  Note that my computer is 25% loaded with a game running in the background.13:42
xobs290 seconds13:46
_florent_ok thanks13:52
futarisIRCcloudThe best / worse bugs are always small changes like that...13:53
xobsWell that's fun.  Now I can debug the USB connection over the USB connection.  Whee!13:56
futarisIRCcloudxobs: Lol.13:56
futarisIRCcloudDid you check what the power usage is when the CPU is running vs stopped?13:57
xobsfutarisIRCcloud: I haven't, no.  Mostly because I suspect the FPGA power usage is in the ~10 mA range, and the LED/regulators probably burn more than that.13:58
xobs_florent_: I created a PR for the change.  I tried to make it small.  I'd like to document the protocol.  Where should I do that?14:07
xobsAlso, it tries to reconnect to the USB device.  That's important because during program startup, it resets the USB connection.  So I made it transparently reconnect.14:08
_florent_xobs: thanks, maybe you can document the protocol in the comm_usb file?14:18
xobs_florent_: sure. let me make some changes first.14:28
*** futarisIRCcloud has quit IRC17:01
*** futarisIRCcloud has joined #litex23:48

Generated by 2.13.1 by Marius Gedminas - find it at!