| *** tpb has joined #tomu | 00:00 | |
| *** emeb has quit IRC | 00:01 | |
| *** rohitksingh has joined #tomu | 00:09 | |
| *** xkapastel has quit IRC | 00:29 | |
| *** xkapastel has joined #tomu | 00:41 | |
| *** rohitksingh has quit IRC | 02:41 | |
| *** xkapastel has quit IRC | 02:49 | |
| *** rohitksingh has joined #tomu | 04:03 | |
| *** mifune has quit IRC | 04:10 | |
| *** mifune has joined #tomu | 04:10 | |
| xobs | ssb: hooray! | 04:51 |
|---|---|---|
| ssb | and 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 |
| xobs | What's that do? | 05:50 |
| ssb | xobs, 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 compilation | 05:53 |
| ssb | as there is no configuration option, one should just to export gcc_cv_as_leb128=no to turn off corresponding configure snippet | 05:53 |
| ssb | error is "Error: non-constant .uleb128 is not supported" (during libgcc compilation, not newlib, sorry) | 05:55 |
| *** rohitksingh has quit IRC | 06:11 | |
| ssb | I see exactly the same bug mentioned in gcc.gnu.org/PR87690 | 07:26 |
| xobs | ssb: if you're building for fomu, you should use march=rv32i and mabi=ilp32 | 07:28 |
| tnt | xobs: the vex doesn't do compressed ? | 07:28 |
| xobs | tnt: it does, and I believe it's even enabled on fomu. No multiply instructions, though. | 07:29 |
| tnt | At 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 |
| tnt | I 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 |
| xobs | Hmm... That's good to know. I'll have to take a look at it. | 07:34 |
| ssb | yeah, I got it. Toolchain, once built, handles rv32i/ilp32 by default. | 08:11 |
| MadHacker | xobs: UP5k DSP slices no good for the multipliers? | 08:12 |
| xobs | MadHacker: 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 |
| xobs | Also, the up5k has 16-bit multipliers, which means there's a bit more support logic. | 08:13 |
| xobs | I really want to get M support in, as soon as the tooling gets there! | 08:13 |
| MadHacker | I 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 |
| tnt | xobs: 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 |
| MadHacker | Could well be lying tho. :) | 08:15 |
| xobs | MadHacker: It can do 16x16 -> 32, so you need to chain four of them together. Which we can do! | 08:16 |
| xobs | tnt: 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 |
| tnt | MadHacker: it can only do 16x16 -> 32 | 08: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 |
| tnt | Yeah, and they mean x[31:0] += a[15:0] x b[15:0] | 08:17 |
| MadHacker | Hm. Really awful wording. | 08:18 |
| MadHacker | Regardless - yep, so it'll do the job, just gonna need a lot of wiring around 'em. | 08:18 |
| tnt | That's why there is a diagram below :p | 08:18 |
| xobs | The ice40 really seems like it was designed to run a 16-bit softcore. | 08:18 |
| tnt | yup :) | 08:18 |
| MadHacker | tnt: 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 |
| tnt | Or you could do a 32b one using 16b slices. | 08:19 |
| MadHacker | tnt: It doesn't, of course, but it could have. :) | 08:19 |
| tnt | MadHacker: if you look at the diagram it has 4 8x8 bits multiply units ... | 08:19 |
| MadHacker | Think we're on about different diagrams. | 08:19 |
| tnt | Figure 2 | 08:19 |
| MadHacker | Right, I was looking at figure 1. | 08:19 |
| MadHacker | Figure 2, yep, agree. | 08:20 |
| tnt | Oh yeah that's useless. | 08:20 |
| tnt | (fig 1 I mean) | 08:20 |
| MadHacker | Aye. | 08:20 |
| MadHacker | I see that now. | 08:20 |
| MadHacker | Ah well. I'll get to looking at stuff later anyway. | 08:21 |
| MadHacker | My 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 |
| MadHacker | Fun times. :) | 08:22 |
| xobs | MadHacker: an interesting addition would be to take dummyusb and extend it to present a serial device to the fpga design. | 08:22 |
| MadHacker | xobs: That's roughly where I was going, but I have doubts about my talents extending to proper CDC in logic. | 08:23 |
| MadHacker | So might have ended up with a single endpoint getting FIFO'd to the 6502. | 08:23 |
| xobs | The CDC stuff is mostly getting the descriptors in there (which should be much easier now). | 08:23 |
| tnt | That's pretty much CDC | 08:23 |
| MadHacker | Haven't looked into it yet. | 08:24 |
| *** im-tomu has left #tomu | 08:24 | |
| MadHacker | But 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 |
| tnt | as 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 #tomu | 08:24 | |
| tnt | Pretty much all the control requests are optional. | 08:24 |
| MadHacker | I have LCs to burn. | 08:25 |
| xobs | You can pretty much steal the descriptor directly from https://github.com/im-tomu/fomu-workshop/blob/60b9b46c5465bb44d6e62a390e4b88f5b10be5fc/riscv-usb-cdcacm/src/usb-desc.c#L98 | 08:25 |
| tpb | Title: fomu-workshop/usb-desc.c at 60b9b46c5465bb44d6e62a390e4b88f5b10be5fc · im-tomu/fomu-workshop · GitHub (at github.com) | 08:25 |
| MadHacker | Thanks. :) | 08:27 |
| xobs | tnt: that sigrok gtkwave decoder is so super useful. I'm using it with spi now. | 09:38 |
| tnt | xobs: tx, glad to hear it's useful :p | 09:40 |
| ssb | hmm, interesting: fomu with user bitstream without usb stack makes my laptop hang in bios at reboot | 11:16 |
| ssb | also in linux at resume from suspend: everything stalls until I disconnect the device | 11:17 |
| ssb | (when foboot is active, everything is fine) | 11:17 |
| xobs | ssb: sounds like the port you have it in doesn't have per-port TTs. | 11:17 |
| ssb | "per-port TTs" ? | 11:18 |
| xobs | Also, 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 |
| xobs | ssb: 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 |
| ssb | ah, ok | 11:19 |
| xobs | Hubs 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 |
| ssb | this is a USB3 port btw (the only lone port on xiaomi mi 12" laptop) | 11:19 |
| xobs | So if your keyboard is a LS device, and Fomu is driving the USB lines low, your keyboard will stop working. | 11:19 |
| MadHacker | xobs: Host has 15k pull-downs. | 11:22 |
| MadHacker | If you're driving them into SE0, then presumably you're locking up the bus for anything else on the hub sans TTs. | 11:22 |
| xobs | MadHacker: you're right, the best thing to do is probably to tristate it. | 11:24 |
| xobs | It's unfortunate that the ICE40 defaults to "weak pullup" on all outputs when unconfigured. | 11:24 |
| ovf | out 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 |
| MadHacker | I can't find the specs on that weak pullup, oddly. | 11:28 |
| tnt | MadHacker: it's specified as a current in uA | 11:31 |
| MadHacker | Oh, 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-up | 11:31 |
| xobs | to VCCIO." | 11:31 |
| MadHacker | tnt: Whereabouts, looking in the datasheet just now? | 11:31 |
| xobs | Oh right. They don't say the value. | 11:32 |
| tnt | up to 128 uA | 11:32 |
| tnt | Section 4.9 of the UltraPlus family manual | 11:33 |
| tnt | I_pu Internal PIO Pull-up current. | 11:33 |
| MadHacker | Isn't that for the strong pull-up? | 11:33 |
| tnt | ovf: 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 |
| tnt | MadHacker: ? There is no "strong" or "weak" pull up for the PIOs. | 11:34 |
| MadHacker | Anyway, let's run with it. 15K @ 128uA says 1.92 volts above zero. That's a pullup. | 11:34 |
| MadHacker | Right 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 |
| tnt | I think some of the ice40 actually have configurable current, but not the UP AFAIK. | 11:36 |
| MadHacker | Hm, page 25, Unused I/Os are automatically blocked and the pull-up termination is disabled. | 11:36 |
| MadHacker | (3.1.9) | 11:36 |
| tnt | Yeah but ... that would be done by icecube ... | 11:37 |
| MadHacker | As you say. | 11:37 |
| MadHacker | Isn't that the default for icestorm's bits too though? | 11:37 |
| MadHacker | Or do we need an SB_IO instance declared for all of them to do that? | 11:38 |
| tnt | I 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 |
| MadHacker | That seems like a bug then, TBH? | 11:39 |
| tnt | Oh 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 |
| tnt | Well ... I usually kind of like unconnected pins not to be floating and toggling randomly the input circuits. | 11:40 |
| MadHacker | And ice40s have no keepers on the pins, I guess. | 11:40 |
| MadHacker | But regardless - "does the same as the chip datasheet says" is generally the right default, no? | 11:40 |
| tnt | never heard anything about it (either positive or negative). | 11:41 |
| tnt | MadHacker: 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 |
| MadHacker | Hm. Lattice's other parts (Mach etc.) have keepers, but I can't find anything on the datasheet for ice40. | 11:41 |
| MadHacker | They oscillate between calling it sysIO (which would be the same thing as the other parts) and PIO in the ice40 datasheets. | 11:42 |
| tnt | ice40 is old silicon blue stuff. | 11:42 |
| MadHacker | Aye. | 11:43 |
| MadHacker | Aware. I have some siliconblue ice40s here. | 11:43 |
| tnt | hehe. The lp1k devboard I have (and got just 1.5y ago) was still marked SB. | 11:43 |
| MadHacker | HX1K, same deal. :) | 11:43 |
| MadHacker | TBH 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 | |
| MadHacker | Nah, these are Lattice ones. :) | 11:44 |
| MadHacker | xobs: Out of curiosity, did you ever do anything with those novena ice40 boards? | 11:46 |
| MadHacker | Honestly 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 |
| xobs | MadHacker: I didn't, I'm sorry! | 11:47 |
| MadHacker | 'sOK, I was just curious. :) | 11:47 |
| MadHacker | The pi version of the Fomu is somewhat equivalent these days, I guess. | 11:48 |
| MadHacker | Albeit the bus between is maybe a bit slower. | 11:48 |
| ssb | IIRC my HX8K on EVB is silicon blue | 12:06 |
| xobs | Speaking 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: https://github.com/xobs/spibone/tree/master/sim | 12:06 |
| tpb | Title: spibone/sim at master · xobs/spibone · GitHub (at github.com) | 12:06 |
| MadHacker | xobs: SPI to wishbone master, or wishbone<--->SPI<--->wishbone or? | 12:07 |
| xobs | MadHacker: The goal here is to be able to debug a Fomu over SPI, much like how we can debug it over USB. | 12:08 |
| xobs | The 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 |
| xobs | Normally one would use a UART debug bridge, but the UART core is too big to fit. Hence, SPI. | 12:08 |
| xobs | The primary usecase for now is on a Raspberry Pi for use with the EVT board. | 12:10 |
| MadHacker | Seems reasonable. I imagine the space saving is the baud-rate generator/clock recovery? | 12:12 |
| xobs | As I understand it, yes. | 12:13 |
| MadHacker | Or is the UART core too smart for its own good? | 12:13 |
| xobs | No, it's the clock recovery that's large. | 12:14 |
| xobs | Speaking of SPI -- how do normal people drive SPI from their computers? | 12:17 |
| MadHacker | To a first approximation normal people don't use SPI. It's an inside-a-device bus. | 12:18 |
| xobs | I 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 |
| MadHacker | Arduino is most common, I guess? | 12:18 |
| * MadHacker ponders. | 12:19 | |
| MadHacker | If I wanted SPI directly from my macbook, my go-to option would be an arduino. | 12:19 |
| MadHacker | An FTDI cable as maybe option 2. | 12:19 |
| MadHacker | https://www.swharden.com/wp/2018-06-03-bit-bang-ftdi-usb-to-serial-converters-to-drive-spi-devices/ | 12:20 |
| tpb | Title: Bit-Bang FTDI USB-to-Serial Converters to Drive SPI Devices SWHarden.com (at www.swharden.com) | 12:20 |
| MadHacker | Oh, I have a more on-brand option. Tomu. | 12:21 |
| MadHacker | Jumper wires between the touchpads. | 12:21 |
| xobs | I had a feeling FTDI was the answer. I think that's how they do it with e.g. icebreaker. | 12:22 |
| xobs | Though I had no end of difficulties with the Windows drivers. | 12:22 |
| MadHacker | Yeah, in all honesty the FTDI option strikes me as widely available but horribly error-prone. | 12:23 |
| MadHacker | Between 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 #tomu | 12:59 | |
| *** emeb has joined #tomu | 13:38 | |
| *** EmilKarlson has quit IRC | 14:05 | |
| *** EmilKarlson has joined #tomu | 14:11 | |
| ssb | tomu/fomu/somu/womu navigation links on https://tomu.im/ are broken, it appears | 14:34 |
| *** esclear has quit IRC | 14:42 | |
| *** esclear has joined #tomu | 14:58 | |
| ssb | tristating usb pins seems to have working -- no bios hang at reboot, no linux hang at resume | 15:00 |
| xobs | ssb: I think mithro was in the process of reworking things. | 15:03 |
| *** rohitksingh has joined #tomu | 16:08 | |
| mithro | xobs: I just pushed the major update to the tomu website | 16:13 |
| mithro | xobs: Still very WIP, but slowly getting there... | 16:13 |
| mithro | https://tomu.im/tomu.html#specs | 16:14 |
| mithro | https://tomu.im/specs.html | 16:14 |
| tnt | 2408 vs 2048 typo | 16:21 |
| shapr | ooh, I like the range of nifty *omu models | 16:40 |
| *** rohitksingh has quit IRC | 16:40 | |
| *** rohitksingh has joined #tomu | 16:44 | |
| *** rohitksingh has quit IRC | 17:32 | |
| *** columna1 has joined #tomu | 18:28 | |
| *** columna1 has quit IRC | 18:31 | |
| *** rohitksingh has joined #tomu | 19:07 | |
| *** ademski has quit IRC | 19:27 | |
| *** ademski has joined #tomu | 19:38 | |
| *** rohitksingh has quit IRC | 19:50 | |
| MadHacker | mithro, xobs: On your list of *omu, can I place a request now for Nomu, with NFC? | 20:49 |
| MadHacker | Since 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 |
| ssb | MadHacker, see also slide 101 ("Bomu") at CCCamp slides: http://tomu.im/fomu.html | 20:55 |
| tpb | Title: Fomu - An FPGA which fits in your USB port. | I’m Tomu - A tiny ARM microprocessor which fits in your USB port. (at tomu.im) | 20:55 |
| MadHacker | I saw that, but bluetooth and NFC aren't the same thing (sadly). | 20:56 |
| ssb | it says nRF52840 and NFC and some quick googling suggests that it is there | 20:58 |
| MadHacker | Apologies then, I clearly didn't read closely enough! | 20:59 |
| MadHacker | Yep, you're right. I'm sorry, I should have looked more closely. | 20:59 |
| ssb | heh, I believe that I constantly miss half of useful information from whatever I read ) | 21:00 |
| MadHacker | I'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 flash | 21:01 | |
| ssb | though looking at the PCB I just don't believe that there is any space for 8Mb SRAM chip ) | 21:02 |
| MadHacker | Well, a USB C one would have to stick out a bit more anyway. Maybe room in one of those. :) | 21:02 |
| ssb | nevertheless, Fomu is absolutely outstanding tiny piece of hardware and software is a masterpiece | 21:04 |
| ssb | very well done, thank you guys! | 21:05 |
| *** ademski has quit IRC | 21:30 | |
| mithro | The specs table pulls from the spreadsheet at https://docs.google.com/spreadsheets/d/1k_ttjsdHY6goHbpZOLQZ0t2Dx0jF6l-AXDTZl8AfOT8/edit#gid=0 | 21:59 |
| tpb | Title: Tomu Family Specifications - Google Sheets (at docs.google.com) | 21:59 |
| *** rohitksingh has joined #tomu | 22:11 | |
| *** rohitksingh has quit IRC | 22:30 | |
| shapr | I want a fomu with an ecp5! | 22:31 |
| mithro | shapr: To my knowledge they don't make an ECP5 chip small enough? | 22:32 |
| shapr | sounds like I want a pony too :-) | 22:32 |
| * shapr checks ecp5 sizes | 22:32 | |
| shapr | according to https://www.latticesemi.com/Products/FPGAandCPLD/ECP5 the LFE5U-85 is 10x10mm but from what I've read the USB plug is 12mm wide, that doesn't leave much room | 22:45 |
| tpb | Title: ECP5 / ECP5-5G - Lattice Semiconductor (at www.latticesemi.com) | 22:45 |
| *** xkapastel has joined #tomu | 22:46 | |
| *** rohitksingh has joined #tomu | 22:56 | |
| *** rohitksingh has quit IRC | 23:24 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!