| programmerjake | lkcl: you mind if I update yosys.git? master is a year old and I was wondering if you still needed that commit for something | 00:49 |
|---|---|---|
| programmerjake | iirc you have the ls2 tag | 00:49 |
| programmerjake | nm, only the ls180 tag | 00:50 |
| lkcl | programmerjake, yeah go for it | 01:43 |
| lkcl | the ls180 tag is - was - for ls180 (duh) | 01:43 |
| programmerjake | k | 01:43 |
| lkcl | the tag that's important (tested / confirmed) is 0.13 | 01:43 |
| lkcl | man that was a pig to track down just the right version which was during a rework of yosys *and* ghdl *and* yosys-ghdl-plugin | 01:44 |
| lkcl | binary-search (more like random drunken walk) on 3 repos to find just the right cross-over point between the two different sets of API changes | 01:45 |
| lkcl | so that's why yosys 0.13 | 01:45 |
| programmerjake | FATAL: W any yosys jacob1 DENIED by fallthru | 01:45 |
| programmerjake | lkcl: ^ | 01:46 |
| lkcl | programmerjake, 1 sec i added you but might not have done a git push, doh :) | 01:47 |
| programmerjake | pushed now | 01:48 |
| lkcl | ye duh started editing gitolite.conf but i appear to have gone walkabout before committing, doh | 01:48 |
| lkcl | magic | 01:48 |
| lkcl | close to 2am and almost falling over, so end-of-day here. | 01:48 |
| programmerjake | i pushed the new tags from upstream too: yosys-0.14 to 0.17 | 01: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 |
| ghostmansd[m] | *use | 08:10 |
| programmerjake | imho that sounds good | 08:16 |
| ghostmansd[m] | Yeah, same for me. Other vendors would simply use a different flag. | 08:31 |
| programmerjake | we'd want the flags needed to somehow indicate the unofficial-experimental nature of the instructions tho...idk what flags you picked | 08: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 / jumpy | 09:16 |
| programmerjake | imho we may want to require -mexperimental too | 09: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 confusion | 09:20 |
| programmerjake | we'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 similar | 09:21 |
| programmerjake | the sv prefix is less likely to move, but still possible | 09:22 |
| * lkcl- agrees there about the difference between -mfuture and -mexperimental | 09:28 | |
| lkcl- | well there's two opcodes marked as being "free" (EXT05 and EXT09 i think) if you need an entire opcode | 09:29 |
| programmerjake | ext5 is in use by bitmanip...though that may change | 09: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 |
| programmerjake | yeah... | 09:33 |
| *** littlebo1eep is now known as littlebebeep | 09:40 | |
| *** littlebebeep is now known as littlebobeep | 09: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 flag | 10:17 |
| ghostmansd[m] | ...and will also rebase SVP64 branch atop of it | 10:18 |
| ghostmansd[m] | That said, -mfuture was equal to Power10 before my changes | 10:18 |
| lkcl- | i think that would be best. even if other people don't understand fully, *we* are the ones that need to act responsibly | 10:18 |
| lkcl- | yes, because - i think - the instructions there had already been approved and ratified by the OPF ISA WG | 10:19 |
| ghostmansd | Ok then, let's introduce -mdraft. I'd like to keep it short, though, not "-munapproved-draft". | 10:21 |
| ghostmansd | Or, perhaps, -mexperimental. | 10:21 |
| lkcl- | ok sensible | 10:21 |
| lkcl- | experimental doesn't have the same implications | 10:21 |
| ghostmansd | Yeah, fair enough | 10:21 |
| ghostmansd | OK I'll use -mdraft. | 10:21 |
| lkcl- | star | 10:21 |
| ghostmansd | updated HDL workflow with task management guidelines | 10:52 |
| ghostmansd | folks, please, check and update or reword as needed | 10:52 |
| programmerjake | two 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 it | 11:06 | |
| ghostmansd | thanks Luke :-) | 11:08 |
| lkcl- | it was useful even to have just that start | 11:23 |
| ghostmansd | sigh, binutils assume that bits in an operand mask are always contiguous. This is not the case for SVP64Prefix.RM. | 13:41 |
| ghostmansd | Mmm... why do we exactly split the RM field bits, I forgot? | 13:42 |
| ghostmansd | Ah OK https://libre-soc.org/openpower/sv/svp64/ | 13:56 |
| ghostmansd | OK looks like our magic instruction is going to have two operands then | 14:00 |
| ghostmansd | No, actually three | 14:02 |
| ghostmansd | The 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 |
| ghostmansd | It 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 example | 14:31 |
| lkcl- | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=openpower/isatables/fields.text;h=eb962688ca674db58b65100a159c1b20cfbbb886;hb=e4142b9e970ae21639ed5a8884d193f57ffc463a#l395 | 14:31 |
| lkcl- | that's part of DX-Form | 14:32 |
| lkcl- | TX as well | 14:33 |
| lkcl- | AX,A | 14:33 |
| lkcl- | BX,B | 14:33 |
| lkcl- | CX,C | 14:33 |
| lkcl- | TX,T | 14:33 |
| lkcl- | dc,dm,dx | 14:33 |
| lkcl- | these are all multi-split bitfields | 14:33 |
| lkcl- | SX,S | 14:34 |
| lkcl- | they're all non-contiguous | 14:34 |
| ghostmansd | thank you for tip! | 14:42 |
| ghostmansd | I'll check this, if so, we will follow the same conventions | 14:42 |
| ghostmansd | Huh, they cheat | 14:43 |
| ghostmansd | Use PPC_OPSHIFT_INV to indicate that BITM and SHIFT cannot be used to determine where the operand goes in the insn. | 14:43 |
| ghostmansd | So there's a special mask which circumvents the check for the contiguous bit vector | 14:44 |
| ghostmansd | Cool story bro | 14:44 |
| lkcl- | should also include a pointer-to-a-function which allows manual reconstruction. fxm is one of them i think | 14:47 |
| ghostmansd | yeah, I think the original approach might work | 14:56 |
| ghostmansd | congrats, I finally made it work :-) | 15:02 |
| lkcl- | hooo-raah | 15:43 |
| tplaten | compared the schematics of the orangecrab with the versa-ecp5, fixed the assignments for dq on orangecrab | 19:13 |
| tplaten | The error that I had yesterday is gone, now I get | 19:13 |
| tplaten | ERROR: DQS group mismatch, port DQSW270 of 'ddrphy.U$$46' in group LDQ41 is driven by DQSBUFM 'ddrphy.U$$45' in group LDQ53 | 19:13 |
| tplaten | Attrs also matches between both | 19:14 |
| programmerjake | seems like that might be worth asking nextpnr or yosys irc about ... they probably have a better idea of what went wrong | 19:18 |
| tplaten | yes, maybe | 19: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 |
| tplaten | most likely yes | 19:25 |
| lkcl- | that hypothesis would fit with the error message | 19:25 |
| tplaten | From the look at versa_ecp5 schematics which I did today, I remember "p0 p1" "n0 n1" | 19:26 |
| programmerjake | afaict known-working pad assignments (used by orange crab example): https://github.com/litex-hub/litex-boards/blob/64773b40850dfb94aae1ab82e1169c5a449435a0/litex_boards/platforms/gsd_orangecrab.py#L110 | 19:42 |
| tplaten | correct, only dqs_p go into the nmigen generated output file | 19:45 |
| tplaten | diffpairs is taking 4 pins, but in the output only two pins appear | 19:49 |
| tplaten | I had a look at nmigen/nmigen/build/dsl.py, DiffPairs takes argument p as the first one and s as the second one as expected | 19:54 |
| tplaten | so maybe I swapped the RAM_LDQS pair with the RAM_UDQS pair. | 19:55 |
| ghostmansd | I know I shouldn't say it, but it's so fricking annoying to debug when you miss the field in the opcode | 20:03 |
| ghostmansd | and then re-calculate the stuff, and not to forget that you must take the last bit and subtract it from 31 | 20: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 |
| ghostmansd | this is what we have in fields.text | 20:04 |
| ghostmansd | but this is how it looks in binutils: { 0x1, 10, NULL, NULL, 0 }, | 20:04 |
| ghostmansd | really annoying, I will one day generate this because I'm really pissed when I'm forced to calculate this crap | 20:06 |
| ghostmansd | and, of course, the fact that some of the fields duplicate the existing ones and this is forbidden adds the fun to this mess | 20:08 |
| ghostmansd | OK, 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-step | 20:10 |
| ghostmansd | Now going through the actually generated code | 20:20 |
| ghostmansd | lkcl, I've synced svp64.py 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 |
| ghostmansd | Or, well, I've synced svshape only, perhaps there's more. I'll check. | 20:41 |
| ghostmansd | Also svremap. | 21:02 |
| ghostmansd | So far so good! https://pastebin.com/6nPFGbGD | 21:04 |
| ghostmansd | OK 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 https://libre-soc.org/openpower/sv/bitmanip/ | 21:42 |
| lkcl- | which contains the [new] XO values for fitting into the [extremely limited] EXT022 space | 21:42 |
| lkcl- | if you do choose to update svp64.py it's absolutely critical that you also update power_decoder.py to match it, and the CSV files as well | 21:43 |
| lkcl- | so for example you shifted XO along by one bit | 21:43 |
| lkcl- | https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=c968dab738cac48733dc958e7a88711af0247d73 | 21: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..30 | 21:44 |
| lkcl- | + insn |= 0b00001 << (31-31) # XO , bits 26..31 | 21:44 |
| lkcl- | BUT | 21:44 |
| lkcl- | now PowerDecoder2 does not match it | 21:45 |
| lkcl- | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/power_decoder.py;h=39ba5f22a46c35ed3824faacb9bad8c96d43f396;hb=HEAD#l737 | 21:45 |
| lkcl- | sorry PowerDecoder | 21:45 |
| lkcl- | 737 Subdecoder(pattern=22, opcodes=get_csv("minor_22.csv"), | 21:46 |
| lkcl- | 738 opint=True, bitsel=(1, 5), | 21:46 |
| lkcl- | these | 21:46 |
| * lkcl- screams | 21: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 order | 21:47 |
| * lkcl- cries | 21:47 | |
| lkcl- | but the point is, you adapted the XO field from 31-26 to 31-30 | 21:47 |
| lkcl- | to | 21:47 |
| lkcl- | 31-26 to 31-31 | 21:47 |
| lkcl- | but did not correspondingly change bitsel=(1,5) to bitsel=(0,5) | 21:47 |
| programmerjake | meeting in 10min | 21:48 |
| lkcl- | and also did not update major_22.csv to add the extra bit | 21:48 |
| lkcl- | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=openpower/isatables/minor_22.csv;hb=HEAD | 21:48 |
| lkcl- | so now, neither svshape nor svremap will work | 21:49 |
| lkcl- | because svp64.py will create a pattern that is *not* correctly decoded by PowerDecoder() | 21:49 |
| lkcl- | which is why i hadn't updated svp64.py even though it's not quite exactly according to the spec | 21:49 |
| lkcl- | because there are quite a few moving pieces that all need to be updated simultaneously | 21:50 |
| ghostmansd[m] | What a shame | 21: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... somewhere | 21: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 places | 21:52 |
| programmerjake | ghostmansd 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 svp64.py is a hack | 21:52 |
| ghostmansd[m] | programmerjake reads my mind :-D | 21:52 |
| lkcl- | status updates with the OPF. | 21:53 |
| lkcl- | it's a set agenda, very fast-paced, a lot to cover | 21: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 time | 21:54 |
| programmerjake | the agenda should cc a mailing list...lkcl can you do that from now on? | 21:54 |
| lkcl- | yes good idea | 21:54 |
| programmerjake | next status update is 2 weeks from now | 21:54 |
| programmerjake | there's also meetings where we talk about whatever every tuesday | 21:55 |
| ghostmansd[m] | It'd be way better if these were a hour or two earlier :-) | 21:57 |
| programmerjake | sorry it's soo late for you ghostmansd, trying to make it work for us, europe, and australia | 21:57 |
| ghostmansd[m] | Yeah I know :-) | 21:57 |
| ghostmansd[m] | I'll try visiting the Tuesday session | 21:59 |
| ghostmansd[m] | I guess the link is the same, eh? | 22:00 |
| programmerjake | yes | 22:02 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!