| *** kylel1 is now known as kylel | 07:11 | |
| lkcl | Veera[m], images look great, sorry i made one mistake, the sums inside the right-end box should be | 08:23 |
|---|---|---|
| lkcl | 0+4+8 | 08:23 |
| lkcl | 1+5+9 | 08:23 |
| lkcl | 2+6+10 | 08:23 |
| lkcl | 3+7+11 | 08:23 |
| lkcl | ghostmansd[m], https://www.timeanddate.com/worldclock/converter.html?iso=20220629T210000&p1=tz_gmt&p2=tz_bst&p3=tz_msk&p4=47&p5=179&p6=224 | 09:03 |
| lkcl | the only reason it appears to be a day later is because it's at 00:00 local time. | 09:04 |
| ghostmansd | Updated the script: https://pastebin.com/FcFxbEQM | 17:53 |
| lkcl | ("r", 32, 256, "(PPC_OPERAND_GPR | PPC_OPERAND_SVP64)"), | 18:38 |
| lkcl | sensible | 18:38 |
| ghostmansd | Yeah 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 |
| ghostmansd | And, still, what about other registers? | 18:55 |
| ghostmansd | WTF | 18:55 |
| ghostmansd | All my messages disappeared | 18:55 |
| ghostmansd | At least nothing in IRC logs | 18:56 |
| ghostmansd | No 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 |
| lkcl | actual numbers: 128 GPRs, 128 FPRs, 16 32-bit CRs | 19:07 |
| lkcl | no VRs | 19:07 |
| lkcl | QTY 16of 32-bit CRs for a total of 128 CR *fields* | 19:07 |
| tplaten | I had a look at ecp5ddrphy.py which uses a ClockSignal("dramsync2x") | 19:11 |
| tplaten | The signal must be connected, if not I get TSHX2DQA 'ddrphy.U$$88' cannot have disconnected ECLK | 19:11 |
| tplaten | I guess when there is only one clock that signal needs to be conntedted to dramsync, but I'm not sure here. | 19:12 |
| lkcl | tplaten, 305 m.d.comb += ClockSignal("dramsync2x").eq(ClockSignal("sync2x")) | 19:16 |
| lkcl | https://git.libre-soc.org/?p=ls2.git;a=blob;f=src/ecp5_crg.py;h=403ff7d1ce1427bcc6b71ae27d7c910a19d25075;hb=3ebe4b322911d2ed37b126872b520960ad4179c1#l305 | 19:16 |
| lkcl | it looks like you've set the dram frequency to an explicit number rather than to None | 19:17 |
| tplaten | I've fixed one line that in the meanwhile, but did not commit my changes yet | 19:21 |
| lkcl | please don't make *any* changes to ecp5_crg.py | 19:24 |
| lkcl | at all | 19:24 |
| lkcl | several hardware modules rely on it and you don't have those systems to test changes | 19:25 |
| lkcl | so please *do not* make *any* modifications to ecp5_crg.py of any kind | 19:25 |
| tplaten | No, I did not change that one. I only changed ls2.py, only the orangecrab section | 19:26 |
| lkcl | ok. | 19:26 |
| lkcl | if you don't have dram_clk_freq=None, you will find that the wrong code is executed in ecp5_crg.py | 19:26 |
| lkcl | and several other places | 19:26 |
| tplaten | I have dram_clk_freq set to None | 19:27 |
| lkcl | 881 # merge dram_clk_freq with clk_freq if the same | 19:27 |
| lkcl | 882 if clk_freq == dram_clk_freq: | 19:27 |
| lkcl | 883 dram_clk_freq = None | 19:27 |
| lkcl | this happens automatically if clk_freq == dram_clk_freq | 19:27 |
| tplaten | I saw | 19: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 |
| lkcl | those are cr *FIELD* numbers | 19:28 |
| lkcl | no VSRs. we are not touching Packed SIMD | 19:28 |
| lkcl | Power ISA 3.0C, section 1.4 p10 | 19:29 |
| lkcl | there is onle one CR, (Condition Register), it is 32-bits in length | 19:29 |
| lkcl | Power ISA 3.0C, section 2.3.1 Condition Register p30 | 19:29 |
| lkcl | The Condition Register (CR) is a 32-bit register which | 19:29 |
| lkcl | reflects the result of certain operations, and provides a | 19:29 |
| lkcl | mechanism for testing (and branching). | 19:29 |
| lkcl | . | 19:30 |
| lkcl | The bits in the Condition Register are grouped into | 19:30 |
| lkcl | eight 4-bit fields, named CR Field 0 (CR0), ..., CR Field | 19:30 |
| lkcl | 7 (CR7), which are set in one of the following ways. | 19:30 |
| lkcl | . | 19:30 |
| lkcl | therefore if you are seeing numbering "cr0" through "cr7", it is referring to CR *FIELDS* | 19:30 |
| lkcl | and therefore | 19:30 |
| lkcl | <ghostmansd> [19:34:33] <ghostmansd> 3) 8 CRs, which can be vectorized; | 19:31 |
| lkcl | this is incorrect | 19:31 |
| lkcl | it is actually | 19:31 |
| lkcl | 3) 8 CR ***FIELDS***, which can be vectorized; | 19:31 |
| lkcl | and that, itself, is incorrect | 19:31 |
| lkcl | there are, in SVP64, *128* CR *Fields* | 19:31 |
| lkcl | so the totals are: | 19:32 |
| lkcl | 1) 128 GPRs | 19:32 |
| lkcl | 2) 128 FPRs | 19:32 |
| lkcl | 3) 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 it | 19:34 |
| lkcl | everything is 128 long | 19:34 |
| tplaten | When 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 |
| ghostmansd | lkcl, 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 |
| programmerjake | ghostmansd: 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 |
| programmerjake | basically register fields will be shifted left by 0, 1, 2, 3... bits | 21:49 |
| programmerjake | just 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 hazard | 21:54 |
| programmerjake | lkcl: what do you think of that? ^ | 21:54 |
| programmerjake | 128-bit registers are useful for more than just vsx, so imho this isn't "poisoning with vsx" | 21:55 |
| programmerjake | and, no, 128-bit registers aren't required to implement svp64, that setvl will trap if 128-bit registers aren't implemented | 21:56 |
| lkcl | another 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, though | 22:54 |
| ghostmansd[m] | OK see you tomorrow! | 22:54 |
| ghostmansd[m] | gn | 22:55 |
| octavius | gn | 22:55 |
| programmerjake | gn | 22:55 |
| markos | lkcl, 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 soon | 22:56 |
| lkcl | markos, nice. you'll be pleased to know that the horrible-ness "#sv.xyz" has gone in media/ | 22:58 |
| markos | can't wait to try it | 22:58 |
| markos | does it also mean no more manually calculated offsets for constants? :) | 22:58 |
| markos | btw, I've installed cockpit won my talos II and love it, | 22:59 |
| markos | with cockpit-machines | 22:59 |
| markos | if you want sth like proxmox or any other VM management on your Talos II, I highly recommend it | 23:01 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!