| octavius | Wow, me logging in made today's IRC log page...I thought it wasn't working XD | 08:36 |
|---|---|---|
| lkcl | octavius, :) takes 5 minutes due to a cron job | 10:00 |
| octavius | Ah, makes sense | 10:27 |
| octavius | Was surprising that there wasn't any night time activity | 10:27 |
| octavius | Also, lkcl, can you have a look at the gpio block so far? bug #762 | 10:29 |
| lkcl | sure | 10:34 |
| lkcl | 0x1Y - Access (R/W) output of GPIO #Y | 10:35 |
| lkcl | 0x2Y - Access (R) input of GPIO #Y | 10:35 |
| lkcl | there can only be output or there can be input (mutually-exclusive) | 10:35 |
| lkcl | therefore reading to 0x1Y can be input and writing to 0x1Y can be output | 10:36 |
| lkcl | also remember what i said about what the ericsson developer said about an 8-bit wishbone arbiter to a 16, 32 or 64-bit bus | 10:36 |
| lkcl | an 8-bit arbiter will perform writes to *individual bytes*, one at a time. | 10:37 |
| lkcl | therefore: 0 0 0 INPUT | bank_select[3:0] | 0 PDEN PUEN ODEN | 0 IEN OE OUTPUT | 10:37 |
| lkcl | for the first byte of that 8-bit Wishbone Arbiter, it will write to the lower half of those settings | 10:37 |
| lkcl | and for the SECOND byte, the 8-bit Wishbone Arbiter will write to the UPPER half | 10:38 |
| lkcl | also: | 10:38 |
| lkcl | INPUT can be merged with OUTPUT | 10:38 |
| lkcl | why? | 10:38 |
| lkcl | because, see above: reading from a reg is *not* the same as *writing* to a reg | 10:39 |
| lkcl | this is not like memory, it is memory-*mapped* peripherals. you can do literally anything. | 10:39 |
| lkcl | read could connect by wet string to the moon if you wanted to. | 10:40 |
| lkcl | and write *to the same address* could engrave the results on a piece of stilton cheese. | 10:40 |
| lkcl | IEN, OEN and ODEN can be merged into 2 bits, comprising 4 modes: | 10:41 |
| lkcl | * input-mode | 10:42 |
| lkcl | 1 sec... | 10:43 |
| lkcl | yep, IE and OE, that should do it | 10:43 |
| lkcl | if 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 effect | 10: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 |
| octavius | Does 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 |
| octavius | So how about a configuration word (8-bits): bank_sel | PD PU IE OE | 11:19 |
| octavius | And then write to 0x0Y is output, read from 0x0Y is input. | 11:19 |
| lkcl | about 4 days ago :) | 12:07 |
| lkcl | no. 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 request | 12:08 |
| lkcl | the problem is that you cannot guarantee *exactly* what any given developer requires | 12:08 |
| lkcl | nor can you restrict it | 12:08 |
| octavius | So better to make the word as small as possible? | 12:09 |
| lkcl | well, not necessarily | 12:09 |
| lkcl | if you make it as "small as possible" you *have* to deploy an up-scaler / down-scaler | 12:10 |
| lkcl | we're running with 64-bit wishbone for the core | 12:10 |
| octavius | But at least have important parameters (like bank select and oe) in the same byte? | 12:10 |
| lkcl | but the opencores uart16550 is 32-bit wide | 12:10 |
| lkcl | what i suggested above, if you redo it, you should find that everything fits into one byte | 12:11 |
| octavius | ok | 12:12 |
| lkcl | ah yes, (8-bits): bank_sel | PD PU IE OE | 12:12 |
| lkcl | bank0 bank1 bank2 InOutBit PD PU IE OE | 12:14 |
| lkcl | something like that | 12:14 |
| octavius | What's InOutBit for? To give the current value of the output or input? | 12:15 |
| lkcl | although some people will be unhappy about having to maintain a copy of the "state", internally, that's fairly common/normal | 12:15 |
| lkcl | yes | 12:15 |
| lkcl | to be able to set the current output | 12:15 |
| lkcl | with a write | 12:15 |
| lkcl | or to get the current input, with a read | 12:15 |
| lkcl | it's fairly common/normal to have a "shadow" copy of the state, in a data structure | 12:15 |
| lkcl | if 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 write | 12:16 |
| octavius | So 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 |
| lkcl | and that's wasting cycles | 12:16 |
| lkcl | yes | 12:16 |
| lkcl | because that will be fully atomic, even down to when some (arbitrary) user (outside of our control) decides to use an 8-bit wishbone arbiter | 12:17 |
| octavius | Ah ok, makes sense | 12:17 |
| octavius | better keep it simple (also reduces gate count a little) | 12:17 |
| lkcl | if 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 parameter | 12:18 |
| octavius | So, for example with Libre-soc 64-bit WB, have 8 GPIOs within a single word? | 12:19 |
| lkcl | exactly. | 12:19 |
| octavius | sure, I'll do that | 12:19 |
| lkcl | makes it more useful for other people | 12:19 |
| lkcl | now, one big thing | 12:19 |
| lkcl | so let's say we have 8 GPIOs | 12:19 |
| lkcl | and there is an SD/MMC muxed onto "banksel 1" | 12:20 |
| lkcl | the way that SD/MMC works is: the 4 data lines direction are selected *by the peripheral* - NOT by the GPIO register setting | 12:20 |
| lkcl | the SD/MMC peripheral DOES NOT write to the wishbone register in order to set the OE (direction) of those 4 data lines | 12:21 |
| lkcl | with me so far? | 12:21 |
| octavius | I 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 |
| lkcl | no we're not *combining* it | 12:23 |
| lkcl | SD/MMC is a *user* of this block | 12:23 |
| lkcl | it's what the "banksel" (muxing) is for. | 12:23 |
| lkcl | when banksel == 0, that means "GPIO setting comes from the wishbone registers we just talked about above" | 12:24 |
| octavius | So if sd/mmc is connected to banksel 1, it will be connected to the GPIO block? | 12:24 |
| lkcl | however 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?" yes | 12:24 |
| lkcl | no, it will go through the Muxes directly to the IOpads **through** the GPIO block | 12:24 |
| lkcl | i know that sounds like it's the same thing but it contains a crucial perspective difference | 12:25 |
| lkcl | when banksel==1, the wishbone peripheral settings *must not* do *anything* to the input, the output, or the output-enable | 12:26 |
| lkcl | those *MUST* be under the control of the [arbitrary example] SD/MMC block | 12:26 |
| octavius | So 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 peripherals | 12:26 |
| lkcl | ***NOT*** repeat ***NOT*** under the control of the wishbone data | 12:26 |
| lkcl | yes, when banksel==0, *only then* does the wishbone registers get routed through to the IOpad. | 12:27 |
| octavius | So in the case of SD/MMC, you need additional logic to configure the ie/oe, disable pd/pu etc. | 12:27 |
| lkcl | ok ok that's not quite true, yes i was just about to say :) | 12:28 |
| octavius | So, a WB wrapper for every peripheral to configure the GPIO? XD | 12:28 |
| octavius | prob not | 12:28 |
| lkcl | it's [probably] ok to have the PU/PD still settable via the WB regs | 12:28 |
| lkcl | the STM32F processors do that. | 12:28 |
| lkcl | to configure an I2C peripheral you have to not only set the right banksel, you have to set the right PU/PD settings as well | 12:29 |
| lkcl | a more sophisticated processor, yes, you would have a full set of configuration information per device | 12:30 |
| lkcl | where *everything* is configured back in the pinmux specification | 12:30 |
| lkcl | SDMMC sets this (blah blah) and oh btw happens to also contain full information about whether PU/PD is set on a *per-pin* basis | 12:31 |
| lkcl | which is a frickin lot of work | 12:31 |
| octavius | To add support for various periph (I2C, SD/MMC, etc) AND allow flexible bank allocation is probably madness right? | 12:31 |
| lkcl | what do you mean "flexible bank allocation"? | 12:31 |
| lkcl | we're not doing FPGA-style "any peripheral can be routed to any pins" if that's what you mean | 12:32 |
| octavius | If 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 go | 12:32 |
| lkcl | the amount of routing involved would be staggeringly high, and would introduce gate delays that would push peripherals beyond clock timing, so no to that | 12:32 |
| lkcl | we are *not* doing an FPGA | 12:33 |
| lkcl | however a simple 4-way banksel is perfectly acceptable | 12:33 |
| octavius | I meant this spec: https://git.libre-soc.org/?p=pinmux.git;a=blob;f=src/spec/ls180.py;h=2454b392cf1dcacad879b5bbd6869e945c92a327;hb=9d78eda9c4374f1cf714ddd0c07ceb17ee5459e0 | 12:33 |
| lkcl | where exactly as has been in the pinspec system, and in hundreds of SoCs for the past 25 years, | 12:33 |
| octavius | sure | 12:33 |
| lkcl | yes | 12:34 |
| lkcl | those are fixed hard-coded selections in HDL | 12:34 |
| lkcl | but, remember, for that one, we arranged for any "muxing" to be unnecessary | 12:34 |
| lkcl | this one on the other hand | 12:35 |
| lkcl | https://git.libre-soc.org/?p=pinmux.git;a=blob;f=src/spec/m_class.py;h=4d6610670179f9ddb5257935ea6f9632c5bf052b;hb=9d78eda9c4374f1cf714ddd0c07ceb17ee5459e0 | 12:35 |
| octavius | And what about if we have peripherals with crazy number of pins, non-power of 2 (rgmii, sdram, etc...) | 12:36 |
| lkcl | up to 3 other peripherals (banksel=1/2/3) overlap with GPIO (banksel=0) on the same pin | 12:36 |
| lkcl | they're just individual pins | 12:36 |
| lkcl | every pin is treated individually and separately | 12:36 |
| lkcl | we don't care in the slightest how many individual pins there aer | 12:36 |
| lkcl | as far as each individual pin is concerned, it can be routed only to any one of the banksel options | 12:37 |
| lkcl | 1,2,3,4,5,6,7 | 12:37 |
| lkcl | why would that be viewed as "crazy"? | 12:37 |
| octavius | So 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 |
| lkcl | we are in NO WAY going to try to route pin 17 of RGMII to 500 different pins. | 12:38 |
| lkcl | no. | 12:38 |
| lkcl | you are confusing banksel with pin types | 12:38 |
| lkcl | banksel is the mux | 12:38 |
| lkcl | banksel is not the pin *type* | 12:39 |
| octavius | If I want an I2C pin, it has to be configured with PU/PD. This is different to an UART RX pin for example | 12:39 |
| octavius | Then what other parameter (other than banksel) will change the GPIO config? | 12:39 |
| lkcl | yes. so you set banksel=2 and you write to the GPIO CSR to say "banksel=2, PU=1, PD=0" | 12:39 |
| lkcl | done | 12:39 |
| lkcl | if 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 |
| lkcl | done | 12:40 |
| octavius | Also this block doesn't actually support bi-directional pins? SDA can ONLY be an input or output at any given tme | 12:40 |
| octavius | Yes, but how do you control OE without WB (banksel==0) | 12:41 |
| lkcl | again: that comes back to what i said "lkcl> now, one big thing" | 12:41 |
| lkcl | when you set banksel != 0 you do **NOT** listen to OE-setting from the WB bank | 12:42 |
| lkcl | OE is connected TO THE PERIPHERAL | 12:42 |
| octavius | Oh yeah XD | 12:42 |
| octavius | So the peripheral will see a o/oe/i interface | 12:43 |
| octavius | forgot about that | 12:43 |
| lkcl | which means that the setting of IN-en and OUT-en must also be connected to the *peripheral* | 12:43 |
| lkcl | *NOT* to the WB register | 12:43 |
| octavius | Ah yeah, the ie as well | 12:43 |
| lkcl | yes. | 12:43 |
| lkcl | and that's part of the pinmux program's job: to auto-generate those settings | 12:44 |
| lkcl | but | 12:44 |
| lkcl | as far as the GPIO block itself that you are developing right now | 12:44 |
| lkcl | it should be clear that you need to have an *array* of wires to connect to the IOpad | 12:45 |
| lkcl | only the *FIRST* of those (when banksel=0) shall be connected to the WB regs | 12:45 |
| lkcl | the rest must be *outputted* from the Module, for the pinmux program to auto-generate HDL that connects to them | 12:45 |
| lkcl | which will be the next phase | 12:46 |
| lkcl | all this stuff took about 4-5 months last time i did it in bluespec, for IIT Madras (!) | 12:46 |
| lkcl | which is why i am slightly nervous about including it now, but hey, we might as well give it a shot | 12:47 |
| lkcl | lunch, here. | 12:48 |
| lkcl | need food. and sunlight | 12:48 |
| octavius | Doing a lot of work isn't hard, it's the understanding that's a pain. Sure, I'll go practice some driving | 12:48 |
| lkcl | cool! | 12:50 |
| lkcl | oh btw do consider taking the advanced driver course | 12:50 |
| lkcl | it will reduce your insurance for the first year | 12:50 |
| lkcl | it's pretty basic, but covers important stuff like "driving on A-roads and motorways" | 12:51 |
| lkcl | and how your brakes are affected by weather, passenger weight, and road surface | 12:51 |
| lkcl | it 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 right | 12:52 |
| lkcl | and also the camber of a road will also have an effect | 12:52 |
| lkcl | those things you just don't have time to cover in the basic training but are kiiinda important to experience | 12:53 |
| octavius | True, 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 |
| lkcl | i put my hand up to cover the oncoming lights, pretty much every time | 13:30 |
| lkcl | also if your windscreen is s***, oncoming cars can cause glare across the entire thing, reducing visibility by 50% | 13:31 |
| lkcl | so keep it clean, outside *and* in! i just vinegared the windscreen inside on my 25 year old car | 13:32 |
| *** kylel1 is now known as kylel | 15:48 | |
| lkcl | sounds weird but it cuts oil and grease :) | 20:11 |
| octavius | Heheh, not the first time I've heard of vinegar doing its magic ;) | 20:38 |
| octavius | Also checked under my bonnet today, so much dust. Need to give it a good clean, even under the fusebox cover. | 20:39 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!