| programmerjake | lkcl: i noticed that there's a unnecessary branch in nmigen that's at the same commit as master: | 01:01 |
|---|---|---|
| programmerjake | https://gitlab.com/nmigen/nmigen/-/compare/master...6-completion-of-ast-and-dsl-abstraction-is-needed | 01:01 |
| programmerjake | can you remove it? | 01:01 |
| programmerjake | wait, not same commit, previous commit. in any case, all its changes are incorporated into master already | 01:02 |
| programmerjake | don't confuse it with the ast-dsl-abstraction branch, which does have new stuff | 01:03 |
| lkcl | programmerjake, gitlab is being annoying, there | 04:24 |
| programmerjake | how so? | 04:26 |
| programmerjake | afaict you can safely delete that branch, gitlab doesn't need it for issues or MRs | 04:27 |
| lkcl | programmerjake, can you update budget-sync to track back the MoU-milestone on each task when the markdown is created? | 04:47 |
| lkcl | not the top-level milestone, the first-level child milestone | 04:47 |
| lkcl | turns out that NLnet's Accountant has been going to the bugtracker for *two years*, manually tracking down the MoU first-level milestones (!) | 04:48 |
| programmerjake | ?? it assumes those milestones are identical and iirc fixes them internally if not | 04:48 |
| lkcl | NLnet.2019.02.012 191 | 04:48 |
| lkcl | bug # 191 budget 50000 excltasks 0 s 50000 p 44025 | 04:48 |
| lkcl | bug # 22 | budget 6125 excltasks 0 s 6125 p 3500 | 04:48 |
| lkcl | bug # 412 | | budget 2000 excltasks 2000 s 2000 p 2000 | 04:48 |
| lkcl | so when the mdwn reports "412", then an extra line in the notes should be "MoU milestone: 22" | 04:49 |
| lkcl | ## Payment not yet submitted | 04:50 |
| programmerjake | oh, you mean the leaf task in the mou that is a parent of whatever the current bug is? | 04:50 |
| lkcl | * [Bug #418](https://bugs.libre-soc.org/show_bug.cgi?id=418): | 04:50 |
| programmerjake | yeah, can you make a bug for that? i'll work on it soon | 04:50 |
| lkcl | ---> MoU child task <--- [Bug #22](https://bugs.libre-soc.org/show_bug.cgi?id=22) | 04:51 |
| lkcl | SPR pipeline formal correctness proof needed | 04:51 |
| lkcl | * €350 out of total of €400 | 04:51 |
| lkcl | willdo | 04:51 |
| lkcl | it needs to be done preferably before putting in the RFPs. sigh | 04:51 |
| lkcl | 5am here. | 04:52 |
| programmerjake | if you're going to be awake in a few hours, i can have it be done by then, though we will need to add a field to bugzilla telling us if that bug is in the mou | 04:54 |
| programmerjake | and we'll need to set that field on all the right bugs | 04:54 |
| programmerjake | lkcl: sound good? i'll add the field now if so. | 04:55 |
| programmerjake | actually, i'll just add it now, we can always remove it if we want to do something else | 04:56 |
| programmerjake | lkcl: i added that new field to a few tasks, unfortunately I don't have easy access to the full set of MoUs, can you help set that flag where appropriate? | 05:14 |
| programmerjake | i'll do the cryptorouter one, the mou list is in the top comment | 05:14 |
| programmerjake | sorry, I had to create a new field cf_is_in_nlnet_mou2 to replace cf_is_in_nlnet_mou, since cf_is_in_nlnet_mou was set to multiple-selection box which doesn't let you easily de-select an item in chromium on desktop...worked fine on mobile... | 07:02 |
| programmerjake | the new field is a drop-down list | 07:02 |
| programmerjake | lkcl: I implemented the requested feature in budget-sync (bug #882), please fill in the cf_is_in_nlnet_mou2 field to match the MoUs, since I don't actually know which tasks are part of most of the MoUs. | 09:16 |
| programmerjake | I added all the tasks in the wishbone MoU, except for "traveling expenses" since that didn't have a bug id in the pdf. | 09:25 |
| programmerjake | I filled in cf_is_in_nlnet_mou2 for all the MoUs I could find in my email history...that's just wishbone and cryptorouter | 09:30 |
| programmerjake | since it's 1:30am, I'm going to be done for the day. | 09:30 |
| lkcl | programmerjake, no, a field is not necessary, it can be calculated | 10:32 |
| lkcl | all tasks are part of the MoU, it is always true | 10:34 |
| lkcl | i will work out how to remove it | 10:34 |
| programmerjake | wait, don't remove it...not all tasks are part of the MoU and we need some way to distinguish them | 10:35 |
| lkcl | they're identifiable by "is this a child of the top-level milestone, yes or no" | 10:38 |
| lkcl | that's it. | 10:38 |
| lkcl | there was no need to add a field for that. | 10:38 |
| programmerjake | ah, ok. | 10:39 |
| programmerjake | I was thinking that we might have added tasks that weren't in the MoU and set the top-level milestone as their parent... | 10:40 |
| lkcl | so there is 100% no circumstance under which a task is added that is... | 10:40 |
| lkcl | no, 100% guaranteed no chance of that | 10:40 |
| programmerjake | or some MoU has 2 layers of tasks somehow | 10:40 |
| lkcl | yes, some have 2 layers (3 in one case): all that's needed is a tree-walk to the parent | 10:40 |
| lkcl | if a task is not on the MoU then it's not part of the MoU and would not even have the drop-down for that Grant. | 10:41 |
| programmerjake | no, i mean the MoU includes tasks that make a 2-layer deep hierarchy...so the MoU would include the top-level task, it's sub tasks, and some sub-sub-tasks | 10:41 |
| programmerjake | in that case, if we did "is it a direct child of the top-level task" then it would miss all the sub-sub-tasks | 10:42 |
| lkcl | no, that cannot happen either because NLnet's agreed tasks are specifically and only the immediate child nodes of the MoU | 10:42 |
| programmerjake | ok | 10:43 |
| lkcl | our decision to create sub-sub-tasks *still* requires that NLnet submit - and this is the kicker - *hunt in the bugtracker for* - only those tasks that were in the MoU | 10:43 |
| lkcl | they've been doing this manually for 2 years and didn't tell me | 10:43 |
| lkcl | sigh | 10:44 |
| sadoon[m] | Hi guys | 10:44 |
| sadoon[m] | How's everyone | 10:44 |
| lkcl | sadoon[m], goood. just woke up | 10:44 |
| lkcl | programmerjake, i'll fix it. there's good stuff here, the reporting itself is in place | 10:45 |
| sadoon[m] | I've had quite a bit of free time recently after testing positive for covid lol | 10:45 |
| lkcl | again? doh | 10:45 |
| sadoon[m] | Nah, first time | 10:45 |
| programmerjake | so, budget-sync can be changed to how you want by changing Node.is_in_nlnet_mou to a property that checks if it's a root bug or it's parent is a root bug. | 10:45 |
| sadoon[m] | Last one was a fluke | 10:45 |
| programmerjake | hi sadoon | 10:45 |
| sadoon[m] | Is there a meeting tonight? | 10:46 |
| programmerjake | yes, iirc | 10:46 |
| sadoon[m] | Awesome | 10:46 |
| programmerjake | lkcl: when you change that, please set the broken tests to `@unittest.skip`, i'll fix them later | 10:47 |
| lkcl | willdo | 10:48 |
| programmerjake | is_in_nlnet_mou needs to be a `@cached_property` rather than set in `__init__` since you need to check `self.milestone.canonical_bug_id == self.bug.id or (self.parent is not None and self.parent.bug.id == self.milestone.canonical_bug_id)` | 10:49 |
| programmerjake | and since `self.milestone` can fail | 10:49 |
| lkcl | good hint | 10:49 |
| programmerjake | check that self.milestone is not None -- it can also raise an error if the milestone isn't known | 10:50 |
| programmerjake | k, gn all | 10:51 |
| programmerjake | wait, set the broken tests to unittest.expectedFailure rather than skip...that way they show up differently in the test results | 10:54 |
| lkcl | ghostmansd[m], sorry about the obscure message. NLnet is just beginning to set up the new HTTPS-only system and beginning to send me the URLs to access the RFPs | 13:38 |
| lkcl | i have two of those URLs so far. i do not have the other 6. | 13:38 |
| lkcl | when they give me those URLs, i will be able to tell you what RFPs have been submitted, what have been approved, and which have been paid | 13:38 |
| lkcl | under the specific NLnet Grant, just like i sent you the status information of the one that they *have* sent me | 13:39 |
| lkcl | i cannot obviously email you the status information where they haven't provided me the URL to find out the status information! | 13:39 |
| lkcl | all of which i was trying to convey in "i hope you can guess most of the above" way, with a very brief message, apologies | 13:40 |
| ghostmansd[m] | lkcl, OK, it became clearer :-) | 13:44 |
| lkcl | :) | 13:45 |
| ghostmansd[m] | I hope that I'll finish macros support soon | 13:45 |
| ghostmansd[m] | In fact, since yesterday we're at stage where we actually remap instructions not as strings, but really as bits | 13:45 |
| ghostmansd[m] | That is, since we now deal on operand parsing stage, we indeed remap say register 42 to register 5 and store sv_extra | 13:46 |
| ghostmansd[m] | (just an example, not real formula) | 13:46 |
| lkcl | ooOooo | 13:46 |
| ghostmansd[m] | I guess this, in fact, will also imply prefix support for gas | 13:46 |
| ghostmansd[m] | Not yet for objdump, unfortunately :-) | 13:47 |
| lkcl | aaaw | 13:47 |
| ghostmansd[m] | But for gas we will already end up with 8 bytes of insn | 13:47 |
| lkcl | what do you mean, we can't have everything all at once?? | 13:47 |
| lkcl | we're taking over the world, damnit! muhahah | 13:47 |
| ghostmansd[m] | For objdump, some magic must be done, so that it understands from prefix that stuff has sv. etc. | 13:48 |
| ghostmansd[m] | Yeah I wish that too :-) | 13:48 |
| lkcl | has v3.1 64-bit prefixes been added yet? | 13:48 |
| lkcl | (by IBM, i mean) | 13:48 |
| ghostmansd[m] | There are some prefixed instructions there, not sure where they came from | 13:48 |
| ghostmansd[m] | I mean, binutils certainly have some basis to work with | 13:49 |
| ghostmansd[m] | But I have to discover yet how far it's completed on disassembly side | 13:49 |
| ghostmansd[m] | For assembly, things are simpler: it's either 4 bytes or 8 bytes | 13:49 |
| ghostmansd[m] | And this is it | 13:49 |
| lkcl | astounding. | 14:23 |
| lkcl | we've a bug in TestIssuer for almost 2 years | 14:23 |
| lkcl | the multiply pipeline was outputting only a 64-bit value where it should have been 128 | 14:24 |
| lkcl | consequently mulhd was 100% guaranteed to produce the value "0" | 14:26 |
| octavius | "only a 64-bit value where it should have been 128" :O | 14:28 |
| * lkcl major face-palm | 14:28 | |
| octavius | But it *was* found, better late than never :) | 14:29 |
| lkcl | well the ls180 test asic will have that in it. oh well | 14:29 |
| octavius | It's not a bug, it's a feature | 14:30 |
| * lkcl snorts | 14:30 | |
| lkcl | oh octavius i had a bit of a think, are you happy to rename the ls2 pinmux to ngi_router? | 14:30 |
| lkcl | you said you had some renaming to do in it anyway | 14:31 |
| octavius | Yeah can do | 14:31 |
| lkcl | frickin ell there's a frickin lot of unit tests | 14:34 |
| lkcl | Veera[m], i moved cvc5 and bitwuzla to a separate bugreport and upped the budget a bit for you | 14:35 |
| lkcl | https://bugs.libre-soc.org/show_bug.cgi?id=883 | 14:35 |
| lkcl | ahh found the error | 14:37 |
| lkcl | it was me, screwing up, back in february | 14:38 |
| lkcl | the ASIC will be fine | 14:38 |
| lkcl | lxo, ping, there's EUR available for you! i emailed you a summary | 14:57 |
| octavius | I moved over ls2 to ngi_router | 15:31 |
| octavius | Do you want to try and add other periphs on different banks? | 15:36 |
| * octavius will go for lunch, will come back later | 15:36 | |
| lkcl | honestly? it's fine | 16:00 |
| lkcl | actually.... y'know what... | 16:00 |
| lkcl | oh no it's ok | 16:00 |
| lkcl | just trying to think how to move these | 16:01 |
| lkcl | 4N VSSE_6 | 16:01 |
| lkcl | 5N VDDE_6 | 16:01 |
| lkcl | 6N VDDI_6 | 16:01 |
| lkcl | 7N VSSI_6 | 16:01 |
| lkcl | 2 pins further inwards | 16:01 |
| lkcl | ah! | 16:02 |
| lkcl | i know | 16:02 |
| lkcl | at least for RG1 | 16:02 |
| lkcl | 32E GPIOE_E0E RG1_ERXD0 | 16:02 |
| lkcl | 33E GPIOE_E1E RG1_ERXD1 | 16:02 |
| lkcl | 34E GPIOE_E2E RG1_ERXD2 | 16:02 |
| lkcl | 35E GPIOE_E3E RG1_ERXD3 | 16:02 |
| lkcl | move these 4 into the places 32-35 | 16:03 |
| lkcl | 58E GPIOE_E16E RG1_ETXCK | 16:03 |
| lkcl | 59E GPIOE_E17E RG1_ECRS | 16:03 |
| lkcl | 60E GPIOE_E18E RG1_ECOLE EINT_0 | 16:03 |
| lkcl | 61E GPIOE_E19E RG1_ETXERR | 16:03 |
| lkcl | no hang on | 16:04 |
| lkcl | i'll do it | 16:04 |
| lkcl | ok sorted. | 16:15 |
| octavius | Ah, you added extra pins for the rgmii lkcl? | 16:57 |
| ghostmansd | OK it seems the new revision which tweaks binutils internal operand parsing works! | 17:44 |
| ghostmansd | https://pastebin.com/6JvmbRHK | 17:44 |
| ghostmansd | These are the same commands I see in pysvp64asm, except that the former does not understand the brand new syntax like "*%", etc. | 17:44 |
| ghostmansd | I've just created task to synchronize pysvp64asm and binutils naming convention: https://bugs.libre-soc.org/show_bug.cgi?id=884. We'll have to keep these in sync, since we'd like to compare their output eventually once the tests are ready. | 17:49 |
| ghostmansd | It'd be great if we could allocate some budget to this task, but I'm not sure whether we have it. | 17:50 |
| lkcl | octavius, extra pins, no - just moved them around | 17:58 |
| lkcl | octavius, wark-wark https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=b4292d8c2a8036f5ca8f4469d7aa858b5508b733 | 17:58 |
| lkcl | you can find that sort of thing with "make clean" followed by "make pdf" | 17:58 |
| octavius | Ah, that's what it was | 17:59 |
| lkcl | ghostmansd[m], wha-hey! | 17:59 |
| octavius | thanks | 17:59 |
| lkcl | ghostmansd[m], let me find somewhere. binutils i already threw the EUR 12k at you :) | 17:59 |
| ghostmansd[m] | Yeah I know. At least I could share those. ;-) | 18:04 |
| lkcl | and this one https://bugs.libre-soc.org/show_bug.cgi?id=838 | 18:05 |
| lkcl | if that wasn't already allocated i could chuck that at you... | 18:05 |
| * lkcl still looking | 18:05 | |
| ghostmansd[m] | Yeah that one is inherited from binutils too :-) | 18:05 |
| lkcl | found one | 18:06 |
| lkcl | https://bugs.libre-soc.org/show_bug.cgi?id=232 | 18:06 |
| ghostmansd[m] | I'm really kinda lost where are all those 12K... I got I think only 1K so far. :-) | 18:07 |
| lkcl | this is actually going to be quite a bit task | 18:07 |
| lkcl | well, NLnet will send me the secret URLs to access the RFP overviews, i'll be able to tell you, then | 18:07 |
| lkcl | ghostmansd[m], i think we'll have to support both naming schemes in pysvp64asm for a while | 18:08 |
| ghostmansd[m] | Yes, sure. Mine impression too. | 18:08 |
| ghostmansd[m] | But at least not for binutils. | 18:08 |
| ghostmansd[m] | There it'd be damn good tricky I'd say. | 18:09 |
| ghostmansd[m] | Well, that's been already discussed, though. | 18:09 |
| ghostmansd[m] | Let me know if I should convert some code too, though. | 18:09 |
| ghostmansd[m] | For example, this good ol' mp3 code I broke... :-) | 18:10 |
| lkcl | mhm :) | 18:10 |
| lkcl | urrrr and documentation | 18:13 |
| lkcl | ghostmansd[m], can you find the IRC and mailing list links, do "edit" on comment 0 https://bugs.libre-soc.org/show_bug.cgi?id=884#c0 | 18:15 |
| lkcl | ghostmansd[m], https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=7bcec293f2761bed16e9f1fddf4469c7398cb32b | 18:23 |
| ghostmansd[m] | I put the link into "link" field of the task | 18:23 |
| lkcl | that *should* be sufficient, just checking it doesn't break anything | 18:23 |
| ghostmansd[m] | But let me also add it to the first comment | 18:23 |
| lkcl | yes please | 18:24 |
| ghostmansd[m] | Actually there are more in binutils, they also provide these r, f, cr and similar notations. | 18:25 |
| ghostmansd[m] | Should we consider these too? | 18:25 |
| lkcl | yes i know - no, keep it simple | 18:25 |
| lkcl | otherwise it's necessary to have a decode_gpr_reg() | 18:25 |
| lkcl | decode_fp_reg() | 18:25 |
| lkcl | decode_cr_reg() | 18:25 |
| ghostmansd[m] | Ok fair enough yeah | 18:25 |
| lkcl | and that's getting to be a handful | 18:25 |
| lkcl | pysvp64asm is intended as "bare-bones and reasonably bloody obvious" :) | 18:26 |
| lkcl | for a given definition of "obvious"... | 18:26 |
| lkcl | ok i didn't break anything with python3 decoder/isa/test_caller_setvl.py >& /tmp/f | 18:26 |
| ghostmansd[m] | :-D | 18:27 |
| lkcl | octavius, "boring" as it is going to be, do you want to help going through unit tests searching for "N.v" and replacing them with "*N"? | 18:29 |
| lkcl | i say boring, but actually it'll mean you get to run some of the unit tests which is always a good thing, and see what's in them | 18:29 |
| lkcl | ghostmansd[m], feel free to help with that not-entirely-mind-numbing task too | 18:29 |
| lkcl | it's kinda useful as a "what the hell has actually been done" kindof way | 18:30 |
| ghostmansd[m] | Yes, sure | 18:32 |
| lkcl | i'm doing test_caller_setvl.py | 18:33 |
| ghostmansd[m] | You'll start first, though: I'm still have some deeds to complete in scope of macros support. | 18:33 |
| lkcl | ack | 18:33 |
| lkcl | i screwed it up already, decode_reg returned int(field), "vector" | 18:34 |
| lkcl | not "vector", int(field) | 18:34 |
| lkcl | or... | 18:34 |
| octavius | So which ones should I do? | 18:39 |
| lkcl | pick one :) | 18:41 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=tree;f=src/openpower/decoder/isa;hb=HEAD | 18:41 |
| lkcl | test_caller_svp64_anything.py | 18:42 |
| octavius | I'll do dct | 18:42 |
| lkcl | ack go for it | 18:42 |
| lkcl | i'm gonna doo.... test_caller_svp64_mapreduce.py | 18:42 |
| lkcl | make sure it works first though! | 18:43 |
| lkcl | dct's a fun one. i'm astonished by what transpired | 18:45 |
| octavius | Discrete Cosine Transform? | 18:46 |
| lkcl | it's literally the world's only in-place Vector DCT algorithm | 18:46 |
| lkcl | yes | 18:46 |
| octavius | Got an "OK" at the end, so I guess it works. Now can start changing | 18:47 |
| lkcl | yyep! | 18:49 |
| lkcl | what the hell?? | 18:49 |
| lkcl | why am i only just hearing about this? https://github.com/hst10/pylog | 18:49 |
| lkcl | https://ieeexplore.ieee.org/document/9591456 | 18:49 |
| lkcl | octavius, when committing make sure to put the bugreport in the commit message | 18:51 |
| octavius | Which bugreport? | 18:52 |
| lkcl | then put the commit diff link into the bugreport | 18:52 |
| lkcl | https://bugs.libre-soc.org/show_bug.cgi?id=884#c0 | 18:52 |
| octavius | ok | 18:52 |
| lkcl | done, i'm using vim ":%s/N.v/*N" laboriously one register number N at a time | 18:54 |
| lkcl | it's not quick but not slow either | 18:54 |
| lkcl | test_caller_setvl_fp.py.... | 18:56 |
| lkcl | done | 18:57 |
| octavius | Ah, that's how you do it | 18:57 |
| octavius | Could be done with regex :D, but I'm just going to copy you | 18:58 |
| lkcl | lol | 18:58 |
| lkcl | i hate regex's | 18:58 |
| octavius | I'm starting to love them | 18:58 |
| lkcl | and you have to watch out for matching against "svstate.vl = 5" | 18:58 |
| octavius | Because I set up a Pi-Hole DNS XD | 18:58 |
| octavius | Ah yeah | 18:59 |
| lkcl | and you have to watch out for matching against "svstate>>>.v<<<<l = 5" | 18:59 |
| lkcl | ha, just doing matrix i ended up with 3*2 | 18:59 |
| lkcl | and 1*6 | 18:59 |
| lkcl | starting again on that one, doh | 19:00 |
| lkcl | matrix done | 19:01 |
| lkcl | ok i'm bored of this now :) | 19:02 |
| octavius | Also have be careful with 8.v matching 48.v | 19:02 |
| * lkcl need to go for a walk | 19:02 | |
| lkcl | yeah | 19:02 |
| lkcl | it's why best not to do automated | 19:02 |
| octavius | No, this happens in vim too | 19:02 |
| octavius | doing " 0.v" works (with the space) | 19:03 |
| lkcl | that doesn't catch things with "sv.addi 0.v,1.v,2.v" | 19:06 |
| octavius | True, which is why everyone should add a space :D | 19:06 |
| octavius | Done dct, I'll get on with bc | 19:54 |
| octavius | done bc, going on to fft | 20:23 |
| lkcl | oleee! tim pearson got libresoc.v working as a drop-in replacement for microwatt.v in kestrel. | 20:28 |
| octavius | Nice | 20:28 |
| octavius | Actually, that's *really* nice | 20:29 |
| lkcl | erm... yes :) | 20:33 |
| lkcl | it also means that if retrying the linux simulations, those now stand a good chance of succeeding as well | 20:34 |
| lkcl | and also booting linux-5.7 on FPGAs | 20:34 |
| octavius | done fft, doing fp | 22:07 |
| octavius | oops, fp already done | 22:11 |
| octavius | ldst it is | 22:12 |
| octavius | done, doing predication | 22:54 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!