Thursday, 2019-08-29

*** tpb has joined #tomu00:00
*** emeb has quit IRC00:01
*** rohitksingh has joined #tomu00:09
*** xkapastel has quit IRC00:29
*** xkapastel has joined #tomu00:41
*** rohitksingh has quit IRC02:41
*** xkapastel has quit IRC02:49
*** rohitksingh has joined #tomu04:03
*** mifune has quit IRC04:10
*** mifune has joined #tomu04:10
xobsssb: hooray!04:51
ssband another one: got riscv64-elf toolchain built and working from upstream sources. Appears to be straightforward with just one caveat (gcc_cv_as_leb128=no).05:46
xobsWhat's that do?05:50
ssbxobs, convinces gcc not to generate *leb128 assembler directives.  I dunno why, but if you try to compile from upstream gcc/binutils/newlib repo you'll get failure during newlib compilation05:53
ssbas there is no configuration option, one should just to export gcc_cv_as_leb128=no  to turn off corresponding configure snippet05:53
ssberror is "Error: non-constant .uleb128 is not supported" (during libgcc compilation, not newlib, sorry)05:55
*** rohitksingh has quit IRC06:11
ssbI see exactly the same bug mentioned in
xobsssb: if you're building for fomu, you should use march=rv32i and mabi=ilp3207:28
tntxobs: the vex doesn't do compressed ?07:28
xobstnt: it does, and I believe it's even enabled on fomu. No multiply instructions, though.07:29
tntAt first i had dismissed 'C' as not that useful, but with restricted SRAM and slow instruction fetch, its actually a nice boost in perf and space.07:30
tntI think I usually use rv32iac (even though I don't have atomics because AFAICT gcc will never generate those by itself, it's only inline asm).07:30
xobsHmm... That's good to know.  I'll have to take a look at it.07:34
ssbyeah, I got it.  Toolchain, once built, handles rv32i/ilp32 by default.08:11
MadHackerxobs: UP5k DSP slices no good for the multipliers?08:12
xobsMadHacker: they're fantastic for the multipliers, it's just that support isn't there yet.  There was a branch of yosys that had it, but I don't know of its status.08:13
xobsAlso, the up5k has 16-bit multipliers, which means there's a bit more support logic.08:13
xobsI really want to get M support in, as soon as the tooling gets there!08:13
MadHackerI was just looking at the SB_MAC16 datasheet for that. It claims it can do a straight 32-bit multiply (but that's 32x32 -> 32 not 32x32 -> 64)08:14
tntxobs: it's not a branch, it's merged AFAIK, just need to specify -dsp in synth_ice40  but I'm not sure the inferrence worked for the vex because of the way it was written.08:14
MadHackerCould well be lying tho. :)08:15
xobsMadHacker: It can do 16x16 -> 32, so you need to chain four of them together.  Which we can do!08:16
xobstnt: alright, that makes sense. I noticed yosys broke due to a missing header that seemed to imply it had gotten ice40 dsp inferrence.08:16
tntMadHacker: it can only do 16x16 -> 3208:16
MadHacker• Single 32-bit Multiply-Add/ Multiply-Sub.08:17
MadHacker(says the datasheet, which from reading the ports descriptions etc. seems like a lie, I admit)08:17
tntYeah, and they mean  x[31:0] += a[15:0] x b[15:0]08:17
MadHackerHm. Really awful wording.08:18
MadHackerRegardless - yep, so it'll do the job, just gonna need a lot of wiring around 'em.08:18
tntThat's why there is a diagram below :p08:18
xobsThe ice40 really seems like it was designed to run a 16-bit softcore.08:18
tntyup :)08:18
MadHackertnt: If you look at the diagram, you have four 16-bit input ports and a 32-bit output port. It's entirely plausible that 16+16 x 16+16 -> 32 would fit.08:19
tntOr you could do a 32b one using 16b slices.08:19
MadHackertnt: It doesn't, of course, but it could have. :)08:19
tntMadHacker: if you look at the diagram it has 4 8x8 bits multiply units ...08:19
MadHackerThink we're on about different diagrams.08:19
tntFigure 208:19
MadHackerRight, I was looking at figure 1.08:19
MadHackerFigure 2, yep, agree.08:20
tntOh yeah that's useless.08:20
tnt(fig 1 I mean)08:20
MadHackerI see that now.08:20
MadHackerAh well. I'll get to looking at stuff later anyway.08:21
MadHackerMy 6502 is running on the same design as the dummyusb stack, and I've stuck a maybe-it'll-work wishbone bridge on the 6502, so my next fun project is to try and get it to talk to the USB bits.08:21
MadHacker(real 6502 core not 6502-in-emulation)08:22
MadHackerFun times. :)08:22
xobsMadHacker: an interesting addition would be to take dummyusb and extend it to present a serial device to the fpga design.08:22
MadHackerxobs: That's roughly where I was going, but I have doubts about my talents extending to proper CDC in logic.08:23
MadHackerSo might have ended up with a single endpoint getting FIFO'd to the 6502.08:23
xobsThe CDC stuff is mostly getting the descriptors in there (which should be much easier now).08:23
tntThat's pretty much CDC08:23
MadHackerHaven't looked into it yet.08:24
*** im-tomu has left #tomu08:24
MadHackerBut if that's all it takes, then I'll throw a full BBC micro's worth of peripherals onto the 6502 and just make the OS switch input/output streams to the emulated serial on boot.08:24
tntas xobs pointed out, it's just getting descriptors right. After that you have one EP for input and one EP for output with no framing/no structure just raw data.08:24
*** im-tomu has joined #tomu08:24
tntPretty much all the control requests are optional.08:24
MadHackerI have LCs to burn.08:25
xobsYou can pretty much steal the descriptor directly from
tpbTitle: fomu-workshop/usb-desc.c at 60b9b46c5465bb44d6e62a390e4b88f5b10be5fc · im-tomu/fomu-workshop · GitHub (at
MadHackerThanks. :)08:27
xobstnt: that sigrok gtkwave decoder is so super useful. I'm using it with spi now.09:38
tntxobs: tx, glad to hear it's useful :p09:40
ssbhmm, interesting:  fomu with user bitstream without usb stack makes my laptop hang in bios at reboot11:16
ssbalso in linux at resume from suspend: everything stalls until I disconnect the device11:17
ssb(when foboot is active, everything is fine)11:17
xobsssb: sounds like the port you have it in doesn't have per-port TTs.11:17
ssb"per-port TTs" ?11:18
xobsAlso, maybe I should have it not drive the pins to 0 to disconnect it.  Rather, it should let the pins float.  I wonder how that would work with the pullup.11:18
xobsssb: Fomu is a USB FS device.  Presumably your ports are HS.  To prevent FS devices from slowing down the rest of the hub, they have Transaction Translators that go from HS to FS.11:19
ssbah, ok11:19
xobsHubs can either have one TT per port, or one per hub.  If it's per-hub, then each FS device is effectively bridged to all other FS/LS devices.11:19
ssbthis is a USB3 port btw (the only lone port on xiaomi mi 12" laptop)11:19
xobsSo if your keyboard is a LS device, and Fomu is driving the USB lines low, your keyboard will stop working.11:19
MadHackerxobs: Host has 15k pull-downs.11:22
MadHackerIf you're driving them into SE0, then presumably you're locking up the bus for anything else on the hub sans TTs.11:22
xobsMadHacker: you're right, the best thing to do is probably to tristate it.11:24
xobsIt's unfortunate that the ICE40 defaults to "weak pullup" on all outputs when unconfigured.11:24
ovfout of interest i just checked and apparently my laptop's internal keyboard and trackpoint are somehow on the same hub as the externally facing ports. what fun!11:26
MadHackerI can't find the specs on that weak pullup, oddly.11:28
tntMadHacker: it's specified as a current in uA11:31
MadHackerOh, that'll do. We know what the resistance on the PC side is, so we can work out what the effect on the pulldown will be from that.11:31
xobs"The default configuration of the I/O pins in a device prior to configuration is tri-stated with a weak pull-up11:31
xobsto VCCIO."11:31
MadHackertnt: Whereabouts, looking in the datasheet just now?11:31
xobsOh right.  They don't say the value.11:32
tntup to 128 uA11:32
tntSection 4.9 of the UltraPlus family manual11:33
tntI_pu Internal PIO Pull-up current.11:33
MadHackerIsn't that for the strong pull-up?11:33
tntovf: Usually I instanciate IOB that are explicitely tristated and with .PULLUP(0) when I do a design without USB but that will be in a usb port to make sure it's not detected in any way.11:34
tntMadHacker: ? There is no "strong" or "weak" pull up for the PIOs.11:34
MadHackerAnyway, let's run with it. 15K @ 128uA says 1.92 volts above zero. That's a pullup.11:34
MadHackerRight enough. Some of the xilinx parts do have exactly that distinction, was assuming the "weak pullup" for unconfigured was not the same as pin configured actively for pullup.11:35
tntI think some of the ice40 actually have configurable current, but not the UP AFAIK.11:36
MadHackerHm, page 25,  Unused I/Os are automatically blocked and the pull-up termination is disabled.11:36
tntYeah but ... that would be done by icecube ...11:37
MadHackerAs you say.11:37
MadHackerIsn't that the default for icestorm's bits too though?11:37
MadHackerOr do we need an SB_IO instance declared for all of them to do that?11:38
tntI don't think so. I definitely see a different behavior between manually creating a SB_IO that I force to tristate vs not doing that.11:38
MadHackerThat seems like a bug then, TBH?11:39
tntOh and having that pin at top level and not assigned to anything is forcing it to 0 (i.e. strong drive) IIRC (at least it used to).11:39
tntWell ... I usually kind of like unconnected pins not to be floating and toggling randomly the input circuits.11:40
MadHackerAnd ice40s have no keepers on the pins, I guess.11:40
MadHackerBut regardless - "does the same as the chip datasheet says" is generally the right default, no?11:40
tntnever heard anything about it (either positive or negative).11:41
tntMadHacker: we'd have to check icecube first. I think doing the same as icecube is genrally the goal for compat reason, and there is no telling if icecube matches the datasheet.11:41
MadHackerHm. Lattice's other parts (Mach etc.) have keepers, but I can't find anything on the datasheet for ice40.11:41
MadHackerThey oscillate between calling it sysIO (which would be the same thing as the other parts) and PIO in the ice40 datasheets.11:42
tntice40 is old silicon blue stuff.11:42
MadHackerAware. I have some siliconblue ice40s here.11:43
tnthehe. The lp1k devboard I have (and got just 1.5y ago) was still marked SB.11:43
MadHackerHX1K, same deal. :)11:43
MadHackerTBH I haven't checked what's marked on my big pile of HX8Ks, now I think about it.11:44
* MadHacker prods a novena.11:44
MadHackerNah, these are Lattice ones. :)11:44
MadHackerxobs: Out of curiosity, did you ever do anything with those novena ice40 boards?11:46
MadHackerHonestly I haven't used the ones I made for myself much, but they're fun and the build-compile-test cycle on them is lovely compare to most things.11:47
xobsMadHacker: I didn't, I'm sorry!11:47
MadHacker'sOK, I was just curious. :)11:47
MadHackerThe pi version of the Fomu is somewhat equivalent these days, I guess.11:48
MadHackerAlbeit the bus between is maybe a bit slower.11:48
ssbIIRC my HX8K on EVB is silicon blue12:06
xobsSpeaking of which, I'm working on a wishbone bridge that goes over SPI.  I updated the documentation on my simulation setup, which incorproates the sigrok decode stuff from tnt:
tpbTitle: spibone/sim at master · xobs/spibone · GitHub (at
MadHackerxobs: SPI to wishbone master, or wishbone<--->SPI<--->wishbone or?12:07
xobsMadHacker: The goal here is to be able to debug a Fomu over SPI, much like how we can debug it over USB.12:08
xobsThe trick is that I want to debug the new USB cores, which doesn't work so well if the USB connection isn't stable.12:08
xobsNormally one would use a UART debug bridge, but the UART core is too big to fit.  Hence, SPI.12:08
xobsThe primary usecase for now is on a Raspberry Pi for use with the EVT board.12:10
MadHackerSeems reasonable. I imagine the space saving is the baud-rate generator/clock recovery?12:12
xobsAs I understand it, yes.12:13
MadHackerOr is the UART core too smart for its own good?12:13
xobsNo, it's the clock recovery that's large.12:14
xobsSpeaking of SPI -- how do normal people drive SPI from their computers?12:17
MadHackerTo a first approximation normal people don't use SPI. It's an inside-a-device bus.12:18
xobsI usually use a Raspberry Pi, but if I were to add SPI support to `wishbone-tool`, how would I do that for non-Pi users?12:18
MadHackerArduino is most common, I guess?12:18
* MadHacker ponders.12:19
MadHackerIf I wanted SPI directly from my macbook, my go-to option would be an arduino.12:19
MadHackerAn FTDI cable as maybe option 2.12:19
tpbTitle: Bit-Bang FTDI USB-to-Serial Converters to Drive SPI Devices (at
MadHackerOh, I have a more on-brand option. Tomu.12:21
MadHackerJumper wires between the touchpads.12:21
xobsI had a feeling FTDI was the answer.  I think that's how they do it with e.g. icebreaker.12:22
xobsThough I had no end of difficulties with the Windows drivers.12:22
MadHackerYeah, in all honesty the FTDI option strikes me as widely available but horribly error-prone.12:23
MadHackerBetween fake FTDI devices, things that claim to be FTDI devices but are CP2102, and other variations, it's not a terribly consumer-friendly option if you're using it as anything more than a UART.12:24
*** ademski has joined #tomu12:59
*** emeb has joined #tomu13:38
*** EmilKarlson has quit IRC14:05
*** EmilKarlson has joined #tomu14:11
ssbtomu/fomu/somu/womu navigation links on are broken, it appears14:34
*** esclear has quit IRC14:42
*** esclear has joined #tomu14:58
ssbtristating usb pins seems to have working -- no bios hang at reboot, no linux hang at resume15:00
xobsssb: I think mithro was in the process of reworking things.15:03
*** rohitksingh has joined #tomu16:08
mithroxobs: I just pushed the major update to the tomu website16:13
mithroxobs: Still very WIP, but slowly getting there...16:13
tnt2408  vs 2048 typo16:21
shaprooh, I like the range of nifty *omu models16:40
*** rohitksingh has quit IRC16:40
*** rohitksingh has joined #tomu16:44
*** rohitksingh has quit IRC17:32
*** columna1 has joined #tomu18:28
*** columna1 has quit IRC18:31
*** rohitksingh has joined #tomu19:07
*** ademski has quit IRC19:27
*** ademski has joined #tomu19:38
*** rohitksingh has quit IRC19:50
MadHackermithro, xobs: On your list of *omu, can I place a request now for Nomu, with NFC?20:49
MadHackerSince I think it's the one that best fits the Somu etc. stuff too. NFC opens up other options.20:49
MadHacker(Yes, I'll try and get something to work on Fomu for that When I Get Time(TM), but still)20:50
ssbMadHacker, see also slide 101 ("Bomu") at CCCamp slides:
tpbTitle: Fomu - An FPGA which fits in your USB port. | I’m Tomu - A tiny ARM microprocessor which fits in your USB port. (at
MadHackerI saw that, but bluetooth and NFC aren't the same thing (sadly).20:56
ssbit says nRF52840 and NFC and some quick googling suggests that it is there20:58
MadHackerApologies then, I clearly didn't read closely enough!20:59
MadHackerYep, you're right. I'm sorry, I should have looked more closely.20:59
ssbheh, I believe that I constantly miss half of useful information from whatever I read )21:00
MadHackerI'm not normally too bad, but presentation slides are bad for me. Too much urge to rattle through them.21:01
* MadHacker starts work on USB CDC for the 6502 thingy.21:01
* ssb 's personal preference would be Fomu with (much) more RAM and flash21:01
ssbthough looking at the PCB I just don't believe that there is any space for 8Mb SRAM chip )21:02
MadHackerWell, a USB C one would have to stick out a bit more anyway. Maybe room in one of those. :)21:02
ssbnevertheless, Fomu is absolutely outstanding tiny piece of hardware and software is a masterpiece21:04
ssbvery well done, thank you guys!21:05
*** ademski has quit IRC21:30
mithroThe specs table pulls from the spreadsheet at
tpbTitle: Tomu Family Specifications - Google Sheets (at
*** rohitksingh has joined #tomu22:11
*** rohitksingh has quit IRC22:30
shaprI want a fomu with an ecp5!22:31
mithroshapr: To my knowledge they don't make an ECP5 chip small enough?22:32
shaprsounds like I want a pony too :-)22:32
* shapr checks ecp5 sizes22:32
shapraccording to the LFE5U-85 is 10x10mm but from what I've read the USB plug is 12mm wide, that doesn't leave much room22:45
tpbTitle: ECP5 / ECP5-5G - Lattice Semiconductor (at
*** xkapastel has joined #tomu22:46
*** rohitksingh has joined #tomu22:56
*** rohitksingh has quit IRC23:24

Generated by 2.13.1 by Marius Gedminas - find it at!