| *** tpb has joined #tomu | 00:00 | |
| futarisIRCcloud | Bit banging would work, but would be slow. But I guess it would fine for the small SPI flash. | 00:02 |
|---|---|---|
| *** drprune has joined #tomu | 00:31 | |
| *** drprune has quit IRC | 00:56 | |
| *** drprune has joined #tomu | 01:58 | |
| *** futarisIRCcloud has quit IRC | 02:07 | |
| *** ewen has joined #tomu | 03:01 | |
| ewen | While playing with SB_RGBA_DRV in the Fomu blink example (https://github.com/im-tomu/fomu-tests/tree/master/blink) I'd expected to be able to influence the mapping of RGB channels to LED colours with .RGB0/.RGB1/.RGB2 parameters to SB_RGBA_DRV. | 03:05 |
| tpb | Title: fomu-tests/blink at master · im-tomu/fomu-tests · GitHub (at github.com) | 03:05 |
| xobs | ewen: there might be a nextpnr issue. or maybe they're hardcoded? I noticed something similar. | 03:06 |
| ewen | But experimentally it seems like while .RGB0/.RGB1/.RGB2 do need to be specified for instantiation to happen, it doesn't seem to matter which order I list led_r/led_b/led_g | 03:06 |
| ewen | xobs: Yeah, that's where I got to: wondering if there was a nextpnr bitstream generation issue going on. | 03:06 |
| *** drprune has quit IRC | 03:07 | |
| ewen | xobs: I was also trying to figure out the actual *on PCB* mapping of RGB0 / RGB1 / RGB2 to the LED pins (since IIRC you said some were accidentally swapped from schematic). | 03:07 |
| ewen | xobs: Make I create an issue on nextpnr GitHub to see if anyone else has seen this SB_RGBA_DRV behaviour. Do you want me to tag you too? | 03:09 |
| xobs | ewen: yes, please. | 03:12 |
| xobs | On the PCB, I'd imagine green and blue are swapped. | 03:12 |
| ewen | xobs: According to schematic 39 = Red, 40 = Blue, 41 = Green. In practice RGB0 = Blue, RGB1 = Red, RGB2 = Green (apparently hard coded). | 03:15 |
| ewen | So maybe Red / Blue got swapped, and RGB0/1/2 are being hard mapped? | 03:15 |
| ewen | I'll create an issue now (can't seen anything relevant open). | 03:15 |
| ewen | FTR, this seems to be nexpnr commit originally adding SB_RGBA_DRV support: https://github.com/YosysHQ/nextpnr/pull/131/commits/e8556aff372c77c1e14a4378b43b47f8ba1e75ec | 03:15 |
| tpb | Title: iCE40: Bug fixes and general improvement of global network support by smunaut · Pull Request #131 · YosysHQ/nextpnr · GitHub (at github.com) | 03:15 |
| ewen | (But I don't understand enough of the nextpnr internals to know if it's trying to map RGB0/1/2 or not.) | 03:16 |
| ewen | For those playing along at home, this is https://github.com/YosysHQ/nextpnr/issues/254 | 03:59 |
| tpb | Title: ICE40UP5K-SG48I: SB_RGBA_DRV: LED pin mapping appears hard coded · Issue #254 · YosysHQ/nextpnr · GitHub (at github.com) | 03:59 |
| ewen | FWIW, I did wonder if I could test against aranchne-pnr, but as best I can tell it never had ICE40UP5K support added, just the earlier ICE40s. | 04:17 |
| *** drprune has joined #tomu | 04:17 | |
| *** futarisIRCcloud has joined #tomu | 04:19 | |
| ewen | xobs: It turns out that arachne-pnr *does* support ICE40UP5K-SG48: http://www.clifford.at/icestorm/ | 05:06 |
| tpb | Title: Project IceStorm (at www.clifford.at) | 05:06 |
| ewen | And after a *bunch* of fiddling I've managed to both build arachne-pnr on the Raspberry Pi image *and* figure out a yosys / arachne-pnr commandline that will run. | 05:06 |
| ewen | arachne-pnr fails to route the design with: fatal error: bad constraint on `led_b': pin 40 does not correspond to RGB driver output `RGB2' | 05:07 |
| ewen | xobs: ... and it works as expected if I swap the RGBn/led_A to be in the order of the output pins. More detail at https://github.com/YosysHQ/nextpnr/issues/254#issuecomment-475840646 | 05:27 |
| tpb | Title: ICE40UP5K-SG48I: SB_RGBA_DRV: LED pin mapping appears hard coded · Issue #254 · YosysHQ/nextpnr · GitHub (at github.com) | 05:27 |
| ewen | xobs: It also looks like the Red and Blue LED connections got swapped in PCB layout, and that we should swap their values in the .pcf files and code accordingly. Which I think will make everything consistently blue/red/green 39/40/41 RGB0/RGB1/RGB2. | 05:28 |
| xobs | ewen: I suppose I could update the schematics. Since it's purely a notational issue. | 05:33 |
| ewen | xobs: It's probably a good idea to update the schematics to match the PCB layout *anyone* to avoid confusion. | 05:37 |
| ewen | *anyway | 05:37 |
| ewen | But in addition to the notational issue, there's the consistency with the colour of the visible light... :-) | 05:38 |
| *** drprune has quit IRC | 05:52 | |
| tnt | ewen: The RGB0/1/2 connections in HDL are purely cosmetic. They are hardwired in the the silicon to matching pads and can't be changed. | 06:10 |
| ewen | tnt: Thanks, it's very useful to have confimation that's the way its implemented. | 06:11 |
| ewen | (Having parameters which "don't do anything" is puzzling, especially in nextpnr which doesn't warn about it.) | 06:11 |
| tnt | it's for compatibility with lattice docs, we need to accept those connections, but the doc from lattic is quite clear that they are hw connections and map to the RGB0/1/2 pins of the fpga. | 06:13 |
| ewen | tnt: Compatibility with existing code makes sense. I suspect the arachne-pnr solution of erroring (or at least warning) if you try to connect them to something else is probably the best that can be done to avoid confusion given the Lattice docs / Lattice silicon combination. | 06:14 |
| tnt | Sure, feel free to submit a pull request to do that | 06:15 |
| ewen | I've added https://github.com/YosysHQ/nextpnr/issues/254#issuecomment-475843155 to the ticket with cut'n'paste of your answers so it's in one place. | 06:19 |
| tpb | Title: ICE40UP5K-SG48I: SB_RGBA_DRV: LED pin mapping appears hard coded · Issue #254 · YosysHQ/nextpnr · GitHub (at github.com) | 06:19 |
| ewen | Today is the first I've looked *inside* nextpnr code, so it'd take me a non-trivial amount of time to even figure out where to change it to add an appropriate warning... :-) | 06:19 |
| xobs | I guess the alternative is to lie and swap the connections in the pnr tool, but then you wouldn't have compatibility. | 06:23 |
| ewen | xobs: I guess you could swap around *both* the RGBnPWM *and* RGBn mappigs together, and it'd be internally consistent in the design. But, as you say not compatible with other code that assumes the fixed mapping. Bug-for-bug compatibility is hard... | 06:26 |
| ewen | *mappings | 06:27 |
| *** futarisIRCcloud has quit IRC | 06:29 | |
| tnt | I don't get why this is such an issue ... I mean the input to the SB_RGBA_DRV are from the fabric, just swap that as you need. | 06:31 |
| ewen | tnt: It was only an issue for me because I was confused why there were parameters that nextpnr seemed to accept but they (a) did nothing when I swapped them, and (b) I didn't see any errors/warnings. | 06:34 |
| ewen | So violation of "principle of least surprise" mostly :-) | 06:34 |
| ewen | As you say, for a real design it's trivial to arrange to swap things over earlier. | 06:34 |
| *** jas4711 has quit IRC | 07:27 | |
| *** ewen has quit IRC | 09:10 | |
| *** alexhw has quit IRC | 09:42 | |
| *** awe00 has quit IRC | 10:48 | |
| *** awe00 has joined #tomu | 11:07 | |
| *** AmosSam has left #tomu | 12:09 | |
| *** AmosSam has joined #tomu | 12:09 | |
| *** AmosSam has left #tomu | 13:31 | |
| *** AmosSam has joined #tomu | 13:35 | |
| *** awe00 has quit IRC | 14:33 | |
| *** awe00 has joined #tomu | 14:52 | |
| *** rohitksingh has joined #tomu | 16:28 | |
| *** rohitksingh has quit IRC | 19:07 | |
| *** TheJJ has joined #tomu | 20:08 | |
| *** TheJJ_ has quit IRC | 20:10 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!