Wednesday, 2022-05-18

programmerjakelkcl: you mind if I update yosys.git? master is a year old and I was wondering if you still needed that commit for something00:49
programmerjakeiirc you have the ls2 tag00:49
programmerjakenm, only the ls180 tag00:50
lkclprogrammerjake, yeah go for it01:43
lkclthe ls180 tag is - was - for ls180 (duh)01:43
lkclthe tag that's important (tested / confirmed) is 0.1301:43
lkclman that was a pig to track down just the right version which was during a rework of yosys *and* ghdl *and* yosys-ghdl-plugin01:44
lkclbinary-search (more like random drunken walk) on 3 repos to find just the right cross-over point between the two different sets of API changes01:45
lkclso that's why yosys 0.1301:45
programmerjakeFATAL: W any yosys jacob1 DENIED by fallthru01:45
programmerjakelkcl: ^01:46
lkclprogrammerjake, 1 sec i added you but might not have done a git push, doh :)01:47
programmerjakepushed now01:48
lkclye duh started editing gitolite.conf but i appear to have gone walkabout before committing, doh01:48
lkclclose to 2am and almost falling over, so end-of-day here.01:48
programmerjakei pushed the new tags from upstream too: yosys-0.14 to 0.1701:49
ghostmansd[m]lkcl, I've been thinking about the opcodes and possible collisions in case if multiple vendors reuse the same PO. For binutils, this shouldn't be a problem: which exact insn is emitted depends on the exact -m flags. So, apart of non-technical issue (submitting insns w/o OPF approval), I don't see problems here.08:09
ghostmansd[m]I think we don't need dlopen/dlsym from binutils' developers perpective, they clearly want us to simply us the relevant flag.08:10
programmerjakeimho that sounds good08:16
ghostmansd[m]Yeah, same for me. Other vendors would simply use a different flag.08:31
programmerjakewe'd want the flags needed to somehow indicate the unofficial-experimental nature of the instructions tho...idk what flags you picked08:33
ghostmansd[m]We currently use -mfuture for new insns like fsins/fcoss/etc., and -mlibresoc for SVP64 (this will also include the former).08:52
ghostmansd[m]I'd use -mdraft, but -mfuture was already present.08:53
lkcl-mrhmrhm that makes me so nervous / jumpy09:16
programmerjakeimho we may want to require -mexperimental too09:18
programmerjake-mfuture seems to me to be more of "we already decided we want exactly that but the chip isn't released yet" so seems more prone to confusion09:20
programmerjakewe're highly likely to rearrange which opcodes are used by setvl and friends and bitmanip and fsins/fcoss because the openpower foundation may have another use for those planned already or similar09:21
programmerjakethe sv prefix is less likely to move, but still possible09:22
* lkcl- agrees there about the difference between -mfuture and -mexperimental09:28
lkcl-well there's two opcodes marked as being "free" (EXT05 and EXT09 i think) if you need an entire opcode09:29
programmerjakeext5 is in use by bitmanip...though that may change09:30
lkcl-and bitmanip definitely needs 2 because of a combination of the size of the immediates (8-16 bits) and the number of arguments (3/4-in)09:30
lkcl-(i mean, "once approved and/or proposals may propose to use EXT05 and/or EXT09")09:31
*** littlebo1eep is now known as littlebebeep09:40
*** littlebebeep is now known as littlebobeep09:42
lkcl-i'd be happier with "-mdraft" or better "-munapproved-draft"09:49
ghostmansd[m]Ok I'll refactor the patchset so that we have a new flag10:17
ghostmansd[m]...and will also rebase SVP64 branch atop of it10:18
ghostmansd[m]That said, -mfuture was equal to Power10 before my changes10:18
lkcl-i think that would be best.  even if other people don't understand fully, *we* are the ones that need to act responsibly10:18
lkcl-yes, because - i think - the instructions there had already been approved and ratified by the OPF ISA WG10:19
ghostmansdOk then, let's introduce -mdraft. I'd like to keep it short, though, not "-munapproved-draft".10:21
ghostmansdOr, perhaps, -mexperimental.10:21
lkcl-ok sensible10:21
lkcl-experimental doesn't have the same implications10:21
ghostmansdYeah, fair enough10:21
ghostmansdOK I'll use -mdraft.10:21
ghostmansdupdated HDL workflow with task management guidelines10:52
ghostmansdfolks, please, check and update or reword as needed10:52
programmerjaketwo issues: the nlnet milestone must match the budgeting parent task. generally you'd want to check with lkcl before submitting an rfp rather than after. other than those, it looks generally good!10:58
* lkcl- on it11:06
ghostmansdthanks Luke :-)11:08
lkcl-it was useful even to have just that start11:23
ghostmansdsigh, binutils assume that bits in an operand mask are always contiguous. This is not the case for SVP64Prefix.RM.13:41
ghostmansdMmm... why do we exactly split the RM field bits, I forgot?13:42
ghostmansdAh OK
ghostmansdOK looks like our magic instruction is going to have two operands then14:00
ghostmansdNo, actually three14:02
ghostmansdThe code generation for fields must be refactored, it's not well-apt to binutils as it stands now. I'll think how to handle it better. These scarse fields need separate operands. Also, it'd be better if we had fields offsets for all these operands generated. I have yet to think how to handle it better.14:16
ghostmansdIt became much more obvious after patches for new instructions. :-)14:16
lkcl-ghostmansd: that assumption of binutils breaks down for at least 3 operands. look for d0,d1,d2 for one example14:31
lkcl-that's part of DX-Form14:32
lkcl-TX as well14:33
lkcl-these are all multi-split bitfields14:33
lkcl-they're all non-contiguous14:34
ghostmansdthank you for tip!14:42
ghostmansdI'll check this, if so, we will follow the same conventions14:42
ghostmansdHuh, they cheat14:43
ghostmansdUse PPC_OPSHIFT_INV to indicate that BITM and SHIFT cannot be used to determine where the operand goes in the insn.14:43
ghostmansdSo there's a special mask which circumvents the check for the contiguous bit vector14:44
ghostmansdCool story bro14:44
lkcl-should also include a pointer-to-a-function which allows manual reconstruction.  fxm is one of them i think14:47
ghostmansdyeah, I think the original approach might work14:56
ghostmansdcongrats, I finally made it work :-)15:02
tplatencompared the schematics of the orangecrab with the versa-ecp5, fixed the assignments for dq on orangecrab19:13
tplatenThe error that I had yesterday is gone, now I get19:13
tplatenERROR: DQS group mismatch, port DQSW270 of 'ddrphy.U$$46' in group LDQ41 is driven by DQSBUFM 'ddrphy.U$$45' in group LDQ5319:13
tplatenAttrs also matches between both19:14
programmerjakeseems like that might be worth asking nextpnr or yosys irc about ... they probably have a better idea of what went wrong19:18
tplatenyes, maybe19:19
lkcl-tplaten, i've seen something similar to that before. it probably means you still have the DQ/DQS pins mixed up.19:24
lkcl-such as: you've tried to put DQ0's "positive" with *DQ1's* "negative" together.19:24
tplatenmost likely yes19:25
lkcl-that hypothesis would fit with the error message19:25
tplatenFrom the look at versa_ecp5 schematics which I did today, I remember "p0 p1" "n0 n1"19:26
programmerjakeafaict known-working pad assignments (used by orange crab example):
tplatencorrect, only dqs_p go into the nmigen generated output file19:45
tplatendiffpairs is taking 4 pins, but in the output only two pins appear19:49
tplatenI had a look at nmigen/nmigen/build/, DiffPairs takes argument p as the first one and s as the second one as expected19:54
tplatenso maybe I swapped the RAM_LDQS pair with the RAM_UDQS pair.19:55
ghostmansdI know I shouldn't say it, but it's so fricking annoying to debug when you miss the field in the opcode20:03
ghostmansdand then re-calculate the stuff, and not to forget that you must take the last bit and subtract it from 3120:04
ghostmansd|0     |6     |11  |13   |15   |17   |19   |21  |22   |26     |31 |20:04
ghostmansd| PO   | SVme |mi0 | mi1 | mi2 | mo0 | mo1 |pst |///  | XO        |20:04
ghostmansdthis is what we have in fields.text20:04
ghostmansdbut this is how it looks in binutils: { 0x1, 10, NULL, NULL, 0 },20:04
ghostmansdreally annoying, I will one day generate this because I'm really pissed when I'm forced to calculate this crap20:06
ghostmansdand, of course, the fact that some of the fields duplicate the existing ones and this is forbidden adds the fun to this mess20:08
ghostmansdOK, I've rebased the whole svp64 branch, moved the new SVP64 32-bit opcodes into the common table, and that revealed a lot of issues I had to go through step-by-step20:10
ghostmansdNow going through the actually generated code20:20
ghostmansdlkcl, I've synced to the latest changes in fields.text, but, please, update it whenever you change field.text. It's hard to track both simultaneously.20:41
ghostmansdOr, well, I've synced svshape only, perhaps there's more. I'll check.20:41
ghostmansdAlso svremap.21:02
ghostmansdSo far so good!
ghostmansdOK enough for today.21:06
lkcl-ghostmansd, thx for spotting that. yeah 31-x or 63-x is an utter pain. it is what it is.21:41
lkcl-just so you know, i've been reorganising the bitmanip page
lkcl-which contains the [new] XO values for fitting into the [extremely limited] EXT022 space21:42
lkcl-if you do choose to update it's absolutely critical that you also update to match it, and the CSV files as well21:43
lkcl-so for example you shifted XO along by one bit21:43
lkcl-(technically the right thing to do according to fields.txt)21:44
lkcl--            # |0  |6        |11      |16    |21    |25 |26    |31  |21:44
lkcl--            # |PO |  SVxd   |   SVyd | SVzd | SVRM |vf |   XO |  / |21:44
lkcl-+            # |0     |6        |11      |16    |21    |25 |26    |31  |21:44
lkcl-+            # | PO   |  SVxd   |   SVyd | SVzd | SVRM |vf |   XO      |21:44
lkcl--            insn |= 0b00001 << (31-30)  # XO       , bits 26..3021:44
lkcl-+            insn |= 0b00001 << (31-31)        # XO         , bits 26..3121:44
lkcl-now PowerDecoder2 does not match it21:45
lkcl-sorry PowerDecoder21:45
lkcl- 737         Subdecoder(pattern=22, opcodes=get_csv("minor_22.csv"),21:46
lkcl- 738                    opint=True, bitsel=(1, 5),21:46
* lkcl- screams21:46
lkcl-are in LSB0 order.21:46
lkcl-bitsel=(1, 5)21:46
lkcl-now that i look at it, these are in LSB0 order21:47
* lkcl- cries21:47
lkcl-but the point is, you adapted the XO field from 31-26 to 31-3021:47
lkcl-31-26 to 31-3121:47
lkcl-but did not correspondingly change bitsel=(1,5) to bitsel=(0,5)21:47
programmerjakemeeting in 10min21:48
lkcl-and also did not update major_22.csv to add the extra bit21:48
lkcl-so now, neither svshape nor svremap will work21:49
lkcl-because will create a pattern that is *not* correctly decoded by PowerDecoder()21:49
lkcl-which is why i hadn't updated even though it's not quite exactly according to the spec21:49
lkcl-because there are quite a few moving pieces that all need to be updated simultaneously21:50
ghostmansd[m]What a shame21:50
lkcl-programmerjake, ack. lxo markos toshywoshy cesar octavius sadoon[m] (excited-mango[m] if you're interested this is a bi-weekly meeting but has a set agenda)21:50
lkcl-ghostmansd[m], i know, the above sort-of really should be documented and i think is... partly... somewhere21:51
ghostmansd[m]This looked so trivial, sorry :-(21:51
ghostmansd[m]I think this should not be documented, but, rather, should be generated and come to all these places21:52
programmerjakeghostmansd if you want you can attend the meeting too...21:52
ghostmansd[m]BTW what so you discuss on these meetings?21:52
lkcl-yes is a hack21:52
ghostmansd[m]programmerjake reads my mind :-D21:52
lkcl-status updates with the OPF.21:53
lkcl-it's a set agenda, very fast-paced, a lot to cover21:53
ghostmansd[m]Nice! You mentioned it's biweekly, when's the next session?21:53
ghostmansd[m]Today I won't be able to attend, but will try next time21:54
programmerjakethe agenda should cc a mailing list...lkcl can you do that from now on?21:54
lkcl-yes good idea21:54
programmerjakenext status update is 2 weeks from now21:54
programmerjakethere's also meetings where we talk about whatever every tuesday21:55
ghostmansd[m]It'd be way better if these were a hour or two earlier :-)21:57
programmerjakesorry it's soo late for you ghostmansd, trying to make it work for us, europe, and australia21:57
ghostmansd[m]Yeah I know :-)21:57
ghostmansd[m]I'll try visiting the Tuesday session21:59
ghostmansd[m]I guess the link is the same, eh?22:00

Generated by 2.17.1 by Marius Gedminas - find it at!