Wednesday, 2022-06-29

*** kylel1 is now known as kylel07:11
lkclVeera[m], images look great, sorry i made one mistake, the sums inside the right-end box should be08:23
lkclthe only reason it appears to be a day later is because it's at 00:00 local time.09:04
ghostmansdUpdated the script:
lkcl                ("r", 32, 256, "(PPC_OPERAND_GPR | PPC_OPERAND_SVP64)"),18:38
ghostmansdYeah I want to differ these. On the other hand... I'm thinking of simply using this table after ppc_cpu has been checked for SVP64 flag (i.e. for -mlibresoc). In this case, we'd need to keep only some vector-specific flag.18:54
ghostmansdAnd, still, what about other registers?18:55
ghostmansdAll my messages disappeared18:55
ghostmansdAt least nothing in IRC logs18:56
ghostmansdNo wonder nobody replied.18:56
ghostmansd[19:33:24] <ghostmansd> Hi folks, I'd like so see kind of summary for all registers: which can be vectorized, and which have the extensions.18:56
ghostmansd[19:33:52] <ghostmansd> For now, I assume the following:18:56
ghostmansd[19:34:01] <ghostmansd> 1) 256 GPRs, which can be vectorized;18:56
ghostmansd[19:34:10] <ghostmansd> 2) 256 FPRs, which can be vectorized;18:56
ghostmansd[19:34:33] <ghostmansd> 3) 8 CRs, which can be vectorized;18:56
ghostmansd[19:35:37] <ghostmansd> What about SPRs? VRs? SPRs?18:56
ghostmansd[19:48:44] <ghostmansd> Yes, this is intentionally sorted this way, the vanilla PPC code has a special routine which find the entries via binary search.18:56
ghostmansd[m]There was also link to script which I updated :-)19:00
lkclactual numbers: 128 GPRs, 128 FPRs, 16 32-bit CRs19:07
lkclno VRs19:07
lkclQTY 16of 32-bit CRs for a total of 128 CR *fields*19:07
tplatenI had a look at which uses a ClockSignal("dramsync2x")19:11
tplatenThe signal must be connected, if not I get TSHX2DQA 'ddrphy.U$$88' cannot have disconnected ECLK19:11
tplatenI guess when there is only one clock that signal needs to be conntedted to dramsync, but I'm not sure here.19:12
lkcltplaten,  305             m.d.comb += ClockSignal("dramsync2x").eq(ClockSignal("sync2x"))19:16
lkclit looks like you've set the dram frequency to an explicit number rather than to None19:17
tplatenI've fixed one line that in the meanwhile, but did not commit my changes yet19:21
lkclplease don't make *any* changes to ecp5_crg.py19:24
lkclat all19:24
lkclseveral hardware modules rely on it and you don't have those systems to test changes19:25
lkclso please *do not* make *any* modifications to of any kind19:25
tplatenNo, I did not change that one. I only changed, only the orangecrab section19:26
lkclif you don't have dram_clk_freq=None, you will find that the wrong code is executed in ecp5_crg.py19:26
lkcland several other places19:26
tplatenI have dram_clk_freq set to None19:27
lkcl 881     # merge dram_clk_freq with clk_freq if the same19:27
lkcl 882     if clk_freq == dram_clk_freq:19:27
lkcl 883         dram_clk_freq = None19:27
lkclthis happens automatically if clk_freq == dram_clk_freq19:27
tplatenI saw19:27
ghostmansd[m]lkcl, about CRs, this reg vs field still confuses me. In vanilla PPC, they have cr0..cr7. We'll have cr0..cr31, right?19:27
ghostmansd[m]Oops, cr0..cr15?19:27
ghostmansd[m]And I repeated SPRs twice; I meant VSRs.19:28
lkclthose are cr *FIELD* numbers19:28
lkclno VSRs. we are not touching Packed SIMD19:28
lkclPower ISA 3.0C, section 1.4 p1019:29
lkclthere is onle one CR, (Condition Register), it is 32-bits in length19:29
lkclPower ISA 3.0C, section 2.3.1 Condition Register p3019:29
lkclThe Condition Register (CR) is a 32-bit register which19:29
lkclreflects the result of certain operations, and provides a19:29
lkclmechanism for testing (and branching).19:29
lkclThe bits in the Condition Register are grouped into19:30
lkcleight 4-bit fields, named CR Field 0 (CR0), ..., CR Field19:30
lkcl7 (CR7), which are set in one of the following ways.19:30
lkcltherefore if you are seeing numbering "cr0" through "cr7", it is referring to CR *FIELDS*19:30
lkcland therefore19:30
lkcl<ghostmansd> [19:34:33] <ghostmansd> 3) 8 CRs, which can be vectorized;19:31
lkclthis is incorrect19:31
lkclit is actually19:31
lkcl3) 8 CR ***FIELDS***, which can be vectorized;19:31
lkcland that, itself, is incorrect19:31
lkclthere are, in SVP64, *128* CR *Fields*19:31
lkclso the totals are:19:32
lkcl1) 128 GPRs19:32
lkcl2) 128 FPRs19:32
lkcl3) 128 CR ***FIELDS***19:32
lkcl                ("r", 0, 32, "PPC_OPERAND_GPR"),19:33
lkcl                ("r", 32, 128, "(PPC_OPERAND_GPR | PPC_OPERAND_SVP64)")19:33
lkcl                ("f", 0, 32, "PPC_OPERAND_FPR"),19:33
lkcl                ("f", 32, 128, "(PPC_OPERAND_FPR | PPC_OPERAND_SVP64)"),19:33
lkcl                ("cr", 0, 8, "PPC_OPERAND_CR"),19:33
lkcl                ("cr", 32, 128, "(PPC_OPERAND_FPR | PPC_OPERAND_SVP64)"),19:33
ghostmansd[m]Ah OK I finally got it19:34
lkcleverything is 128 long19:34
tplatenWhen I set dram_clk_freq to None, I get Failed to find a route for arc 2 of net ddrphy_ddr3_0__a__o_fclk.19:50
ghostmansdlkcl, thanks for explanations. Also, about 128/256... I almost certainly recall there's a way to extend the acrhitecture up to 256 registers. Am I confused, or there's a way? From my understanding that'd be possible by affecting the prefix somehow.21:23
programmerjakeghostmansd: yes, it's possible to extend everything to 256 registers, setvl has reserved bits that we will define to adjust how vectorized register fields are addressed, where they can now address every register in 0-127, they will address every other register in 0-255, further adjustment lets it extend to 0-511, 0-1023, etc...21:48
programmerjakebasically register fields will be shifted left by 0, 1, 2, 3... bits21:49
programmerjakejust occurred to me, we can define one of those reserved setvl bits to change svp64 to fill elements into 128x 128-bit registers for vsx compatibility...just like extending to 256 registers except along a different dimension...imho this is a simple/easy way to resolve all issues I have with svp64+vsx since the sw explicitly requests to use the full 128-bits so it isn't a backward compat hazard21:54
programmerjakelkcl: what do you think of that? ^21:54
programmerjake128-bit registers are useful for more than just vsx, so imho this isn't "poisoning with vsx"21:55
programmerjakeand, no, 128-bit registers aren't required to implement svp64, that setvl will trap if 128-bit registers aren't implemented21:56
lkclanother total chaotic meeting :)22:52
ghostmansd[m]Ok folks I won't be able to participate the second one :-)22:53
ghostmansd[m]This time this was at least close to agenda :-)22:53
ghostmansd[m]My internet connection hid some parts of the meeting, though22:54
ghostmansd[m]OK see you tomorrow!22:54
markoslkcl, re progress update on my part as it has been terribly slow, so construction has been almost finished, only a couple of things remain, work wise, I'm almost done with a couple of Arm contracts so I will be much more available for SVP64 work soon22:56
lkclmarkos, nice. you'll be pleased to know that the horrible-ness "" has gone in media/22:58
markoscan't wait to try it22:58
markosdoes it also mean no more manually calculated offsets for constants? :)22:58
markosbtw, I've installed cockpit won my talos II and love it,22:59
markoswith cockpit-machines22:59
markosif you want sth like proxmox or any other VM management on your Talos II, I highly recommend it23:01

Generated by 2.17.1 by Marius Gedminas - find it at!