Monday, 2022-01-24

klysglad to hear you finally got a prompt, my condolences on the cache issues.03:40
lkclklys: that's a kernel-exception prompt :)08:54
lkclbut it is actually interactive, which is the funny bit08:54
octaviuslkcl, please have a look at the pinmux page (bug #762) when you have a chance. I'll be off for some driving, will be back later to respond12:32
lkcloctavius i've an investor meeting to prepare for13:40
lkcloctavius, wotcha. i just added banksel/pullup/pulldown to C4M JTAG TAP.add_io() function17:53
* lkcl need tea17:54
octaviusNice, thanks!17:54
lkclyou can ignore it completely for the GPIO-wb-peripheral for now17:57
lkclbecause JTAG is a "pass-through".17:57
lkclthe idea of using banksel=7 isn't going to fly17:58
octaviusAre you busy with the investor prep still? I mentioned on the wiki page to utilise the upper bit for JTAG control of the GPIO (because you might still want to use the lower two bank select bits for muxing peripherals during the test)18:01
octaviusAh apologies, haven't seen the bug updates, I'll read that now18:34
lkclyes, that's out. total disconnect. JTAG is a pass-thru, absolutely nothing to do with GPIO or its config18:35
lkclwhen it *is* added, it is added *in between* banksel, pullup, and pulldown18:35
lkclexactly like i, o, and oe are, right now18:35
lkclthis does mean that there are two sets of MUXes between the IOs and the actual pads18:36
lkclbut... tough18:36
octaviusAh, so the GPIO block is really just a controller for the IOPad. And when bank is changed, the controller becomes a peripheral (like I2C)18:39
octaviusWe don't need the peripheral to feed *into* the GPIO block, because it is a separate component18:40
lkclno, it's dual-purpose.18:47
lkclpurpose 1)18:47
lkcla controller for the IOpad18:47
lkclpurpose 2)18:47
lkcla means and method of connecting *BANK ZERO* to some wishbone-backed read/write "stuff"18:47
lkcl" And when bank is changed, the controller becomes a peripheral (like I2C)"18:48
lkclnot quite18:48
lkclthis again is down to accuracy of english language semantics18:48
lkclwhen the bank is changed, *one* of the peripherals is directly connected to the IOpad18:49
lkclnot "the controller becomes a peripheral"18:49
lkcl"We don't need the peripheral to feed *into* the GPIO block"18:49
lkclyes, it will18:49
lkclfor banks 1 and above, the following will be needed:18:49
lkcl* I/O/OE "in"18:49
lkcl* I/O/OE "out"18:50
lkcli think18:50
lkcllet's look at the diagram again18:50
* lkcl thinks18:50
octaviusTo me it looks like there are two blocks18:50
octaviusthe GPIO18:51
octaviusand the mux18:51
lkclthose muxes (in orange) are... mmmm18:51
lkclyyeah actually it might be sensible to make them separate blocks18:51
lkclwhat do you think?18:51
octaviusI think separation will make it sane for testing XD18:52
lkcli was thinking initially in terms of the (orange) muxes being actually inside the GPIO block18:52
lkclha, yes :)18:52
lkcland smaller modules (therefore smaller graphviz diagrams)18:52
octaviusAlso, do you expect individual bank select per GPIO pin? Or a shared bank select for a block of GPIOs?18:52
octaviusBecause that means 3 signals into JTAG *per* pin on top of what's already needed18:53
lkclok that's not quite accurate18:53
lkclok so let's imagine you have an SD/MMC peripheral18:53
lkclthe 4 data wires can have their direction reversed, but only all-at-the-same-time18:54
lkclthe individual IOpads do not have "ganging"18:54
lkcltherefore, something needs to care of that "ganging" of the one OE fan-out to 4 OEs18:54
lkclin an FPGA situation, you would have the peripheral PHY code take care of this18:55
octaviusConnect the 4 OEs before they come into the GPIO block?18:55
lkclalthough on the "core" side you would have one OE direction input18:55
lkclit is the *PHY* code which takes care of the fan-out to create 4x duplicate copies of that one OE signal18:55
lkclthus you would have 4x (I/O/OE) on the *pad* side of the PHY18:56
lkcland this is the kicker:18:56
lkclevery bank-sel'd set of I/O/OE pins *must* be *identical* to those of actually looking like they were *directly* connected to the IOpad itself18:57
lkclthe muxer must *not itself* consider any kind of "ganging" of OE signals, at all18:57
lkclit is *not* the GPIO mux's problem, nor is it the GPIO config's problem18:57
octaviusThe diagram muxjtag2 effectively shows just one pin. So for SD/MMC, you'd have 4 instances of that diagram, and it will be the periphal that will be responsible for controlling the i/o/oe. Is this not correct?18:59
lkclyes it does18:59
lkcl4 instances yes18:59
lkclactually six19:00
octaviusbesides the point, that diagram is all that's needed, no?19:00
lkclthe last 4's OE signals are duplicated in a fan-out19:00
lkclyes basically, it is19:00
octaviusOr is there additional logic that's required?19:00
octaviusSo as for what to implement:19:03
octaviusparametrisable GPIO block that has outputs a layout of (i/o/oe/pu/pd/bank sel) for *each* GPIO19:03
octaviusparametrisable mux block with i/o/oe inputs and bank select used for muxing19:03
octaviusa top-level module that instantiates the above two, with a peripheral pin, and IO pad19:03
octaviusalso a JTAG chain, using you extension with bank sel and pu/pd19:04
octaviusOnce that works, test a parametrisable version19:04
lkcl1) yes.19:05
lkcl2) yes, although i strongly recommend the mux block take a dictionary of "stuff" by names that you can easily print out (and debug).  don't do it as "lists with no identifying details". use the pinmux conventions or preferably actually use the pinmux data structures themselves if you can stand it19:07
lkcl(btw do use numbering in future so i can reply with the same numbering)19:07
lkcl3) yes, but it gets slightly complex when you think about how we did the jtag boundary-scan thing, but... yes, let's add that later19:08
lkcl4) yes, which should in theory be possible to chain together easily and integrate into the code you did last month-or-so19:08
octaviusNot sure what you meant by a "take a dictionary of stuff". I do want gtkwave to actually show a port of signals, but don't know what the examples might look like19:09
lkcl5) oh i see... yes, do it hard-coded initially with a few peripherals as examples, like uart and i2c (because uart has tx rx and i2c has i/o/oe) and then make it more general.19:10
lkclit means "use the same pinmux structures as used in the code written a couple of months ago"19:10
lkclor the data structures in pinmux.py19:11
octaviusInstead of "bank_sel$1", actually group a set of signals19:11
lkclinstead of19:11
lkclbanksel = [list, of, utterly, incomprehensible, crap]19:11
lkclbanksel = {'I2C0_SDA': ...}19:12
lkclif you don't have names ("dictionaries of stuff") you will go insane trying to understand what the bloody hell you were doing when wiring up the actual Muxes19:12
lkclthis *needs* to be regular and blindingly obvious19:13
lkclit's going to be complicated as hell to wire up19:13
lkclone of the reasons for that is because IOpad "O" and "OE" signals are not actually "outputs", they are *inputs*!19:14
octaviusIt is obvious, I just don't get how you create it. Can't just be a basic python dict? I saw syntax of "SubSignal("name",etc.)"19:14
lkclyes i'd do a basic python dict19:15
lkclnot piss about creating classes19:15
lkclbut this is the point:19:15
lkclalthough you need the Muxes to, technically, receive their inputs as a list19:15
lkclplease make sure that the wires are actually named19:16
lkclwhat i don't want to see is this:19:16
lkclbanksel = [list,of,incomprehensible,crap]19:16
lkclmux[0] = banksel[crapola0]19:16
lkclmux[1] = banksel[crapola1]19:16
octavius{"port0": Signal(blah blah)}, like that?19:16
octaviusDoes gtkwave automagically give it names19:17
lkcl{"port0": Signal(name="port0", blah blah)19:17
lkcl*no it doesn't*19:17
lkclthat's the point19:17
octaviusAnd if I have a layout?19:17
octaviusSame thing but repeated?19:17
lkclif you have a layout you get a partial name19:17
lkclRecord(name="fred", layout=[("blogs", 1)])19:18
lkclwill create gtkwave traces19:18
lkclnot fred19:18
lkclnot blogs19:18
lkcltry it19:18
lkclactually a Record is probably a good idea19:19
octaviusI'll do that19:19
lkclwhere the Record *must* be of width banksel19:19
lkclbut its contents (the names of the layout) can be named after their PHY names19:19
lkclMux0 = Record(name="port0", layout=[("gpio_a0", 1), ("uart0_tx", 1), .... ])19:20
lkclsee how that works?19:20
lkclit's got all of the naming info, which will trickle through to the gtkwave traces19:21
lkclif you did it as19:21
lkclMux = Signal(banksel)19:21
lkclMux0 = Record(name="port0", layout=[("mux0", 1), ("mux1", 1) .... ])19:22
lkclhow the hell would you know what was what?19:22
lkclthat's what i mean by "don't use crapola lists-of-stuff"19:22
octaviusI think I see it, but I'll need more experimentation. I'll try adding names to layouts first19:22
lkcluse dictionaries (or Records) which *actually* have the *actual* names in them19:22
lkclgreat. perfect19:22
octaviusDon't really understand how dictionaries will help with gtkwave, but records definitely19:23
octaviusOr are dictionaries more for debugging the code itself, not looking at the sims?19:23
lkclnot with gtkwave, but with understanding the code19:24
lkcland doing "print" statements to find out what the hell's going on19:25
lkclthen relate it *back* to the gtkwave19:25
octaviusWow, adding a prefix to a layout is night and day XD19:26
lkclduh :)19:33
*** analognoise1 is now known as analognoise21:50

Generated by 2.17.1 by Marius Gedminas - find it at!