Friday, 2022-01-14

octaviusWow, me logging in made today's IRC log page...I thought it wasn't working XD08:36
lkcloctavius, :) takes 5 minutes due to a cron job10:00
octaviusAh, makes sense10:27
octaviusWas surprising that there wasn't any night time activity10:27
octaviusAlso, lkcl, can you have a look at the gpio block so far? bug #76210:29
lkcl0x1Y - Access (R/W) output of GPIO #Y10:35
lkcl0x2Y - Access (R) input of GPIO #Y10:35
lkclthere can only be output or there can be input (mutually-exclusive)10:35
lkcltherefore reading to 0x1Y can be input and writing to 0x1Y can be output10:36
lkclalso remember what i said about what the ericsson developer said about an 8-bit wishbone arbiter to a 16, 32 or 64-bit bus10:36
lkclan 8-bit arbiter will perform writes to *individual bytes*, one at a time.10:37
lkcltherefore: 0 0 0 INPUT | bank_select[3:0] | 0 PDEN PUEN ODEN | 0 IEN OE OUTPUT10:37
lkclfor the first byte of that 8-bit Wishbone Arbiter, it will write to the lower half of those settings10:37
lkcland for the SECOND byte, the 8-bit Wishbone Arbiter will write to the UPPER half10:38
lkclINPUT can be merged with OUTPUT10:38
lkclbecause, see above: reading from a reg is *not* the same as *writing* to a reg10:39
lkclthis is not like memory, it is memory-*mapped* peripherals. you can do literally anything.10:39
lkclread could connect by wet string to the moon if you wanted to.10:40
lkcland write *to the same address* could engrave the results on a piece of stilton cheese.10:40
lkclIEN, OEN and ODEN can be merged into 2 bits, comprising 4 modes:10:41
lkcl* input-mode10:42
lkcl1 sec...10:43
lkclyep, IE and OE, that should do it10:43
lkclif you set - and bear in mind this critically relies on everything being 8-bit - if you set both OUT and OE to 1 to indicate "1", or you set everything to zero except PUEN, you get open drain effect10:45
octavius"about what the ericsson developer said about an 8-bit wishbone arbiter to a 16, 32 or 64-bit bus", sorry, it's been a while. I don't remember where you mentioned this.11:19
octaviusDoes this mean that when performing a wishbone write, there will ALWAYS be a delay between individual bytes of the data word being written?11:19
octavius"this is not like memory, it is memory-*mapped* peripherals. you can do literally anything.", so what you're saying is, since the WB transaction doesn't need look like a register, I can have fewer bits representing the configuration instead.11:19
octavius"if you set both OUT and OE to 1 to indicate "1", or you set everything to zero...", true, didn't think of that. Technically the PUEN is not necessary for open-drain, open-drain is just a floating pin.11:19
octaviusSo how about a configuration word (8-bits): bank_sel | PD PU IE OE11:19
octaviusAnd then write to 0x0Y is output, read from 0x0Y is input.11:19
lkclabout 4 days ago :)12:07
lkclno. if you use a wishbone arbiter that exactly matches the width of the wishbone device(s) on it, then of course the arbiter does not have to break up the request12:08
lkclthe problem is that you cannot guarantee *exactly* what any given developer requires12:08
lkclnor can you restrict it12:08
octaviusSo better to make the word as small as possible?12:09
lkclwell, not necessarily12:09
lkclif you make it as "small as possible" you *have* to deploy an up-scaler / down-scaler12:10
lkclwe're running with 64-bit wishbone for the core12:10
octaviusBut at least have important parameters (like bank select and oe) in the same byte?12:10
lkclbut the opencores uart16550 is 32-bit wide12:10
lkclwhat i suggested above, if you redo it, you should find that everything fits into one byte12:11
lkclah yes, (8-bits): bank_sel | PD PU IE OE12:12
lkclbank0 bank1 bank2 InOutBit PD PU IE OE12:14
lkclsomething like that12:14
octaviusWhat's InOutBit for? To give the current value of the output or input?12:15
lkclalthough some people will be unhappy about having to maintain a copy of the "state", internally, that's fairly common/normal12:15
lkclto be able to set the current output12:15
lkclwith a write12:15
lkclor to get the current input, with a read12:15
lkclit's fairly common/normal to have a "shadow" copy of the state, in a data structure12:15
lkclif you don't, you're forced to perform a read of the register (to find out what the current PU/PD/IE/OE status is), followed by a modify, followed by a write12:16
octaviusSo what you're suggesting is to do away with separate address (0x1Y) for out/in, and instead have a copy of the current config, and write the whole config when you want to change the output?12:16
lkcland that's wasting cycles12:16
lkclbecause that will be fully atomic, even down to when some (arbitrary) user (outside of our control) decides to use an 8-bit wishbone arbiter12:17
octaviusAh ok, makes sense12:17
octaviusbetter keep it simple (also reduces gate count a little)12:17
lkclif you're feeling up to the challenge, what you could do is make each GPIO be per byte, but allow the number of bytes per row to be a configuration parameter12:18
octaviusSo, for example with Libre-soc 64-bit WB, have 8 GPIOs within a single word?12:19
octaviussure, I'll do that12:19
lkclmakes it more useful for other people12:19
lkclnow, one big thing12:19
lkclso let's say we have 8 GPIOs12:19
lkcland there is an SD/MMC muxed onto "banksel 1"12:20
lkclthe way that SD/MMC works is: the 4 data lines direction are selected *by the peripheral* - NOT by the GPIO register setting12:20
lkclthe SD/MMC peripheral DOES NOT write to the wishbone register in order to set the OE (direction) of those 4 data lines12:21
lkclwith me so far?12:21
octaviusI think so, but I'm not sure why you're combining SD/MMC with the GPIO block? I thought the pinmux would connect peripheral pins individually (I think there my understanding of the bank architecture is shaky)12:22
lkclno we're not *combining* it12:23
lkclSD/MMC is a *user* of this block12:23
lkclit's what the "banksel" (muxing) is for.12:23
lkclwhen banksel == 0, that means "GPIO setting comes from the wishbone registers we just talked about above"12:24
octaviusSo if sd/mmc is connected to banksel 1, it will be connected to the GPIO block?12:24
lkclhowever we need to mux multiple functions onto the actual IOpads, yes?12:24
octavius" we need to mux multiple functions onto the actual IOpads, yes?" yes12:24
lkclno, it will go through the Muxes directly to the IOpads **through** the GPIO block12:24
lkcli know that sounds like it's the same thing but it contains a crucial perspective difference12:25
lkclwhen banksel==1, the wishbone peripheral settings *must not* do *anything* to the input, the output, or the output-enable12:26
lkclthose *MUST* be under the control of the [arbitrary example] SD/MMC block12:26
octaviusSo libre-soc core will see a memory-mapped set of GPIOs which are accessible via wishbone when banksel==0? This GPIO block I'm making is not a "peripheral", it is part of the pad, and will connect to other peripherals12:26
lkcl***NOT*** repeat ***NOT*** under the control of the wishbone data12:26
lkclyes, when banksel==0, *only then* does the wishbone registers get routed through to the IOpad.12:27
octaviusSo in the case of SD/MMC, you need additional logic to configure the ie/oe, disable pd/pu etc.12:27
lkclok ok that's not quite true, yes i was just about to say :)12:28
octaviusSo, a WB wrapper for every peripheral to configure the GPIO? XD12:28
octaviusprob not12:28
lkclit's [probably] ok to have the PU/PD still settable via the WB regs12:28
lkclthe STM32F processors do that.12:28
lkclto configure an I2C peripheral you have to not only set the right banksel, you have to set the right PU/PD settings as well12:29
lkcla more sophisticated processor, yes, you would have a full set of configuration information per device12:30
lkclwhere *everything* is configured back in the pinmux specification12:30
lkclSDMMC sets this (blah blah) and oh btw happens to also contain full information about whether PU/PD is set on a *per-pin* basis12:31
lkclwhich is a frickin lot of work12:31
octaviusTo add support for various periph (I2C, SD/MMC, etc) AND allow flexible bank allocation is probably madness right?12:31
lkclwhat do you mean "flexible bank allocation"?12:31
lkclwe're not doing FPGA-style "any peripheral can be routed to any pins" if that's what you mean12:32
octaviusIf we go all the way bay to the pinset generator (one that produces the soc pinout). There you were able to select any 'ol bank setting. I'm guessing this flexibility has to go12:32
lkclthe amount of routing involved would be staggeringly high, and would introduce gate delays that would push peripherals beyond clock timing, so no to that12:32
lkclwe are *not* doing an FPGA12:33
lkclhowever a simple 4-way banksel is perfectly acceptable12:33
octaviusI meant this spec:;a=blob;f=src/spec/;h=2454b392cf1dcacad879b5bbd6869e945c92a327;hb=9d78eda9c4374f1cf714ddd0c07ceb17ee5459e012:33
lkclwhere exactly as has been in the pinspec system, and in hundreds of SoCs for the past 25 years,12:33
lkclthose are fixed hard-coded selections in HDL12:34
lkclbut, remember, for that one, we arranged for any "muxing" to be unnecessary12:34
lkclthis one on the other hand12:35
octaviusAnd what about if we have peripherals with crazy number of pins, non-power of 2 (rgmii, sdram, etc...)12:36
lkclup to 3 other peripherals (banksel=1/2/3) overlap with GPIO (banksel=0) on the same pin12:36
lkclthey're just individual pins12:36
lkclevery pin is treated individually and separately12:36
lkclwe don't care in the slightest how many individual pins there aer12:36
lkclas far as each individual pin is concerned, it can be routed only to any one of the banksel options12:37
lkclwhy would that be viewed as "crazy"?12:37
octaviusSo banksel=1/2/3 need to be general enough to support a range of different peripheral pin types (although there's only a few actual settings)12:37
lkclwe are in NO WAY going to try to route pin 17 of RGMII to 500 different pins.12:38
lkclyou are confusing banksel with pin types12:38
lkclbanksel is the mux12:38
lkclbanksel is not the pin *type*12:39
octaviusIf I want an I2C pin, it has to be configured with PU/PD. This is different to an UART RX pin for example12:39
octaviusThen what other parameter (other than banksel) will change the GPIO config?12:39
lkclyes.  so you set banksel=2 and you write to the GPIO CSR to say "banksel=2, PU=1, PD=0"12:39
lkclif you want UART, let us say that UART tx is connected to banksel=3, you write to the GPIO CSR, "banksel=3, PU=0, PD=0, OE=1"12:40
octaviusAlso this block doesn't actually support bi-directional pins? SDA can ONLY be an input or output at any given tme12:40
octaviusYes, but how do you control OE without WB (banksel==0)12:41
lkclagain: that comes back to what i said "lkcl> now, one big thing"12:41
lkclwhen you set banksel != 0 you do **NOT** listen to OE-setting from the WB bank12:42
lkclOE is connected TO THE PERIPHERAL12:42
octaviusOh yeah XD12:42
octaviusSo the peripheral will see a o/oe/i interface12:43
octaviusforgot about that12:43
lkclwhich means that the setting of IN-en and OUT-en must also be connected to the *peripheral*12:43
lkcl*NOT* to the WB register12:43
octaviusAh yeah, the ie as well12:43
lkcland that's part of the pinmux program's job: to auto-generate those settings12:44
lkclas far as the GPIO block itself that you are developing right now12:44
lkclit should be clear that you need to have an *array* of wires to connect to the IOpad12:45
lkclonly the *FIRST* of those (when banksel=0) shall be connected to the WB regs12:45
lkclthe rest must be *outputted* from the Module, for the pinmux program to auto-generate HDL that connects to them12:45
lkclwhich will be the next phase12:46
lkclall this stuff took about 4-5 months last time i did it in bluespec, for IIT Madras (!)12:46
lkclwhich is why i am slightly nervous about including it now, but hey, we might as well give it a shot12:47
lkcllunch, here.12:48
lkclneed food. and sunlight12:48
octaviusDoing a lot of work isn't hard, it's the understanding that's a pain. Sure, I'll go practice some driving12:48
lkcloh btw do consider taking the advanced driver course12:50
lkclit will reduce your insurance for the first year12:50
lkclit's pretty basic, but covers important stuff like "driving on A-roads and motorways"12:51
lkcland how your brakes are affected by weather, passenger weight, and road surface12:51
lkclit sounds obvious when you think about it but an emergency brake with everyone sitting on the left side of the car is going to pull it to the right12:52
lkcland also the camber of a road will also have an effect12:52
lkclthose things you just don't have time to cover in the basic training but are kiiinda important to experience12:53
octaviusTrue, I do plan to ask my instructor for motorway and evening lessons. Coming back sunday evening from Ely was quite tiring. Staying within the lane is hard in darkness (and I seem to remember there's an optical illusion with moving lights, at least for pilots)12:55
lkcli put my hand up to cover the oncoming lights, pretty much every time13:30
lkclalso if your windscreen is s***, oncoming cars can cause glare across the entire thing, reducing visibility by 50%13:31
lkclso keep it clean, outside *and* in! i just vinegared the windscreen inside on my 25 year old car13:32
*** kylel1 is now known as kylel15:48
lkclsounds weird but it cuts oil and grease :)20:11
octaviusHeheh, not the first time I've heard of vinegar doing its magic ;)20:38
octaviusAlso checked under my bonnet today, so much dust. Need to give it a good clean, even under the fusebox cover.20:39

Generated by 2.17.1 by Marius Gedminas - find it at!