Thursday, 2020-10-15

*** tpb has joined #tomu00:00
mithro@tcal-x -- I think the general advice has been to pull the Fomu out and put it back in again...01:56
mithro@xobs - Do you have any idea about the above issue?01:58
xobseforth doesn't meet timing (see so it's not surprising it doesn't work.02:01
xobsFor Micropython... it looks like what's going on is it's going back to foboot when they unplug Fomu and plug it back in, which is also expected behavior. Run `dfu-util -e` to run the program that's already on the device without needing to reload it.02:02
*** bluebugs has quit IRC02:03
mithroxobs: Want to reply in that issue above?03:42
xobsSure, done03:45
im-tomu[tcal-x] Thanks xobs, I couldn't figure out what he was doing.03:58
*** dwg has quit IRC04:10
*** dwg has joined #tomu04:11
*** futarisIRCcloud has quit IRC04:13
*** flag has quit IRC04:44
*** flag has joined #tomu04:50
*** im-tomu has left #tomu05:18
*** im-tomu has joined #tomu05:19
*** cdmatter has quit IRC07:02
*** cdmatter has joined #tomu07:03
*** mtretter has joined #tomu07:04
im-tomu[umarcor] @xobs is that true for HDL designs too?11:34
im-tomu[umarcor] Typically, boards allow configuring the FPGAs directly (volatile) or programming a sibling SPI memory. The default in the Icestick and such is for the memory to be programmed. Then, each time the user plugs the board again, the last design is used.11:37
im-tomuThe behaviour of Fomu feels opposite: it always loads the bootloader, regardless of the last programmed design (before shutting down).11:37
im-tomu[umarcor] If the bitstream of the last design remains in the board, even after turning it off, the touch buttons might be used for deciding the boot design. That is, the bootloader is loaded and, if a touch button is active, y directly reloads the last design. I the touch button is not active, the current behaviour is preserved.11:40
im-tomu[umarcor] That'd feel similar to "warm boot".11:41
*** thaytan has quit IRC11:57
*** thaytan has joined #tomu11:58
xobsThe problem with that is we don't have a good, reliable capacitive design. I had some experiments, but reliable captouch is hard.12:09
xobsAlso, the way you insert it, you're always pressing on the touchpads, so it would always go into the bootloader anyway.12:09
xobsOnce an HDL design runs, there's no way to set up a watchdog to have it go back to the bootloader. So if you load a design that doesn't work, you've bricked your board.12:10
xobsThere's a patch in `master` that hasn't been released yet sets a timeout to auto-boot a loaded design.12:12
im-tomu[umarcor] @xobs, what do you mean with bricking the board if an HDL doesn't work? My understanding is that, no matter which Verilog/VHDL source I use, when I plug the board again, the reference design (bootloader) is loaded. Hence, the HDL is discarded, even if it does not work, isn't it?12:19
xobsThat's how it works now, yes. But if it loaded the last design automatically, as you're suggesting, then it would be bricked.12:19
im-tomu[umarcor] Oh, ok, It's just the translation of "bricked". I take it as "unrecoverably bricked". You mean "temporaly bricked".12:20
xobsIt's reasonably challenging to solder to the 6 pins required to reflash SPI. If someone had a test jig with pogo pins, they could reflash it, but that's not very common.12:21
im-tomu[umarcor] Then the logic might be inverted. If any of the touchpads are active when plugged, it takes the bootloader. For HDL development,  using a short male-female USB cable should work.12:25
im-tomu[umarcor] In fact, instead of inserting/removing the board continuously, I think it's desirable to use a cable or USB hub with a swtich.12:26
im-tomu[umarcor] Overall, I'd like the UX experience for users learning HDLs be closer to those learning micropython, C, etc. for RISCV.12:30
xobsIt seems like that would require additional hardware on the part of the user, which we can't assume they have.12:32
xobsI think the bigger issue now is the lack of a good USB stack that works with pure Verilog.12:33
xobsSomething akin to the stack that was used with the forth interpreter, except something that meets timing.12:33
xobsWould do for you?12:35
im-tomu[umarcor] Indeed, I'm good with supporting this use case as something specific, or in a fork. That is, I agree that we can't assume users to have additional hardware. For those, the current solution should work.12:38
im-tomu> I think the bigger issue now is the lack of a good USB stack that works with pure Verilog.12:38
im-tomuAgree. On the one hand, I'd like to have an HDL USB-UART core that users can instantiate as if it was a hard IP. I'll look into LUNA for that. On the other hand, that'd allow communication between HDL designs and the PC, but it would not solve the plug/unplug issue. Having that feature in the same IP would be so useful.12:38
im-tomu[umarcor] > Would do for you?12:39
im-tomuIt seems quite close. Let me have a better look!12:39
xobsIt hasn't been released yet, but with sufficient testing perhaps we can release
*** _stew_ has quit IRC15:03
*** _stew_ has joined #tomu15:04
im-tomu[umarcor] It seems that migen is added as a submodule twice: Would it make sense to remove ?15:49
*** mtretter has quit IRC16:16
*** wrtlprnft has quit IRC16:52
*** wrtlprnft has joined #tomu16:53
*** CarlFK has joined #tomu17:14
*** FxPape has quit IRC18:28
*** CarlFK has quit IRC19:07
*** CarlFK has joined #tomu22:03

Generated by 2.17.2 by Marius Gedminas - find it at!