Wednesday, 2019-05-22

*** tpb has joined #tomu00:00
*** emeb has quit IRC00:35
xobsssb: mithro is correct. For the Hacker boards, I think there is GND and Power on those pads, but for Production we edge-plate them so they're easier to hit.  So for Production you have no source for GND or +3.3V.01:20
*** Asara has left #tomu01:21
*** rohitksingh has joined #tomu03:55
*** rohitksingh has quit IRC04:14
*** rohitksingh_work has joined #tomu04:29
*** rohitksingh has joined #tomu05:12
ssbmithro, xobs: thanks! That is great.05:31
xobsssb: :D I'm really looking forward to seeing what people do with them.05:32
ssbfor me that will depend on how much data rate the usb softcore will be able sustain )05:35
*** devanagram has quit IRC05:36
xobsThat depends on how you use it.  I'd like to do a version of the softcore that doesn't require a CPU, for example.  It shouldn't be too difficult, since the rest of the pieces are all validated.05:37
xobsThat would be nice and deterministic, and should sustain a high throughput.  Relatively speaking, of course.05:39
*** ukembedded has quit IRC05:39
*** ukembedded has joined #tomu05:41
*** devanagram has joined #tomu05:42
*** im-tomu has left #tomu05:52
*** im-tomu has joined #tomu05:52
polloxobs: hey, I've been unable to build micropython for the fomu: https://share.riseup.net/#vJLqV_cY7f9gmwDWSs2fMw06:06
tpbTitle: share.riseup.net (at share.riseup.net)06:06
polloShould I open a bug report?06:06
polloI'm not sure if you folks intent to work on it or if it was just a proof of concept for now06:06
xobspollo: right now it's a proof-of-concept. Is this on the Raspberry Pi image?06:07
polloYeah06:07
xobsInteresting. That makes it super reproducable then :)06:07
xobsI've finally settled on an approach that I think is easy-yet-robust, and we'll have to see just how doable it is.06:08
polloI used the latest git commit though (not the latest release) if that matters06:08
xobsBut the inital batch of Fomu units will ship with the DFU bootloader.06:08
polloI've been able to make that work (foboot) though :906:09
xobsI'm going to work on a more advanced MSC-based bootloader, which we'll release when it's ready.  The DFU bootloader will still be the "failsafe" one, but once the "main" bootloader is available it'll be more for recovery.06:09
polloAh, interesting06:09
xobsThe "main" bootloader will read the SPI flash as a FAT12 filesystem, starting at offset 0x40000.  It'll support the concept of "interpreters", one of which will be Micropython.06:10
xobsSo micropython will be just a program on the FAT12 filesystem, and it'll interpret your .py file.06:10
xobsAs a result, micropython support will have to come after the main bootloader support.06:11
pollosure, I was mainly trying to test all the things to help out06:33
xobsI appreciate it!  I'll look at it now.06:34
xobsMy guess is that the toolchain I built doesn't have rv32i support.06:34
xobsI think that's it, yeah.  Initially I wanted to add a multiply unit, but it ended up being too big, so we're shipping without one.06:40
xobsOnce we have the usb core optimized, and once nextpnr gets better at inferring 17-bit multplies, we'll be able to move back to rv32im.06:41
xobsBut for now, I will rebuild the toolchain for rv32i (i.e. no multiply unit), which should fix that problem.06:42
tntxobs: huh ? I thought all toolchain supported going to rv32i with proper flags ( -march=rv32i -mabi=ilp32 )06:53
xobstnt: that was my guess, but the issue reported by pollo appears to be that the standard libraries we ship are for rv32im only.06:54
tntoh, ok. Yeah looking at both toolchain I have they ship with a bunch of variants of the standard libs.06:56
xobsYeah, I built the riscv toolchain as non-multilib, because multilib is complicated and takes more time.07:02
tntbtw, I've been comparing the vex and picorv32. I was excpecting the vex to be much faster but in the end, not so much :/  It takes a bit less cycles per instruction on average, but it also has a lower fmax.07:09
xobstnt: interesting. is this on ice40?07:14
tntyes on the up5k.07:15
tntThat was the 'min' variant. The variant with icache is a bit faster but consumes also quite a bit more resources.07:16
xobsthere are a few knobs we can tune.  From what I gather the ones in the "Vexriscv-Verilog" directory are all rather old.  But maybe not.  I've been trying to get it as small as possible while still being reasonably compliant.07:17
tntThey've been updated recently because I found an issue when testing :)  (it only affected simulation though)07:18
xobsCompiling toolchains is so very difficult.08:03
*** rohitksingh has quit IRC08:15
*** rohitksingh has joined #tomu08:47
*** AmosSam has left #tomu09:33
*** AmosSam has joined #tomu09:39
*** rohitksingh has quit IRC09:39
*** rohitksingh has joined #tomu10:05
*** rohitksingh has quit IRC10:21
*** rohitksingh_work has quit IRC12:51
*** rohitksingh_work has joined #tomu12:56
*** rohitksingh_work has quit IRC13:10
tntA bit more testing: Switching from wishbone to a pipelined bus for instruction fetch and enabling static branch prediction seems to have very positive effects. ~ 150 more LCs but I can probably live with that. Need to do a more complete system and try it on actual hw.13:51
*** rohitksingh has joined #tomu14:09
*** emeb has joined #tomu16:02
*** rohitksingh has quit IRC16:17
*** rohitksingh has joined #tomu16:49
*** rohitksingh has quit IRC17:12
*** rohitksingh has joined #tomu17:33
*** rohitksingh has quit IRC17:42
*** rohitksingh_ has joined #tomu17:42
*** AmosSam has left #tomu17:52
*** AmosSam has joined #tomu18:19
*** rohitksingh_ has quit IRC18:25
*** rohitksingh has joined #tomu19:11
*** rohitksingh has quit IRC19:16

Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!