| lkcl | Veera[m], i updated symbiflow-install to include buster-backports and to install fpga-something from the github repo | 11:22 |
|---|---|---|
| lkcl | it's no longer in pypi | 11:22 |
| lkcl | which is really odd | 11:22 |
| lkcl | hoo-boy the build takes ages :) | 11:22 |
| lkcl | MaciejPijanowski, hi. you got my email to leads@3mdeb.com? going well - we should talk. NLnet asked us not to make announcements yet | 11:23 |
| lkcl | ghostmansd[m], ^ | 11:24 |
| Veera | Hi | 12:47 |
| Veera | lkcl: Are you available | 12:47 |
| cesar | lkcl: python ~/src/soc/src/soc/simple/test/test_issuer.py | 13:03 |
| cesar | File "/home/cstrauss/src/soc/src/soc/fu/alu/main_stage.py", line 16, in <module> | 13:03 |
| cesar | from ieee754.part.partsig import PartitionedSignal | 13:03 |
| cesar | ImportError: cannot import name 'PartitionedSignal' from 'ieee754.part.partsig' (/home/cstrauss/src/ieee754fpu/src/ieee754/part/partsig.py) | 13:04 |
| Las[m] | We need CI. | 13:13 |
| lkcl | Veera, i've a stack of changes i'm in the middle of | 13:25 |
| Veera | lkcl: I need review with symbiflow-install ( I have read the bugzilla mails) | 13:26 |
| lkcl | Veera, done | 13:26 |
| lkcl | https://git.libre-soc.org/?p=soc.git;a=commitdiff;h=dd84c610a68a556eb532cee133df68c4354dbf32 | 13:27 |
| lkcl | git pull soc | 13:27 |
| lkcl | Veera, i've run it, and there's still errors | 13:28 |
| lkcl | https://bugs.libre-soc.org/show_bug.cgi?id=654 | 13:28 |
| lkcl | i corrected buster-backports (added that) and fpga-interchange | 13:28 |
| Veera | python-fpga-interchange is git clone done at start of script | 13:29 |
| lkcl | yes but it's not then actually installed | 13:30 |
| lkcl | it's installed with "pip3" which fails | 13:30 |
| lkcl | see the commit diff | 13:30 |
| lkcl | https://git.libre-soc.org/?p=dev-env-setup.git;a=commitdiff;h=9acff23d8e121186233b1daafaba1645f910ae8e | 13:30 |
| lkcl | ^^^ | 13:30 |
| Veera | In talos machine they are passing | 13:33 |
| Veera | git commit 1959b40e998db987c604c0a75664ccb209df13f7 | 13:34 |
| lkcl | i need to re-run it | 13:35 |
| lkcl | ahh but the talos machine is based on debian-testing | 13:35 |
| lkcl | (it has to be) | 13:35 |
| lkcl | btw don't for goodness sake under any circumstances run "apt-get upgrade" on it | 13:35 |
| lkcl | create a chroot and use that | 13:35 |
| lkcl | inside a chroot you can do whatever | 13:36 |
| Veera | conda lock is on git commit 5004f1c19e9f0bd9f87447502770b65a367878c7 | 13:36 |
| lkcl | that doesn't make much sense to me | 13:37 |
| Veera | on talos machine I am using debootstrap for clean env | 13:37 |
| lkcl | i'm going to blow away the chroot's /home/lkcl/src directory and re-run it | 13:37 |
| lkcl | ok whew | 13:37 |
| lkcl | except the assumption of the script was that you manually add buster-backports | 13:38 |
| lkcl | which i hadn't done, i ran the standard mk-deb-chroot script | 13:38 |
| lkcl | and adding buster-backports is *not* part of that | 13:38 |
| lkcl | so i added it | 13:38 |
| lkcl | that gave the right version of cmake | 13:38 |
| Veera | conda lock: in symbiflow-arch-defs there is this file conda_lock.yml | 13:38 |
| Veera | conda lock: in this valid versions are there which are known to work | 13:39 |
| lkcl | i've set it running again, it'll take a few hours, i'll let you know what happens | 13:39 |
| Veera | lkcl: in the script apt-get upgrade -y is to be used or not | 13:43 |
| lkcl | Veera, answer is there already. https://bugs.libre-soc.org/show_bug.cgi?id=654#c18 | 13:53 |
| lkcl | and it's already taken care of | 13:53 |
| lkcl | i've already made the two modifications required that answer comment 18 and 19. | 13:53 |
| lkcl | no further action need be taken | 13:53 |
| lkcl | re-running the script, vpr is currently being built | 13:54 |
| lkcl | it's much quicker because ccache is being used | 13:54 |
| lkcl | so shouldn't take 3 hours this time | 13:54 |
| lkcl | Veera[m], script completed, exact same error | 15:21 |
| lkcl | OSError: File not found: /home/lkcl/src/symbiflow/symbiflow-arch-defs/env/conda/envs/symbiflow_arch_def_base/share/vtr/rr_graph_uxsdcxx.capnp | 15:21 |
| ghostmansd[m] | lkcl: sorry for the long absence, got a lot with regular work | 15:28 |
| ghostmansd[m] | I have no idea what you mean, I don't belong to 3mdeb-leads list :-) | 15:29 |
| ghostmansd[m] | Speaking of our roadmap, I recall we stopped at updating the wiki with CSV, and also writing a test which makes use of this CSV as well, right? | 15:30 |
| lkcl | ghostmansd[m], no problem | 15:31 |
| lkcl | yes. | 15:31 |
| lkcl | i've done some examples | 15:31 |
| ghostmansd[m] | Ok, will take a look today | 15:31 |
| lkcl | they look great, and i was able to confirm that the function you wrote is correct | 15:31 |
| lkcl | although i recommended removing one redundant call | 15:31 |
| lkcl | it's now a one-liner | 15:32 |
| ghostmansd[m] | In the end of November, I'll have a vacation, which means I can dedicate more time :-) | 15:32 |
| ghostmansd[m] | Ack | 15:32 |
| lkcl | funfunfun | 15:32 |
| lkcl | err aren't holidays supposed to be, y'know... holidays? | 15:32 |
| lkcl | i've a task for you which will make understanding ISACaller easier, for then: ISACaller needs splitting into individual functions. | 15:33 |
| lkcl | self.read_regs() | 15:33 |
| ghostmansd[m] | For me this project is kind of holiday, actually | 15:33 |
| lkcl | self.do_something_else() | 15:33 |
| lkcl | self.process_instruction() | 15:33 |
| lkcl | self.write_regs() | 15:33 |
| ghostmansd[m] | I mean, compared to what I do on everyday basis :-) | 15:33 |
| lkcl | :) | 15:33 |
| lkcl | i have visions of you abseiling down cliffs whilst simultaneously programming a... a... yeah | 15:34 |
| ghostmansd[m] | Does it mean that we will have kind of state machine, or instructions etc. will arrive as parameters? | 15:34 |
| lkcl | no, it's just a huge code-clean-up | 15:34 |
| ghostmansd[m] | That is, hopefully all the state is explicit, right? | 15:35 |
| ghostmansd[m] | And passed by caller? | 15:35 |
| lkcl | the entire main function in ISACaller is just one ridiculously-long blatch of lines | 15:35 |
| lkcl | yes? | 15:35 |
| lkcl | he said | 15:35 |
| ghostmansd[m] | Aha, yep, I think I know what you mean :-) | 15:35 |
| lkcl | there are, um, some things that the yield() progression actually has to do side-effects | 15:35 |
| lkcl | storing things *in* ISACaller as part of other yield() progressions | 15:36 |
| lkcl | it's a dog's dinner mess to be honest but there's not much other option once you get involved with yield | 15:36 |
| ghostmansd[m] | Lol | 15:36 |
| lkcl | you can't return anything *other* than what is being yield()ed | 15:36 |
| ghostmansd[m] | Well, otoh, I like yield | 15:36 |
| lkcl | which means you can't bloody well call functions to get actual, like, y'know... function call return results? | 15:37 |
| ghostmansd[m] | Because it still makes other stuff look simpler | 15:37 |
| lkcl | i do too, but when it becomes pervasive it's a bit of a handicap | 15:37 |
| lkcl | the best/worst example i saw of this was a full-on HTTP proxy server | 15:37 |
| lkcl | i wrote it 10 years ago and *only now* are python-istas / python-afficionados going "oh we should convert everything to asyncio" because that's all luverlyy-and-the-latest-treeeeen | 15:38 |
| lkcl | d | 15:38 |
| lkcl | https://git.libre-soc.org/?p=multitaskhttpd.git;a=blob;f=README;hb=HEAD | 15:39 |
| lkcl | anyway: cleaning up ISACaller would give you a working-knowledge / idea of its structure (and foibles) | 15:40 |
| lkcl | which would in turn give you the "handles" on which to try setting XLEN=32/16/8 | 15:40 |
| ghostmansd[m] | Ok | 15:42 |
| ghostmansd[m] | Do you have a task? | 15:43 |
| lkcl | yes the CSV reading | 15:48 |
| lkcl | unit tests | 15:48 |
| lkcl | sorry, thought that was understood | 15:48 |
| ghostmansd[m] | Nope, I mean regarding ISACaller update | 15:49 |
| ghostmansd[m] | :-) | 15:49 |
| lkcl | oh ok. | 15:49 |
| ghostmansd[m] | I mean, once I complete CSV | 15:49 |
| lkcl | ah right, no, bugreport not created yet | 15:49 |
| lkcl | feel free to make one, cross-ref irclog here | 15:49 |
| lkcl | the only thing is, you'll need to run a *lot* of openpower-isa unit tests each time | 15:49 |
| lkcl | i strongly recommend doing one code-cut at a time (create one function) | 15:50 |
| lkcl | starting at the *end* of the function named call() | 15:50 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/caller.py;h=36e3c732d55c7c705b40d4456a299af3807eb789;hb=8ffb51a901da471cb3fd80f0c1cd8f3bcc1a1028#l1138 | 15:51 |
| lkcl | you can see it's massive. 500 frickin lines. | 15:52 |
| lkcl | the first blindingly-obvious "cut" point should be here: | 15:52 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/caller.py;h=36e3c732d55c7c705b40d4456a299af3807eb789;hb=8ffb51a901da471cb3fd80f0c1cd8f3bcc1a1028#l1592 | 15:52 |
| lkcl | basically call() should become a blindingly-obvious set of well-named functions | 15:53 |
| lkcl | which pass around parameters. | 15:53 |
| lkcl | that _will_ however be hampered by not being able to use function call return-results | 15:54 |
| lkcl | and you will see self.srcstep and self.dststep are a byproduct of that limitation | 15:55 |
| lkcl | sorry | 15:55 |
| lkcl | self.new_srcstep and self.new_dststep | 15:55 |
| lkcl | deep breath: before each commit you'll need to run pretty much *every* one of these unit tests | 15:56 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=tree;f=src/openpower/decoder/isa;hb=HEAD | 15:56 |
| lkcl | because ISACaller is actually frickin complicated | 15:57 |
| cesar | lkcl: It seems to me that DMI single-step is not really implemented on TestIssuer (although start and stop core are). I guess there wasn't time to implement it for the test chip. | 16:01 |
| lkcl | cesar, yes it is. or, it had damn well better be | 16:02 |
| lkcl | it's a little odd, though | 16:03 |
| lkcl | you have to run DMI "stop", first | 16:03 |
| lkcl | then run a polling-procedure to check it's actually stopped | 16:03 |
| lkcl | then you can "step" | 16:03 |
| lkcl | i described it to Anton on the #microwatt channel | 16:03 |
| lkcl | 1 sec | 16:03 |
| lkcl | drat, it looks like it was before i enabled logging | 16:05 |
| lkcl | might be on OPF mattermost | 16:05 |
| cesar | I mean, the single-step function is implemented in DMI, but, as far as I can see, TestIssuer does nothing with it. | 16:08 |
| cesar | I'll take a deeper look. | 16:08 |
| cesar | There must be an unit-test for this somewhere. | 16:11 |
| ghostmansd[m] | lkcl: ack, will summarize this in task | 16:19 |
| Veera | lkcl: did it worked out | 17:39 |
| ghostmansd | lkcl: I have a question regarding the table | 18:53 |
| ghostmansd | Let's assume we have 0x0000000090000A93 as an input value for extsb instruction with XLEN=64 | 18:53 |
| ghostmansd | Why do we have 0x0000000000000093 there? I would have expected the sign active, thus propagated to 0xffffffffffffff93. | 18:54 |
| ghostmansd | Please correct me if I'm mistaken. | 18:54 |
| ghostmansd | So, long story short: we take the byte, get its sign (1 in this case, since we got 0x93), then populate the byte to the rest. | 18:56 |
| ghostmansd | Again, I can for sure be wrong. :-) But the rest of the table works like this. | 18:57 |
| ghostmansd | lkcl: I've updated the csv respectively, please let me know if you think my rationale is wrong. I've also committed the corresponding test which deals with these CSVs. Hopefully this test is able to incorporate more CSVs, and I implemented it in batch mode so it'll be fast if we desire to update it with more cases. | 19:50 |
| ghostmansd | The way I access CSVs (path construction) is a total bullshit. Please let me know if we have some standard way to do it. | 19:51 |
| ghostmansd | lkcl: https://bugs.libre-soc.org/show_bug.cgi?id=723 for tests | 20:10 |
| ghostmansd | will raise the task for ISACaller changes soon, likely the day after tomorrow | 20:11 |
| ghostmansd | I've also updated https://libre-soc.org/3mdeb/ghostmansd/ with task 723, please check whether this should be covered by some grant or not, I'm not sure | 20:23 |
| lkcl | ghostmansd, yes, i'll work it out | 21:07 |
| lkcl | +extsb, 0xFFFFFFFFFFFFFF93 , 0x00000093 , 0x0093 , 0x93 | 21:10 |
| lkcl | because it is extsb, the only thing to take into account is the 0x93 | 21:11 |
| lkcl | where bit 7 is 1 | 21:11 |
| lkcl | and is therefore propagated down the *entire* lot, all XLENs. | 21:11 |
| lkcl | so that should be | 21:11 |
| lkcl | 0xffffffffff93, 0xffffff93, 0xff93, 0x93 | 21:12 |
| cesar | lkcl: On branch libresoc-nmigen-fork of nmigen: | 21:35 |
| cesar | from nmigen import Module, Signal, Repl | 21:35 |
| cesar | m = Module() | 21:35 |
| cesar | s = Signal(8) | 21:36 |
| cesar | m.d.comb += s.eq(Repl(0,8)) | 21:36 |
| cesar | Traceback (most recent call last): | 21:36 |
| cesar | File "<stdin>", line 1, in <module> | 21:36 |
| cesar | File "/home/cstrauss/src/nmigen/nmigen/hdl/ast.py", line 921, in Repl | 21:36 |
| cesar | return value.__Repl__(count, src_loc_at=src_loc_at) | 21:36 |
| cesar | AttributeError: 'int' object has no attribute 'Repl' | 21:37 |
| cesar | Master branch of seems ok. | 21:38 |
| lkcl | cesar, i haven't merged into libresoc-nmigen-fork for some time. use libresoc-partsig instead | 21:39 |
| cesar | Problem solved, thanks. | 21:40 |
| lkcl | :) | 21:41 |
| lkcl | merging is a bit of a lairy one, i forget each time how to do it | 21:41 |
| ghostmansd[m] | lkcl: I already did it :-) | 21:41 |
| lkcl | and there's some merge-conflicts that need sorting, each time, now | 21:41 |
| lkcl | ghostmansd[m], :) | 21:41 |
| ghostmansd[m] | Looked somewhat persuasive | 21:42 |
| ghostmansd[m] | :-D | 21:42 |
| lkcl | wait, whuu? what did you do? :) | 21:42 |
| ghostmansd[m] | Fixed extsb | 21:42 |
| lkcl | oh cool. | 21:42 |
| ghostmansd[m] | In csv | 21:42 |
| lkcl | but you saw you missed a couple of values? | 21:43 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=951dd564494af57dde0c439604f529f6b007bb98 | 21:43 |
| lkcl | you did XLEN=64 extsb correctly | 21:43 |
| lkcl | but missed XLEN=32 and XLEN=16 extsb | 21:43 |
| ghostmansd[m] | For now I updated XLEN=64 | 21:43 |
| lkcl | ahh | 21:43 |
| ghostmansd[m] | Because that was the one I could test :-) | 21:43 |
| lkcl | git pull | 21:43 |
| lkcl | ok | 21:43 |
| lkcl | yehyeh | 21:43 |
| ghostmansd[m] | But yeah, please push others I haven't looked into | 21:44 |
| ghostmansd[m] | That one I saw since test failed | 21:44 |
| ghostmansd[m] | (and that one was even w/o extsb changes) | 21:44 |
| ghostmansd[m] | So I simply took a look at value and realized it was incorrect wrt how the algorithm expects it to be | 21:45 |
| ghostmansd[m] | The test is run atop of the current extsX routines | 21:46 |
| ghostmansd[m] | I haven't pushed EXTS routine yet | 21:46 |
| ghostmansd[m] | That'll be the next step | 21:46 |
| ghostmansd[m] | I also suspect once we enable other XLEN we'll face more errors :-) | 21:48 |
| ghostmansd[m] | But I think these can be solved in scope of this enabling | 21:48 |
| lkcl | yes. going down the stack carefully. it's quite a big job. the entire unit test-case suite needs duplicating *multiple* times... | 21:52 |
| * lkcl claps hands together in fake-joy | 21:52 | |
| ghostmansd[m] | I just recalled you mentioned another task quite similar to XLEN, where changes are rather mechanical, but I already forgot the details, do you recall what must be done? | 22:21 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!