Friday, 2021-11-12

Veera[m]Just for knowing in XER, CA is one bit only but here it is set as = 0b11 (0x3) why?01:17
lkclCA and CA32 are in the same XER sub-register07:51
kylelveera, it basically shifts one of them to the left and adds them together resulting in 311:42
lkclas in: bit 0 is CA, and bit 1 is CA32.14:00
lkclPower ISA requires, in 64-bit mode, for those to be the same. i think.  something like that.14:00
lkclwhatever the reason, you'll see both of them set.14:00
lkclghostmansd[m], i've an idea.  we've a nominal amount of BTC (donated). how about we send you some of that, as a "deposit"?14:07
lkclif you really need to use it, you convert it.14:09
* lkcl waves at octavius 19:14
lkclmoornin. you saw the research i've been doing into nmigen pins/resources?19:14
lkclChips4Makers[m], i tracked down an appropriate location to put JTAG Boundary scan [when using nmigen]19:15
octaviusHi luke, yeah I have. Atm is a little overwhelming to me. Does the JTAG Boundary scan effectively look like a giant shift register (where each SoC pin is a bit)?19:16
lkclit's actually very simple: create a new Platform "MixIn" which overrides set_input, set_output, and set_input_output, to do exactly what you'd naturally expect to be done19:16
octaviusWhat is set_input/output/io?19:17
lkclbut it's not _one_ bit19:17
lkclit's 2 bits19:17
lkclone bit as the actual pin19:17
lkclone bit to be able to set whether it's connected "through"19:17
lkclor whether it's connected to the JTAG for "Scan purposes"19:17
lkclcaveat again:19:17
lkclon bi-directional pins, it's _three_ wires19:18
lkclwire 1: the input wire19:18
lkclwire 2: the output wire19:18
octaviusoh, you're talking about gpio19:18
lkclwire 3: the pad direction (oe), whether it's an input or output19:18
lkclyes, that's what Boundary Scan is19:18
lkclBoundary Scan is "full complete and total redirection" of the entire GPIO19:18
lkclevery single one19:19
lkclinto a Shift Register - if requested19:19
lkcland not into a Shift Register (direct connection of peripheral to actual IOpad) - if not requested19:19
lkclthis controlled - again via the same Shift Register - for absolutely every single pin, on a per-pin basis19:19
lkclwhere each pin can be19:20
lkclget_input, get_output and get_input_output, sorry19:21
lkclfurther up, you can see the enumeration of all pins:19:21
lkcland the Xilinx Platform overrides get_input, get_output, and get_input_output19:21
lkclconnecting them to the requested FPGA IOpad resource19:22
lkclwe don't want that19:22
lkclwe want, for every single "requested" pin, that they be wired *FIRST* to JTAG Boundary Scan19:22
lkcland *THEN* to be returned.19:23
lkclhaving found the right code-point, it's actually dead easy19:23
octaviusApologies if I'm slow at this, the explanation is difficult to visualise in my head. I read a quick article on JTAG (needed a fresher), and made a simple diagram for the single GPIO block. Uploaded it here: Can you confirm if this is correct?19:47
octaviusTo fully control GPIO from the JTAG chain, all three signals must be muxed19:48
octaviusIn our case though, not every pin is going to be GPIO (such as RGMII or ULPI), so we probably don't need a 3-6 mux for every SoC pin?19:49
octaviusSo you want me to create a new Platform class which adds a mux to the in, out, oe signals of the pin object in get_input, get_output, get_tristate, get_input_output? If so, that does seem straightforward. I'd just need to know the names of the JTAG signals to connect to20:13
lkclyeah! that looks pretty damn good actually20:14
lkclthat's worth dropping on the wiki20:14
lkclyes, all 3 must be muxed...20:16
lkclah ok i am using the word "GPIO" in a general context, sorry20:16
lkclin the context of "JTAG", GPIO could be "a pin named GPIO0" or "a pin named RGMII_TX0"20:17
lkclsorry about that20:17
lkclso, yes, every single one of the pins - RG0_TX0, ULPI0_DATA0, GPIO5, I2C_SDA, everything - absolutely all of them must be routed through JTAG Boundary Scan muxes.20:18
lkclotherwise, how would you:20:18
lkcla) test the IO pads without the function potentially being faulty20:18
lkclb) test the function without the IOpad potentially being faulty20:18
lkclSo you want me to create a new Platform class which adds a mux to the in, out, oe signals of the pin object in get_input, get_output, get_tristate, get_input_output?20:18
lkclno, not add a mux: connect to a pre-existing JTAG object's pin-resource20:19
lkclthis will need to be done in small steps20:19
lkclline 64 of class JTAG20:20
lkclhere is where i have created something which calls the "add_io" function of C4M JTAG20:20
lkclthat creates a suite of IO Records whiiiich...20:21
lkcl... line 197:20:22
lkclget created *on-demand* of the right type (In, Out, InOut, TristateInOut)20:22
lkclline 544 is the implementation of add_io20:22
lkclso, whilst that gets created in that function, and it doesn't really look as if anything is done with it, actually, if you look in elaborate_ios, actually it is20:23
lkclthe IOConn Records get connected up to the Shift Register (so that you don't have to).20:23
lkclback iiiin....20:24
lkclwhen a "pinset" dictionary was created, those *automatically* get connected to the Shift Register (and the Mux)20:24
lkclso that *you* do not have to connect up a Mux20:25
lkclall you have to do is:20:25
lkclm.d.comb += self.ios[0].i.eq(somethingsomethingfromaperipheral)20:25
lkclm.d.comb += actualoutputtocorona.eq(self.ios[0].pad_side.i)20:26
lkclit's probably easiest / best to do this as a 3-stage process20:27
lkcl1) create a dummy ASICPlatform class - hardcoded Resources.20:27
lkcl2) convert ASICPlatform to non-hard-coded Resources20:27
lkcl3) add JTAG Boundary Scan20:28
lkclwhere (3) involves creating a *duplicate* set of Resources.20:28
lkclwhere - exactly as in the image you created, the one set of Resources is on the left (actual IO pads)20:28
lkcland the other set of Resources - with identical names and identical functions - is on the right20:29
lkcl1 sec20:29
lkclif you write that as a really, *really* simple program, starting at phase (1) with something that matches20:32
lkclline 2620:33
lkclit should be pretty straightforward20:33
lkclhey, for uart, you could even use this:20:35
lkclI2CResource further down as well....20:37
octaviusSorry, I'm distracted atm, I'll come back in half hour and read again. I think I understand the problem, but it's a lot (and seems redundant, at least until I understand it)20:53
lkclfor when you're back: it isn't redundant, because without JTAG Boundary Scan, you end up with the situation in every single one of the google skywater 130nm OpenMPW tape-outs22:01
lkclthe "Management" core failed22:01
lkcland because there was no JTAG boundary scan, absolutely nobody could properly identify if their ASIC peripheral functions were faulty22:02
lkclor whether the IO pads were faulty22:02
lkclbecause the "Management" Core could not flip the GPIO muxer22:03
lkclno JTAG boundary scan, no way to test IO pads independently of peripherals22:03
lkclyou're probably referring to "the JTAG Resource() list" has to be identical to "the IOPad Corona Resource() list"22:04
lkclthat absolutely *has* to be an identical list22:04
lkclif if isn't an identical list, how the hell can you connect the thing on the left to the thing on the right?22:05
lkcli just realised, the diagram's slightly inaccurate.  let me redraw it22:06
octaviusJust re-read your comments. So the topology is:22:10
octaviusResource Manager (SoC periphs) <-> JTAG <-> Resource Manager (ASIC corona)22:10
octaviusI'll need to create an ASIC Platform class that attaches to JTAG (within the get_* methods) by:22:11
octaviusjtag_in = self.jtag.get_core_side(pi, port, attrs, invert)22:11
octavius        jtag_out = self.jtag.get_core_side(pi, port, attrs, invert)22:11
octaviusDoes there need to be a new directory "ngi_router" in "libresoc-litex" repo? There would then be a file with the new class22:15
lkclyes... but not in stage (1) or (2)22:20
lkclthat'll be stage (3)22:20
lkcloh hell no.22:20
lkcllitex is *out*22:20
lkclthis will be entirely without litex.  except, potentially, having looked at how lambdasoc works, that explicitly imports litedram and liteeth.22:21
lkclbut it imports them as stand-alone instances.  and, what is very nice, does so in a way that illustrate how that can be done... from nmigen22:21
lkclok i have the redrawn image... just cropping it22:22
lkclso that should illustrate it correctly.22:24
lkclin "bypass" mode - note that one of the SR bits sets "bypass / no-bypass"....22:24
lkclthe IOpad is connected *directly* to the peripheral.22:24
lkclJTAG is bypassed entirely22:24
lkclwhich is why it's called: bypass22:24
lkclthis is "normal" operation.22:25
lkclwhen that "control" bit is set, two things happen - not one:22:25
lkcl1) the IOpad is connected (muxed) to "pad" SR TDI/TDO bits22:25
lkcl2) the *PERIPHERAL* is **LIKEWISE** connected (muxed) to "core" SR TDI/TDO bits22:25
lkclit is useless just to connect the IOpads to the SR without connecting the core to the SR22:26
lkclit is useless also to connect the core to the SR without also connecting the IOpads to the SR.22:26
octaviusOk, I think I understand the hardware itself22:26
lkclhow else would you test both, independently?22:26
octaviusThe diagram explains it quite well22:27
lkclbut, you do not even need to know that c4m-jtag is doing that on your behalf22:27
lkclbut, it also explains, clearly, why there must be *two* identical resources22:27
lkclone named pads22:27
lkclone named core22:27
lkclby resource, i mean - very specifically - nmigen PlatformManager.resources lists22:28
lkclwhich contain entries of type nmigen Resource()22:28
lkclfor stage (1) and (2), strictly speaking, you don't even need to create an ASICPlatform class22:28
lkclyou should literally just be able to use a PlatformTemplate() instance22:29
lkclmaybe not even that - just Platform() instance22:30
octaviusAnd then override PlatformTemplate's get_* methods?22:30
lkcldoes Platform() have a build() function?22:30
lkclno, not even that, initially22:30
lkclthat would be stage (3)22:30
lkclnope build() is part of Platform() not PlatformTemplate()22:30
lkclso you can create an instance Platform()22:31
lkclthen call
lkclfor stage (1) and (2) - which do not involve JTAG - the existing get_input() get_output() and get_input_output() should work perfectly22:32
lkclonly at *phase 3* - when actually doing the redirection (get_core_side, jtag_in/out) would the ASICPlatform need to be created, *then* the duplicate Resource() is needed.22:33
octaviusI need to go, otherwise I won't get enough sleep. I'll be on tomorrow morning around 8am onwards to continue. If you're busy I'll continue with figuring out the svg.22:33
lkclok :)22:34
octaviusSorry, this is a lot22:34
lkclah goo idea22:34
lkclyes, sorry :)22:34
octaviusHopefully with a fresh mind I'll get it22:34
octaviusYou two, gn22:34
lkcltook me 5 months to work it all out...22:34

Generated by 2.17.1 by Marius Gedminas - find it at!