| Veera[m] | cached property in functools was added with Python-3.8! And I have the default Python-3.7 installed with Buster | 03:41 |
|---|---|---|
| lkcl | python3 budget_sync | 10:17 |
| lkcl | checked that, you're right | 10:20 |
| lkcl | programmerjake, ^ can you please remove cached_property from budget_sync | 10:21 |
| *** henriok_ is now known as henriok | 11:56 | |
| ghostmansd | Hi folks, I have some issues upon running `sudo bash ../dev-env-setup/hdl-dev-repos-virtualenv` | 12:30 |
| ghostmansd | https://pastebin.com/qEWZDGDK | 12:31 |
| ghostmansd | Is anyone familiar with this? It's been a while since I established the repos | 12:31 |
| ghostmansd | That's for local setup, not talos | 12:32 |
| ghostmansd | Same for `sudo bash ../dev-env-setup/hdl-dev-repos` | 12:39 |
| lkcl | git submodule update. | 12:48 |
| lkcl | it means you've not done "git pull" or "git submodule update" since tuesday. | 12:49 |
| lkcl | https://git.libre-soc.org/?p=soc.git;a=commitdiff;h=d40d5ded858bf09b7b46838d47410c9dc957167f | 12:49 |
| lkcl | ghostmansd, ^ | 12:49 |
| ghostmansd[m] | Not sure if I should; this soc repository is handled as part of hdl-dev-repos, isn't it? | 13:02 |
| ghostmansd[m] | lkcl: I suspect it happens on `make gitupdate`, it must've taken the wrong revision | 13:19 |
| ghostmansd[m] | No, even `git submodule update --init --recursive` doesn't help | 13:20 |
| lkcl | sadoon_albader[m ran git pull and then submodule update and it worked fine | 14:58 |
| lkcl | there's been some changes to pinmux in the past 2 weeks | 14:59 |
| lkcl | toshywoshy, mattermost bridging seems to have stopped at about tuesday | 15:10 |
| lkcl | Veera[m], you can look through the source code for the function "exts" | 15:25 |
| lkcl | with "grep -r" | 15:25 |
| lkcl | or ctags -R in the top-level directory | 15:26 |
| lkcl | then ":tag exts" in vim | 15:27 |
| lkcl | Veera[m], openpower.decoder.helpers. you could have also done, "find . -name "helpers.py" | 15:35 |
| Veera[m] | lkcl: I found it beforehand | 16:40 |
| Veera[m] | lkcl: I git pulled both openpower-isa and soc repo | 16:41 |
| Veera[m] | ran make pywriter but now the tests are not finishing | 16:42 |
| Veera[m] | they are stalling at decode2execute init tmp <class 'openpower.decoder.decode2execute1.Decode2ToOperand'> None | 16:43 |
| Veera[m] | running make mkpinmux in soc repo gives error!!! | 17:24 |
| Veera[m] | Traceback (most recent call last): | 17:24 |
| Veera[m] | File "src/pinmux_generator.py", line 101, in <module> | 17:24 |
| Veera[m] | pm, chip = jsoncreate.pinparse(ps, pinspec) | 17:24 |
| Veera[m] | File "/home/vklr/src/soc/pinmux/src/jsoncreate.py", line 217, in pinparse | 17:24 |
| Veera[m] | padbank[banknum] = name | 17:25 |
| Veera[m] | IndexError: list assignment index out of range | 17:25 |
| Veera[m] | make: *** [Makefile:10: mkpinmux] Error 1 | 17:25 |
| Veera[m] | And pinmux git log outputs commit 20ca612b2600530ce901009b3d1b9ef0e05b7438 | 17:25 |
| Veera[m] | The same problem ghostmansd has/had! | 17:26 |
| Veera[m] | ghostmansd[m]: I solved the problem temporarily with: cd soc; cd pinmux; git checkout 1d16fd5b277d276f2e7603e888be359083cec09a; cd ..; make mkpinmux | 17:36 |
| Veera[m] | I think pinmux is work in progress for now and broken. You can ask lkcl andrey for more recent commit which works | 17:37 |
| programmerjake | lkcl: fixed budget-sync, you'll need to rerun setup.py | 18:09 |
| Veera[m] | programmerjake: yes cached_property error has gone. | 18:54 |
| Veera[m] | programmerjake: But there are other errors: KeyError: 'NLnet.2021-08-049.coriolis2' | 18:56 |
| Veera[m] | programmerjake: And also budget allotment errors | 18:57 |
| programmerjake | yeah, those errors mean that the new milestones need to be added to budget-sync-config.toml, as well as the inconsistent information corrected on bugzilla...note that #48 and #191 should be left unfixed | 19:15 |
| programmerjake | i'll fix that... | 19:15 |
| programmerjake | Veera: ok, i fixed it. ignore the errors for #48, #191, and #589, we're aware of them and are intentionally leaving it that way. if other errors show up, check with @lkcl or fix the allocation in bugzilla if you messed it up by miscalculating | 19:42 |
| lkcl | 2021-08-049 is a new grant | 19:51 |
| lkcl | so is... #589. | 19:51 |
| lkcl | "NLnet.2021.02A.CryptoRouter" = { canonical_bug_id = 589 } | 19:53 |
| lkcl | "NGI POINTER Gigabit ASIC" = { canonical_bug_id = 690 } | 19:53 |
| lkcl | "NLnet.2021-08-049.coriolis2" = { canonical_bug_id = 748 } | 19:53 |
| lkcl | brilliant, thx programmerjake, saves me a job | 19:53 |
| lkcl | ERROR:root:Budget assigned to task including subtasks (cf_total_budget field) doesn't match calculated value: bug #589, calculated value 9000 | 19:54 |
| lkcl | that's because the cryptorouter one hasn't had the MoU signed yet | 19:54 |
| ghostmansd | lkcl: I'll need some help and clarification regarding sv_analysis.py and binutils. I'm checking sv_decode.vhdl and I think I can hack/copy sv_analysis to produce some C-compatible stuff, but I have no idea how it correlates with binutils, except for perhaps an opcode (and even there I'm not sure how to treat records like `-----10110`). | 20:00 |
| ghostmansd | I also don't get anything close to 10000 of instructions; $(wc -l openpower/isatables/sv_decode.vhdl) shows 348 lines, many of these are boilerplate. | 20:01 |
| ghostmansd | My main question is, I don't understand what to use and how. I can generate some C table of structures, for sure, but I need to know which kind of info should be there. | 20:04 |
| ghostmansd | Let's consider some instructions, e.g. `extsw` and `extsw.`, which have entries in powerpc_opcodes. `extsw` I can also see in `sv_decode.vhdl` (there's none for `extsw.`, though). | 20:06 |
| ghostmansd | It'd be great if we could dissect what should be the relevant definition for the structures, e.g. what `struct svp64_opcode_augmentation` entry should `extsw` and `extsw.` have. | 20:08 |
| ghostmansd | I assume we also need some check for `sv.` prefix so that it's considered, right? | 20:09 |
| lkcl | ghostmansd[m], ok let's go through it | 20:20 |
| lkcl | https://git.libre-soc.org/?p=binutils-gdb.git;a=blob;f=opcodes/ppc-opc.c;h=bbbadffad8f62f867c53630b9bf67cfe72ecfed6;hb=84629a61ee0f459a78e245e5aa41bec73f30c4d1 | 20:21 |
| lkcl | is 10,748 lines long. | 20:21 |
| lkcl | starting from 4280, running to 10,748, so there are "only" 6,500 Power ISA instructions, not 10,000. | 20:22 |
| lkcl | clearly it would be f****g stupid to even attempt to add SVP64 encoding to that, by hand. | 20:22 |
| lkcl | particularly when much of it is duplicated. | 20:23 |
| ghostmansd[m] | Yehyeh, binutils part I plus or minus get | 20:23 |
| programmerjake | lkcl, you allocated more money for #730 but forgot to update its parent | 20:23 |
| ghostmansd[m] | I have no fricking idea of what this VHDL is and how sv.whatever corresponds to a simple whatever | 20:24 |
| programmerjake | i'll do that | 20:24 |
| lkcl | add, add. addo, addo. they are all identical SVP64 encoding, so it would need 4 duplicate copies of hand-edited SVP64 information to be added to all 4 | 20:24 |
| lkcl | the VHDL itself is not important, it's the fact that it's an auto-generated table that's important | 20:25 |
| lkcl | programmerjake, thx, just concentrating on binutils with ghostmansd[m] | 20:25 |
| lkcl | so the basic principle is - as you can see in svp64.py - which literally needs translating into c - is: | 20:26 |
| lkcl | "sv.add RT, RA, RB" instruction is encountered | 20:26 |
| lkcl | the fields RT, RA, and RB are now 7-bit, not 5-bit | 20:26 |
| lkcl | 2 of those bits go into the 24-bit prefix. | 20:26 |
| lkcl | the remainder of the 5-bit fields *remains in the 32-bit opcode*, exactly as if it was a Power ISA 3.0 32-bit operation | 20:27 |
| lkcl | thus, when the hardware (and simulator) encounters a 64-bit SVP64 Prefix, it: | 20:27 |
| ghostmansd[m] | Two more bits indicate the XLEN? | 20:27 |
| lkcl | 1) extracts the 24-bit SV "RM" field from the first 32-bits | 20:28 |
| lkcl | 2) **RECONSTRUCTS** the 7-bit register numbers based on 2-bits in SV "RM" and the 5-bit fields in the 32-bit Power ISA 3.0 instruction | 20:28 |
| lkcl | yes, funnily enough | 20:28 |
| lkcl | ELWIDTH encoding - https://libre-soc.org/openpower/sv/svp64/ | 20:29 |
| lkcl | now, where it gets bloody complicated is that, actually, those register number "enhancements" can either mark those (extended-to-7-bit) register numbers as either | 20:30 |
| lkcl | 1) scalar | 20:30 |
| lkcl | 2) vector | 20:30 |
| lkcl | so that's actually *3* bits per register, not 2. | 20:30 |
| lkcl | BUT | 20:30 |
| lkcl | as you probably already worked out: | 20:30 |
| lkcl | say for e.g. FMAC, 3 bits times 4 registers (Rt RA RB RC) is 12 bits | 20:31 |
| lkcl | and that's far too much | 20:31 |
| lkcl | soooo.... | 20:31 |
| lkcl | to cope with that.... | 20:31 |
| lkcl | we have *two* different encodings for registers | 20:31 |
| lkcl | EXTRA2 | 20:31 |
| lkcl | and EXTRA3 | 20:31 |
| lkcl | EXTRA2 is *only two* bits per register | 20:32 |
| lkcl | EXTRA3 is *three* bits per register | 20:32 |
| lkcl | and the sv_analysis.py program basically encodes | 20:32 |
| lkcl | which instructions are encoded as EXTRA2 | 20:32 |
| lkcl | and which are encoded as EXTRA3 | 20:32 |
| lkcl | it also specifies the relationship / mapping between EXTRA2[0..3] and EXTRA3[0..2] to RA/RB/RC/RT/EA | 20:33 |
| lkcl | and *that* is the information that is auto-generated by sv_analysis.py | 20:33 |
| lkcl | without which it is literally impossible to decode the SV64 24-bit prefix | 20:33 |
| lkcl | and if you tried to do it by hand you would create a total maintenance nightmare and also 100% guaranteed get it wrong simply through typing. | 20:34 |
| lkcl | so | 20:38 |
| lkcl | to get through that barrier, in python (sv/trans/svp64.py), sv_analysis.py creates some CSV files which provide the "augmentation" information | 20:38 |
| lkcl | which if you're not looking for it, isn't obvious, it's this one line of code that picks up all the CSV files: | 20:39 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/trans/svp64.py;h=45b292b4c4c32bbff548f2bf299235633d31db6c;hb=ca475c00b80c1b66d03505e1d7ba6f26a379ff2e#l157 | 20:39 |
| lkcl | actually, sorry, that's picking up the markdown pseudocode but is using the register encoding information from it | 20:41 |
| lkcl | field1: RT | 20:41 |
| lkcl | field2: RA | 20:41 |
| lkcl | field3: RB | 20:41 |
| lkcl | from e.g. addi RT,RA,RB | 20:41 |
| lkcl | you'll be able to use sv/trans/svp64.py to double-check what you do. the results should always be identical | 20:45 |
| lkcl | let's take an example from the auto-generated SVP64 CSV files | 20:45 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=openpower/isatables/RM-1P-2S1D.csv;hb=HEAD#l45 | 20:45 |
| lkcl | 1 insn,CONDITIONS,Ptype,Etype,0,1,2,3,in1,in2,in3,out,CR in,CR out,out2 | 20:45 |
| lkcl | 45 add,,1P,EXTRA3,d:RT;d:CR0,s:RA,s:RB,0,RA,RB,0,RT,0,CR0,0 | 20:46 |
| lkcl | Predicate-Type (number of predicates) is 1P - so only one predicate mask | 20:46 |
| lkcl | E-Type (Extra Type) = EXTRA3. | 20:46 |
| lkcl | therefore, we have had it declared to us that from here https://libre-soc.org/openpower/sv/svp64/ Section 12 | 20:47 |
| lkcl | actually section 12.4 - 1P-2S1D (number of predicate masks: 1 number of source regs: 2 number of dest regs: 1) | 20:48 |
| lkcl | that ... err hang on, 12.4 isn't correct for that because the CSV file declares it as EXTRA3, the 12.4 table is for EXTRA2... | 20:49 |
| lkcl | so... | 20:49 |
| lkcl | 12.3 | 20:49 |
| lkcl | Rdest_EXTRA310:12extends Rdest | 20:49 |
| lkcl | Rsrc1_EXTRA313:15extends Rsrc1 | 20:50 |
| lkcl | therefore, in the CSV file "0" column, you see d:RT | 20:50 |
| lkcl | and in the "1" column you see "s:RA" | 20:50 |
| lkcl | and in the "2" column you see "s:RB" | 20:51 |
| lkcl | which, ha, that is Rsrc2_EXTRA3 which should be in bits 16:18 extending Rsrc2 | 20:51 |
| lkcl | i need to edit the svp64 wiki 1 sec | 20:51 |
| lkcl | done | 20:53 |
| lkcl | new section 12.4 RM-1P-2S1D | 20:53 |
| lkcl | Rdest_EXTRA310:12extends Rdest | 20:54 |
| lkcl | Rsrc1_EXTRA313:15extends Rsrc1 | 20:54 |
| lkcl | Rsrc2_EXTRA316:18extends Rsrc2 | 20:54 |
| lkcl | okaaay. | 20:54 |
| lkcl | *now* it matches what's in the CSV file. | 20:54 |
| lkcl | the line 45 add,,1P,EXTRA3,.... says | 20:54 |
| lkcl | "to decode RT which is marked as destination (d:RT) you must use the EXTRA3 bits 10:12 which are in the 24-bit SVP64 prefix" | 20:55 |
| lkcl | "to decode RA which is marked as src1 (s:RA) you must use the EXTRA3 bits 13:15 which are in the 24-bit SVP64 prefix" | 20:55 |
| lkcl | "to decode RB which is marked as src2 (s:RB) you must use the EXTRA3 bits 16:18 which are in the 24-bit SVP64 prefix" | 20:56 |
| lkcl | there is *NOT* enough room in the actual 24-bit RM field for it to be self-describing | 20:56 |
| lkcl | therefore | 20:56 |
| lkcl | you *HAVE* to partially-decode the v3.0 mnemonic. sv.add ==> Power ISA v3.0 "add" instruction | 20:57 |
| lkcl | ==> look up the SVP64 CSV file entry for "add" | 20:57 |
| lkcl | ==> 45 add,,1P,EXTRA3,d:RT;d:CR0,s:RA,s:RB,0,RA,RB,0,RT,0,CR0,0 | 20:57 |
| lkcl | and THAT is why you need to augment the ppc_ops tables with pointers to SVP64 information struct svp64_augmentation_info | 20:58 |
| lkcl | because you must | 20:58 |
| lkcl | 1) identify the Power v3.0B operation FIRST | 20:58 |
| lkcl | 2) look up the SVP64 information SECOND | 20:58 |
| lkcl | 3) use the designation EXTRA2/3 and the d:RT s:RA (etc) information to decide what to put into bits 10:18. | 20:59 |
| lkcl | it is very much a mundane by-rote task that is literally the translation of sv/trans/svp64.py into c. | 21:00 |
| lkcl | it doesn't *actually* need "understanding" of SVP64 itself. | 21:00 |
| lkcl | it's literally "if recognise these strings / ASCII characters, blat these binary 1s/0s into certain bit fields" | 21:01 |
| lkcl | i would suggest starting small | 21:02 |
| lkcl | don't even bother at the moment with the reg number remapping. | 21:02 |
| lkcl | start with recognising say.. | 21:03 |
| * lkcl looking for some bitfields that are mandatory and unconditionally-positioned.. | 21:03 | |
| lkcl | SUBVL | 21:03 |
| lkcl | section 7 "common RM fields" | 21:04 |
| lkcl | 45 add,,1P,EXTRA3,d:RT;d:CR0,s:RA,s:RB,0,RA,RB,0,RT,0,CR0,0 | 21:04 |
| lkcl | whoops | 21:04 |
| lkcl | SUBVL8:9Sub-vector length | 21:04 |
| lkcl | sv.add/vec2 | 21:04 |
| lkcl | sv.add/vec3 | 21:04 |
| lkcl | sv.add/vec4 | 21:04 |
| lkcl | if strcmp(sub_field, "vec2") { svp64_rm |= (1<<8 } | 21:05 |
| lkcl | if strcmp(sub_field, "vec3") { svp64_rm |= (2<<8 } | 21:05 |
| lkcl | if strcmp(sub_field, "vec4") { svp64_rm |= (3<<8 } | 21:05 |
| lkcl | that's it. | 21:05 |
| lkcl | that's SUBVL done. | 21:05 |
| lkcl | equivalent python: | 21:06 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/trans/svp64.py;h=45b292b4c4c32bbff548f2bf299235633d31db6c;hb=ca475c00b80c1b66d03505e1d7ba6f26a379ff2e#l652 | 21:06 |
| cesar | I remember gaining a much better undersranding of SVP64 when Luke presented it live, going over the wiki, topic by topic. | 21:23 |
| cesar | ... but then, we were reviewing it, and had a wider audience... | 21:25 |
| programmerjake | lkcl: well, i'm trying to get my friend's printer to work for printing the stuff I need to sign for fundingbox, currently the black ink doesn't work at all, i may run out of time today so not get around to ternlogi, sorry | 23:24 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!