| madan_kartheessa | hi | 09:02 |
|---|---|---|
| MANIKANDAN | hello | 09:02 |
| MANIKANDAN | hi | 10:56 |
| Las[m] | Downgrading to 3.7 didn't fix it, fixing the code to match the comment did fix it. | 11:34 |
| Las[m] | i.e. 12 -> 15 | 11:34 |
| Las[m] | Funniest thing is that it's been wrong from the start in commit a8080116d7b787aaedf0f71558a95682ab96a71c | 11:35 |
| Las[m] | How did you ever get this to work? | 11:35 |
| Las[m] | programmerjake: Have you ever built for the versa ecp5? | 11:36 |
| Las[m] | Now I get "libresoc-versa-ecp5> ERROR: Conflicting init values for signal 1'0 (\test_issuer.ti.core_core_cr_out [3] = 1'0 != 1'x)." | 11:37 |
| lkcl | Las[m], i have no idea! | 11:37 |
| lkcl | that's an uninitialised value | 11:38 |
| lkcl | like i said: litex is horribly fragile due to using migen | 11:38 |
| lkcl | MANIKANDAN, hi, what's your email address, i will add you to bugzilla. | 11:39 |
| lkcl | also, if you are happy with our Charter, https://libre-soc.org/charter, then i can give you ssh write access and you can commit directly to the wiki back-end | 11:41 |
| lkcl | you should however still be able to use the wiki | 11:47 |
| Veera[m] | Hi | 11:51 |
| Veera[m] | lkcl: bug: 251, what is the status? | 12:03 |
| lkcl | Veera[m], hi. 1 sec | 12:06 |
| lkcl | we haven't heard from vivek in a while | 12:07 |
| lkcl | Veera[m], i re-enabled authorized_keys on the TALOS-II workstation | 12:08 |
| Veera[m] | lkcl: I deleted the prv and pub key a month ago after it was not working! | 12:09 |
| Veera[m] | lkcl: Have you received update on Bug: 654 | 12:10 |
| lkcl | Veera[m], then that stops you entirely from accessing the git.libre-soc.org repositories | 12:13 |
| lkcl | yes, i saw it just now | 12:13 |
| lkcl | don't destroy public/private keys without a really good reason, it is completely unnecessary to do that | 12:15 |
| lkcl | and makes more work for me | 12:15 |
| lkcl | now i have to | 12:15 |
| lkcl | 1) revoke your existing public key in the gitolite3 config | 12:15 |
| lkcl | 2) revoke your existing public key on the TALOS-II server | 12:15 |
| lkcl | 3) request that you send me a new one | 12:15 |
| lkcl | 4) add the new one to the gitolite3 config | 12:16 |
| lkcl | 5) scp the new one to the TALOS-II server | 12:16 |
| Veera[m] | lkcl: wait a minute | 12:17 |
| lkcl | Veera[m], i have now revoked your access to gitolite3. | 12:17 |
| lkcl | Veera[m], i have now revoked your access on TALOS-II | 12:17 |
| Veera[m] | lkcl: my libre-soc.org ssh keys are intact | 12:17 |
| lkcl | Veera[m], please send me a new ssh public key | 12:18 |
| lkcl | you said, Veera[m]> lkcl: I deleted the prv and pub key a month ago after it was not working! | 12:18 |
| Veera[m] | i deleted them for TALOS-II | 12:18 |
| lkcl | there is only one, so i have revoked them | 12:18 |
| Veera[m] | In fact in this afternoon I uploded to git libreriscv | 12:18 |
| lkcl | only one ssh key was authorized, and that was the one net-lr@lily | 12:19 |
| lkcl | 9pwN1OCVl01s8aZ2JF net-lr@lily | 12:19 |
| Veera[m] | Sorry. I had a separate one for TALOS in my directory. | 12:19 |
| Veera[m] | I did not remembered much for TALOS | 12:19 |
| lkcl | that key is a local key that has absolutely nothing to do with the key which is authorized to access the server | 12:20 |
| lkcl | only one was added and it has now been removed | 12:20 |
| lkcl | i will now have to take action to revert that | 12:20 |
| lkcl | that action has now been taken. | 12:21 |
| lkcl | i have now restored the gitolite3 access | 12:21 |
| lkcl | i have now copied over the public key to /home/vklr/.ssh/authorized_keys | 12:21 |
| Veera[m] | Is not separate keys are to be generated for two different machines | 12:22 |
| Veera[m] | git pull is working for gitolite3 access | 12:23 |
| lkcl | it's not necessary - you can if you like | 12:23 |
| lkcl | good, whew | 12:23 |
| lkcl | now that you have access with the "....9pwN1OCVl01s8aZ2JF net-lr@lily" one you can add as many other keys as you desire | 12:24 |
| lkcl | it's entirely up to you | 12:24 |
| lkcl | https://libre-soc.org/HDL_workflow/symbiflow/ | 12:24 |
| lkcl | wowww that's one hell of a lot of work | 12:24 |
| lkcl | i think we'll up the budget on that one. | 12:24 |
| Veera[m] | I can access the talos workstation | 12:26 |
| Veera[m] | just for check 922 23.155.224.75 | 12:26 |
| lkcl | excellent | 12:26 |
| lkcl | you saw also, i sent you a useful trick to add to ~/.bashrc (locally) | 12:27 |
| lkcl | use a command "mosh" which will give you a persistent shell | 12:27 |
| lkcl | so if you ever get disconnected you can carry on | 12:27 |
| MANIKANDAN | MANIKANDAN: lkcl I apologies for the delayed response My mail id is manikandan_phd@outlook.com, please add me to bugzilla and ikiwiki also. Thank you | 12:28 |
| Veera[m] | lkcl: what trick | 12:28 |
| Veera[m] | I have to see what mosh is? | 12:29 |
| Veera[m] | Can I use screen command | 12:29 |
| lkcl | it's a remote shell that works extremely well in combination with screen | 12:29 |
| lkcl | yes i installed screen on the server | 12:30 |
| lkcl | MANIKANDAN, got it, not a problem, this is IRC, delays are inevitable :) | 12:30 |
| lkcl | MANIKANDAN, added you on bugzilla | 12:31 |
| MANIKANDAN | lkcl, Thank you I will check:] | 12:32 |
| lkcl | MANIKANDAN, you should have just received an email from bugzilla@libre-soc.org | 12:32 |
| MANIKANDAN | lkcl, Yeah got it just now | 12:33 |
| lkcl | for the wiki, to edit the front-end (via the website) you don't actually need a username/password. or, you *should* just be able to create one, yourself. | 12:33 |
| lkcl | excellent | 12:33 |
| Veera[m] | I am reading on mosh. Well it may better than screen + ssh | 12:33 |
| lkcl | however it may be easier to get access via git.libre-soc.org | 12:33 |
| lkcl | Veera[m], indeed. actually it uses ssh underneath | 12:34 |
| Veera[m] | lkcl: Can I do debootstrap in TALOS and chroot | 12:34 |
| lkcl | Veera[m], in theeeory... yes :) | 12:34 |
| lkcl | yes, i remember now, i ran it a couple months back | 12:34 |
| Veera[m] | ok | 12:34 |
| lkcl | MANIKANDAN, here https://git.libre-soc.org/?p=libreriscv.git;a=summary | 12:34 |
| lkcl | if you'd like write access to that i need to first know if you're ok with our Charter, https://libre-soc.org/charter | 12:35 |
| lkcl | then i can give you write access when you send me an ssh public key | 12:35 |
| MANIKANDAN | lkcl, I can able to login bugzilla now. FYI the link shared in the mail https://bugs.libre-soc.org/: seems broken | 12:36 |
| MANIKANDAN | lkcl, Yeah i agree with the Charter, May I know how to share ssh public key | 12:40 |
| MANIKANDAN | lkcl, Sorry the problem is with the ":" adjoined with the link. Without that bugzilla link working fine | 12:44 |
| Las[m] | Using an older version of Migen I still get "ERROR: Conflicting init values for signal 1'0 (\test_issuer.ti.core_core_cr_out [3] = 1'0 != 1'x)."... | 12:55 |
| Las[m] | It would be a great help if I could get pointers for how to debug this | 13:00 |
| Las[m] | e.g. what is `ti.core_core_cr_out`? | 13:00 |
| lkcl | Las[m], here's the thing: you're literally the first other person - ever - to actually try to reproduce the build of ls180. | 13:09 |
| lkcl | i had to do this entirely myself, with zero assistance from anyone else, under extreme time pressure | 13:09 |
| Las[m] | oh lol | 13:12 |
| lkcl | yyeah. sigh | 13:12 |
| Las[m] | makes sense it's a PITA then | 13:12 |
| Las[m] | Glad I get to work on this though, Libre-SOC being libre isn't of much use if you can't patch the source code and build it yourself. | 13:12 |
| lkcl | many of the things that would normally be resolved by having a 2nd person, through the inter-communication, are just not there | 13:12 |
| lkcl | it's sounding like a nmigen / yosys issue. | 13:13 |
| Las[m] | The hope is that, through Nix, building your own version of LiteX, for an FPGA or whatever, should be exactly one command that Just Works | 13:13 |
| Las[m] | Yeah maybe my nmigen and yosys are too new | 13:13 |
| lkcl | can you try nmigen commit d824795c2c7cb43dcbc8ed8fac6d309d7 | 13:14 |
| lkcl | Date: Mon Apr 12 10:48:20 2021 +0100 | 13:14 |
| Las[m] | what about nmigen-soc? | 13:14 |
| lkcl | nmigen-soc is from git.libre-soc.org and that hasn't been updated | 13:14 |
| Las[m] | Already using that commit | 13:15 |
| lkcl | Veera[m], i increased you to EUR 500 for symbiflow | 13:15 |
| lkcl | ok let's check another one | 13:15 |
| Veera[m] | lkcl: Are you trying symbiflow build? | 13:15 |
| Veera[m] | Yeah I just read mail | 13:15 |
| lkcl | Veera[m]: i have a version i managed to bash together (it's where the notes came from) | 13:16 |
| Veera[m] | thanks | 13:16 |
| lkcl | if you can create a script (i will move symbiflow_install to a .txt extension) i will try it out | 13:16 |
| Veera[m] | oh | 13:16 |
| lkcl | Las[m], yosys commit a58571d0fe8971cb7d3a619a31b2c21be6d75bac | 13:16 |
| lkcl | i am so under time pressure i can't do manual commands again | 13:17 |
| Las[m] | Thanks, I'll try that | 13:17 |
| Veera[m] | lkcl: I will create a dev-env-setup script soon. In first attempt it was little haphazard. | 13:18 |
| Veera[m] | I thought installing will be easily, but it turned out not | 13:18 |
| lkcl | yyeah. | 13:19 |
| lkcl | if it's a lot of work i'll increase the budget some more | 13:19 |
| Veera[m] | I have to start a issue with symbiflow devs. As conda packages do not give build details | 13:20 |
| lkcl | yes, i know. it's pretty.... yeah. | 13:20 |
| lkcl | it took me 2 days to work out | 13:20 |
| lkcl | Las[m]: can you upload the issuer_verilog.v somewhere? | 13:21 |
| Veera[m] | So I have to get git clone origin and particular commit they used. | 13:21 |
| lkcl | to make sure it's stable, yes, that sounds about right | 13:21 |
| Veera[m] | as I posted in bugzilla, latest commits of symbiflow-arch-defs does not works | 13:22 |
| lkcl | kylel, ha, that looks blindingly obvious, doesn't it. nicely done | 13:23 |
| lkcl | yyeah we really need stable (reproducible) builds | 13:23 |
| lkcl | so a fixed commit is not only fine, it's actually kinda necessary | 13:24 |
| Veera[m] | lkcl: in conda litex-hub they are using vtr-optimized which is multi-threaded. But upstream vtr does not supports multithreaded. | 13:24 |
| lkcl | daaaang | 13:26 |
| lkcl | i actually used vtr (upstream) and it worked fine | 13:26 |
| Veera[m] | vtr upstream works fine. But it takes lot of time. | 13:30 |
| lkcl | intriguing. | 13:30 |
| Veera[m] | It uses only single cpu thread(vpr) | 13:30 |
| lkcl | yeah to be honest, personally i'm fine with that! | 13:30 |
| lkcl | otherwise my laptop also overheats | 13:30 |
| lkcl | :) | 13:31 |
| Veera[m] | googled but could not find anything related to vtr-optimized except in conda litex-hub pkgs | 13:31 |
| Veera[m] | ohh | 13:31 |
| Las[m] | lkcl: I'm just using https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/simple/issuer_verilog.py;h=8c0f8e1f5b8cc6a1a3d3e4f5947350e880c428e5;hb=75bdc1747f32a4fb6cf848ed8b5c68ef2f683f4c | 13:33 |
| Las[m] | I haven't changed the file | 13:33 |
| lkcl | i mean, its output | 13:33 |
| lkcl | 1 sec | 13:33 |
| Las[m] | Will upload now | 13:33 |
| lkcl | https://ftp.libre-soc.org/lars_build/ | 13:34 |
| kylel | lkcl, baby steps and yeah fairly straight forward. | 13:34 |
| lkcl | kylel, https://git.libre-soc.org/?p=soc.git;a=commitdiff;h=5bc2cf02f0df7639fbc6b2869b1d9cba71b9c8d2 | 13:36 |
| lkcl | if you can think of a better way to deal with those arguments instructions, gen, insncode, i'm all ears | 13:38 |
| lkcl | ghostmansd, sorry about yesterday, i was right in the middle of something complex (which i'd broken), and i have memory-recall issues. hence the rather extensive reliance on the bugtracker | 13:41 |
| kylel | lkcl, store in a class? | 13:42 |
| lkcl | kylel, this works great! $ python3 simple/test/test_issuer.py nosvp64 shiftrot2 >& /tmp/f1 | 13:42 |
| lkcl | that runs those ExpectedState tests you did :) | 13:42 |
| lkcl | kylel, what, my memory? | 13:42 |
| lkcl | kylel, just moved run_sim_state into SimRunner | 13:44 |
| lkcl | https://git.libre-soc.org/?p=soc.git;a=commitdiff;h=a567e84eb9e5ed130614c4e953b42744607c4cd0 | 13:44 |
| lkcl | if you do HDLRunner i'll do SimRunner | 13:44 |
| kylel | ok | 13:44 |
| Veera[m] | lkcl: I need to upload patch file or any other file needed in dev-env-setup scripts for symbiflow where should it be? | 13:46 |
| ghostmansd | lkcl: that's OK, I gonna sort it out today | 13:46 |
| lkcl | ghostmansd, :) | 13:46 |
| Veera[m] | lkcl: I know you describing ftp server hosted in libre-soc.org | 13:46 |
| lkcl | Veera[m], hmmm, good question | 13:46 |
| Veera[m] | lkcl: is there any other way? | 13:46 |
| lkcl | one option is to embed the text into the script | 13:46 |
| lkcl | and extract it to /tmp for example | 13:47 |
| lkcl | but that's really awkward | 13:47 |
| lkcl | the other is to make a subdirectory of dev-env-setup | 13:47 |
| Veera[m] | big patches embedded in script may look bad | 13:47 |
| lkcl | oh they're that big, ehn? dang | 13:47 |
| lkcl | ok then make a subdirectory, symbiflow | 13:47 |
| lkcl | in dev-env-setup | 13:47 |
| lkcl | and put them in that | 13:48 |
| Veera[m] | okay. | 13:48 |
| lkcl | there's a #symbiflow channel here on libera btw | 13:48 |
| Veera[m] | oh | 13:49 |
| Veera[m] | are they responsive? | 13:49 |
| lkcl | i have no idea | 13:49 |
| Veera[m] | ok | 13:49 |
| Veera[m] | no problem | 13:49 |
| lkcl | every community's different | 13:50 |
| Veera[m] | yeah I know. Just wanted to know you interacted beforehand | 13:51 |
| lkcl | a brief statement that we were going to attempt to create some alternative repro scripts that don't use conda | 13:52 |
| lkcl | and that we'd document it | 13:53 |
| lkcl | which you've done :) | 13:53 |
| lkcl | which is great | 13:53 |
| lkcl | oh we have an icarus verilog install script already, right? | 13:53 |
| lkcl | https://git.libre-soc.org/?p=dev-env-setup.git;a=blob;f=iverilog-install;hb=HEAD | 13:54 |
| lkcl | yes | 13:54 |
| Veera[m] | yes we have iverilog script already. | 13:55 |
| lkcl | ok whew | 13:55 |
| Veera[m] | is there other way to reference it in a new script? | 13:56 |
| lkcl | we've never done that before | 13:57 |
| Veera[m] | the build instructions for iverilog are small only | 13:57 |
| lkcl | i'm not sure if it's a good idea to do so or not | 13:57 |
| lkcl | yehyeh | 13:57 |
| lkcl | ok duplicate them, but put a comment (in both) and, oh i know | 13:58 |
| Veera[m] | we can install yosys and vtr in separate directories. I have to try that out. | 13:58 |
| lkcl | ah yeah good idea | 13:58 |
| lkcl | you have to add to the $PATH for that to work | 13:58 |
| Veera[m] | yes | 13:58 |
| Veera[m] | Either PATH or separate variables for that exist | 13:59 |
| lkcl | if it creates (and then uses) dynamic shared libraries | 14:00 |
| lkcl | you also have to add to either LD_LIBRARY_PATH | 14:00 |
| lkcl | or to /etc/ld.so.conf.d/{somefile}.conf | 14:00 |
| Veera[m] | Why LD_LIBRARY_PATH? | 14:00 |
| Veera[m] | I think no shared libraries are used. | 14:01 |
| lkcl | LD_LIBRARY_PATH is a standard POSIX env var for a list of locations, like $PATH, to search for dynamic libraries | 14:01 |
| lkcl | let me just check | 14:01 |
| Veera[m] | yes. I know | 14:01 |
| lkcl | $ ldd /usr/local/bin/iverilog | 14:01 |
| lkcl | linux-vdso.so.1 (0x00007ffd6624d000) | 14:01 |
| lkcl | libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4732404000) | 14:01 |
| lkcl | /lib64/ld-linux-x86-64.so.2 (0x00007f4732626000) | 14:01 |
| lkcl | yep all good. | 14:01 |
| lkcl | no need | 14:01 |
| lkcl | those are standard libraries | 14:02 |
| Veera[m] | symbiflow uses excutable binaries only no shared libraries | 14:02 |
| lkcl | excellent, whew | 14:02 |
| lkcl | i mean: if you install yosys in a separate location, that *will* need to know where its shared libraries are | 14:03 |
| lkcl | but that's handled slightly differently / automatically | 14:03 |
| lkcl | it uses a command "yosys-config" to find *out* where all the plugins / dynamic libraries are | 14:03 |
| lkcl | so as long as the right "yosys-config" is in $PATH it's all good | 14:03 |
| Veera[m] | Usually the built programs configure to find shared libraries it builds. In the symbiflow yosys is installed to /usr/local/symbiflow and it working fine. | 14:05 |
| Veera[m] | yosys-config to find out where all the plugins. YES | 14:06 |
| Veera[m] | Have you got the Xilinx ARTY_100T board? | 14:06 |
| lkcl | the problem comes when the program *installs* dynamic libraries that it itself uses, rather than using (e.g.) debian-installed /usr/lib ones | 14:07 |
| lkcl | yes | 14:07 |
| lkcl | i tested blinky lights 6 weeks ago, it worked great | 14:07 |
| lkcl | ldd /usr/local/bin/yosys | 14:07 |
| lkcl | linux-vdso.so.1 (0x00007ffc3037c000) | 14:07 |
| lkcl | libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f147ad73000) | 14:07 |
| lkcl | those are all /usr/lib and /lib | 14:07 |
| lkcl | so that's fine too. | 14:07 |
| Veera[m] | /etc/ld.so.conf.d/{somefile}.conf we can use this if needed | 14:09 |
| Veera[m] | For symbiflow we need newer yosys which supports proc_memwr command and friends | 14:10 |
| lkcl | does symbiflow do something like "$YOSYS" at all? | 14:11 |
| lkcl | or "if $SYMBIFLOW_YOSYS" | 14:11 |
| lkcl | like you see in Makefiles a lot ($GCC, $HOST_CC and so on) | 14:12 |
| Veera[m] | The final scripts use PATH I think | 14:13 |
| Veera[m] | I have to check them out. | 14:13 |
| lkcl | ok | 14:13 |
| Veera[m] | Yesterday only I finished build and install without failure | 14:14 |
| Veera[m] | !!!Have you got the Xilinx ARTY_100T board? | 14:14 |
| lkcl | nice! | 14:15 |
| lkcl | yes i have | 14:15 |
| Veera[m] | very good | 14:15 |
| Veera[m] | Do we need litex support? | 14:16 |
| lkcl | https://libre-soc.org/irclog/%23libre-soc.2021-09-25.log.html#t2021-09-25T14:07:26 | 14:16 |
| lkcl | sigh | 14:16 |
| lkcl | yes - but not as a dependency of symbiflow | 14:17 |
| lkcl | we need a "repro" system - Las[m] has a script for nix with all of the git commit checksums | 14:17 |
| Veera[m] | Guix is similar as nix pkg manager | 14:19 |
| Veera[m] | Guix was a cpu and memory hog | 14:20 |
| Veera[m] | I was/am a package manager for few programs for Guix. | 14:20 |
| lkcl | Veera[m], nice | 14:21 |
| lkcl | there's a summer of nix, if you're interested to help out, talk with Las[m] and justinrestivo[m] | 14:22 |
| lkcl | i don't know the exact situation but there *may* be NLnet EUR available | 14:22 |
| lkcl | if you've already done symbiflow then helping check that this is still functional may be useful https://github.com/HackerFoo/nix-symbiflow | 14:23 |
| lkcl | and maybe checking that the nix packages he's doing work on the TALOS-II workstation (non-x86) | 14:24 |
| lkcl | just a thought | 14:24 |
| Veera[m] | Ok. I will check. | 14:25 |
| * lkcl afk | 14:25 | |
| Las[m] | If you want to reproducibly build this stuff then yeah Nix is the answer | 14:27 |
| Las[m] | Veera: what are you trying to build? | 14:27 |
| Veera[m] | Guix used GNU guile language. Nix uses it's own language nix. | 14:27 |
| Las[m] | If you've succeded, and it's related to Libre-SOC, can you write down the steps somewhere so I can Nixify it? | 14:27 |
| Veera[m] | Las: https://libre-soc.org/HDL_workflow/symbiflow/ | 14:27 |
| Veera[m] | Built symbiflow chain for Artix7/Artix_100t | 14:28 |
| lkcl | Las[m], someone's already done symbiflow, it would be great to verify it's still operational and/or if necessary update it | 14:41 |
| lkcl | https://libre-soc.org/irclog/%23libre-soc.2021-09-25.log.html#t2021-09-25T14:23:26 | 14:41 |
| Veera[m] | lkcl: have you checked both symbiflow-arch-defs and symbiflow-examples has litex demos. Or has support to use litex. | 14:41 |
| Veera[m] | lkcl: Las pkgs uses pre-built binaries to install symbiflow. | 14:43 |
| lkcl | Veera[m], the developers of litex have been so problematic, and litex itself so fragile, i'm not that interested in spending time on it unless absolutely critically essential | 14:44 |
| lkcl | i ran just the blinky-lights and it worked great, i considered that to be "success" enough | 14:44 |
| Veera[m] | lkcl: What I have done is to make those prebuilt binaries/scripts from source and use them as well. | 14:44 |
| lkcl | Veera[m]: ahhh excellent | 14:44 |
| lkcl | Las[m], ^ | 14:45 |
| lkcl | once we have a symbiflow setup script, it can be tested *from* litex | 14:45 |
| lkcl | with litex arty.py --toolchain=symbiflow | 14:45 |
| lkcl | so, the dependency is the other way round | 14:46 |
| Veera[m] | lkcl: ref only because today you updated Bug 654 with litex-vexriscv | 14:46 |
| Veera[m] | symbiflow-examples litex demo also uses something like this. | 14:48 |
| lkcl | yes, i found a command which allows.. ahhh great | 14:52 |
| lkcl | i wanted to make sure i had a record of the command "arty.py --toolchain=symbiflow" | 14:52 |
| lkcl | it's great to hear the examples have it | 14:52 |
| Veera[m] | https://github.com/SymbiFlow/symbiflow-examples/tree/master/xc7/litex_demo | 14:53 |
| lkcl | ahh --variant a7-100 as well, that's important | 14:57 |
| lkcl | ahh that's quite valuable - https://github.com/SymbiFlow/symbiflow-examples/blob/master/xc7/litex_demo/requirements.txt | 14:57 |
| Veera[m] | https://symbiflow-examples.readthedocs.io/en/latest/building-examples.html | 15:02 |
| Las[m] | lkcl: My issuer_verilog.v: https://ipfs.io/ipfs/QmbhJjnt3KTZqJSgyxWzGpAdkEXGjzi15UBEmwJvadzUsX | 15:39 |
| Las[m] | Spent some time trying to get IPFS working lol | 15:39 |
| lkcl | deep joy :) | 15:40 |
| lkcl | i'm impressed it works... still downloading though... zzzz | 15:40 |
| lkcl | Las[m], nmigen is supposed to be deterministic. *at no time* should there be "uninitialised" values appearing in the output | 15:41 |
| lkcl | however, i have a vague recollection of a discussion about this on the #nmigen channel | 15:42 |
| lkcl | it *may* be the case that z- and x- value support was added to yosys | 15:43 |
| lkcl | but by using an earlier version of nmigen it's not syncing properly | 15:43 |
| Las[m] | I'm using an old version of Yosys now tool | 15:44 |
| Las[m] | too* | 15:44 |
| Las[m] | But I'm not using the one from the lars files you gave me | 15:44 |
| Las[m] | i.e. `.9+3475 (git sha1 f61d62a7, clang 9.0.1-12 -fPIC -Os)` | 15:45 |
| lkcl | ok. is that ipfs version from the version of yosys you're using? | 15:45 |
| Las[m] | Yeah, it's my latest build. | 15:45 |
| lkcl | ok cool. | 15:45 |
| lkcl | and same error? | 15:45 |
| lkcl | (from litex)? | 15:45 |
| Las[m] | The error hasn't changed from before, i.e. `1'0 != 1'x` or something like that | 15:46 |
| lkcl | rrrrr | 15:46 |
| lkcl | can you try using the issuer_verilog.v that i uploaded? | 15:47 |
| lkcl | https://ftp.libre-soc.org/lars_build/ | 15:47 |
| lkcl | that will help triage where this lies. | 15:48 |
| ghostmansd-pc | lkcl: there's no mentioning of changes other than bcd at https://bugs.libre-soc.org/show_bug.cgi?id=671 | 15:48 |
| lkcl | yes, that seems about right | 15:48 |
| ghostmansd-pc | but I recall we identified several instructions that must be changed | 15:48 |
| ghostmansd-pc | because as they stand they go outside of bounds bitwise | 15:49 |
| ghostmansd-pc | ori, IIRC | 15:49 |
| ghostmansd-pc | and similar things... | 15:49 |
| lkcl | yes. that's in a separate bugreport... 1sec | 15:49 |
| ghostmansd-pc | do we have a way to search through irclogs? | 15:49 |
| ghostmansd-pc | https://libre-soc.org/irclog/ | 15:49 |
| lkcl | https://bugs.libre-soc.org/show_bug.cgi?id=684 | 15:49 |
| ghostmansd-pc | I mean, not via checking each and every way :-) | 15:49 |
| lkcl | hmmm no not yet | 15:50 |
| ghostmansd-pc | hm, I missed it | 15:50 |
| lkcl | whitequark runs one that is searchable | 15:50 |
| ghostmansd-pc | ah, OK, it's assigned to you | 15:50 |
| Las[m] | I'll try using your issuer_verilog yeah | 15:50 |
| ghostmansd-pc | do you mind if I assign it to me? | 15:50 |
| lkcl | no sure | 15:50 |
| lkcl | Las[m]: ah ha! | 15:50 |
| lkcl | see how core_cr_out is 3-bit in the version i am using? | 15:51 |
| lkcl | but is 7 bit in the version you created? | 15:51 |
| lkcl | that means you have too new a version of soc (etc) | 15:51 |
| lkcl | and/or you built without --no-svp64 | 15:51 |
| lkcl | the ls180 core (the ASIC) is "straight" Power ISA v3.0B Scalar Fixed-Point | 15:52 |
| Las[m] | I have `--disable-svp64` | 15:52 |
| lkcl | so core_cr_out should only be 3 bits wide | 15:52 |
| Las[m] | Thanks for noticing that | 15:52 |
| ghostmansd-pc | lkcl, programmerjake: https://bugs.libre-soc.org/show_bug.cgi?id=684#c8 | 15:52 |
| Las[m] | One thing I don't get is: what is the difference between issuer_verilog.v and libresoc.v? | 15:52 |
| Las[m] | In the Makefile you get libresoc.v from issuer_verilog.py | 15:52 |
| Las[m] | And I sent you the result of issuer_verilog.py. Is the libresoc.v here made in another way? | 15:53 |
| lkcl | Las[m]: ahh a file rename, for convenience when copying over to soclayout :) | 15:53 |
| ghostmansd-pc | I assume this is the thing we wanna do, air? | 15:53 |
| lkcl | that's all | 15:53 |
| Las[m] | Ah, OK. | 15:53 |
| lkcl | ghostmansd-pc, it's programmerjake's mum's birthday party today, plus he's in the U.S. so it's.... mmm.... 7am? | 15:53 |
| lkcl | 8am-ish | 15:54 |
| * lkcl ponders | 15:54 | |
| ghostmansd-pc | ah, sorry, totally forget about these timezones | 15:54 |
| lkcl | Las[m]: what git revision did you use for soc (etc) | 15:54 |
| lkcl | the ls180 tag? | 15:54 |
| ghostmansd-pc | excuses to Jacob :-) | 15:54 |
| lkcl | ghostmansd-pc, oooo https://github.com/adamharrison/nginx-xapian | 15:55 |
| ghostmansd-pc | nice stuff | 15:56 |
| ghostmansd-pc | it'd also be nice if logs could filter "user exited" noise | 15:56 |
| ghostmansd-pc | (totally unrelated problem, just recalled) | 15:56 |
| lkcl | ghostmansd-pc, yes, i have a script for that. | 15:57 |
| lkcl | but i haven't finished it. i run it manually, once a week or so, at the moment | 15:57 |
| Las[m] | lkcl: I'm using 75bdc1747f32a4fb6cf848ed8b5c68ef2f683f4c | 15:57 |
| ghostmansd-pc | could it be applied to modify the contents of https://libre-soc.org/irclog? | 15:57 |
| Las[m] | for soc.git | 15:57 |
| ghostmansd-pc | or you download a local copy and run script on it? | 15:57 |
| lkcl | Las[m]: ah that's much too early | 15:58 |
| kylel | lkcl, https://bugs.libre-soc.org/show_bug.cgi?id=686 | 15:58 |
| Las[m] | Unfortunately even with the prebuilt issuer_verilog.v, I get `ERROR: Module `test_issuer' referenced in module `versa_ecp5' in cell `test_issuer' does not have a port named 'jtag_wb__we'.` | 15:58 |
| lkcl | yyeah that also sounds about right because you have to compile with different arguments for FPGA than from ASIC | 15:59 |
| lkcl | and what i uploaded there was for ASIC | 15:59 |
| lkcl | although... hang on... | 15:59 |
| Las[m] | What do I need to pass to issuer_verilog then? | 15:59 |
| Las[m] | I'm using the same one for both the FPGA and ASIC build... | 15:59 |
| lkcl | yeah i've had that work successfully, here (same one) | 16:00 |
| lkcl | problem is, this is a major distraction, it takes absolutely ages to track these things down | 16:00 |
| lkcl | and after the tape-out i "moved on" and haven't returned to either the FPGA or ASIC since | 16:02 |
| lkcl | so unless using *exactly* what went into the ASIC / FPGA back then, we can pretty much guarantee 100% it won't work | 16:02 |
| Las[m] | wait, how do you test it then | 16:02 |
| lkcl | i am running the core tests only at the moment | 16:02 |
| lkcl | which is software-only, simulated-only, not involving litex at all in any way | 16:03 |
| lkcl | which does *peripherals* (connected to the core), *not* anything else | 16:03 |
| lkcl | litex is a *peripheral*-generator (UART, I2C, etc. etc.) | 16:03 |
| lkcl | and the focus of the past few months has been "core-only" i haven't returned to litex (at all) because we don't need litex to check the modifications to the *core* | 16:04 |
| lkcl | that can all be done via the nmigen simulations. | 16:05 |
| Las[m] | So basically, it might just be broken? | 16:05 |
| lkcl | yes. | 16:05 |
| lkcl | i can't do everything - keep litex up-to-date when it's not relevant to the current focus (adding SVP64 support) | 16:06 |
| lkcl | i'll come *back* to it when it's time to try running on an FPGA | 16:06 |
| Las[m] | lol | 16:07 |
| lkcl | in the meantime it's safest to use versions of soc (etc.) that predate the latest stuff of the past few months | 16:07 |
| lkcl | https://git.libre-soc.org/?p=soc.git;a=commit;h=290c36c7210934b5f832ccb97a112e490af45169 | 16:07 |
| Las[m] | Thanks, I'll do that | 16:07 |
| lkcl | is prooobably too early, but maybe not | 16:07 |
| Las[m] | Perhaps I can bisect it and see where it broke! | 16:07 |
| lkcl | :) | 16:07 |
| lkcl | if you use something from around... i think... June/July, it should be good | 16:08 |
| lkcl | definitely before the big split moving things to the new openpower-isa repo though | 16:08 |
| Las[m] | from which project was it that nextpnr and ecppack came? | 16:10 |
| Las[m] | nextpnr-ecp5 specifically | 16:10 |
| lkcl | looking through here | 16:10 |
| lkcl | https://git.libre-soc.org/?p=soc.git;a=shortlog;pg=1 | 16:10 |
| lkcl | this one looks like a good starting point https://git.libre-soc.org/?p=soc.git;a=commit;h=449819b4ac953519db729c1c17abb131f0a0f328 | 16:11 |
| lkcl | Las[m], nextpnr-ecp5 we use this https://git.libre-soc.org/?p=dev-env-setup.git;a=blob;f=nextpnr-ecp5-install;hb=HEAD | 16:11 |
| Las[m] | Thanks! | 16:12 |
| lkcl | it's not fixed to a particular commit though (oops) | 16:12 |
| Las[m] | Ah, so prjtrellis gives ecppack? | 16:12 |
| lkcl | i have nooo idea :) | 16:12 |
| * lkcl head spinning, so many context-switches right now | 16:12 | |
| lkcl | ghostmansd-pc, a next high-priority task, if we may reasonably assume that XLEN=32 and XLEN=16 are the easier things to tackle first, is to move all "helper" routines into a class | 16:13 |
| lkcl | which ISACaller then inherits from | 16:13 |
| lkcl | and that's actually quite a big (but straightforward) task, again, one of those "hit it all at once doing only one thing" tasks | 16:14 |
| lkcl | where decoder/pseudo/parser.py needs to learn about the helper function names | 16:15 |
| lkcl | and add a "self." in front of the function name | 16:15 |
| ghostmansd-pc | you mean src/openpower/decoder/helpers.py? | 16:15 |
| lkcl | yes. every function in there needs to move to a "class" | 16:15 |
| ghostmansd-pc | ok, gotcha | 16:15 |
| ghostmansd-pc | does it have an issue? | 16:15 |
| lkcl | which ISACaller then inherits from | 16:15 |
| lkcl | no not yet, feel free to raise it | 16:15 |
| ghostmansd-pc | I mean bugzilla ticket | 16:15 |
| ghostmansd-pc | ok | 16:15 |
| lkcl | cf the irclog here https://libre-soc.org/irclog/%23libre-soc.2021-09-25.log.html#t2021-09-25T16:13:44 | 16:16 |
| * lkcl thinks | 16:16 | |
| Las[m] | I was actually wrong! Pinning Yosys and Migen to an old version fixed my problem. Now Yosys doesn't fail anymore! Now it's telling me nextpnr isn't available, which should be easy to fix :). | 16:16 |
| lkcl | frickin unbelievable. | 16:17 |
| lkcl | thank god for that | 16:17 |
| lkcl | then it was the sync-up between nmigen and yosys | 16:17 |
| lkcl | if we updated nmigen as well it would "probably" work | 16:17 |
| lkcl | but | 16:17 |
| lkcl | other things might also break. sigh | 16:17 |
| Las[m] | The great thing about Nix, is it's easy to test different versions of dependencies and revert them if they don't work, as I'm doing right now actually. | 16:18 |
| Las[m] | Does Libre-SOC have any CI? | 16:21 |
| lkcl | Las[m], sigh, no. it's been on the TODO list for 18 months. | 16:21 |
| lkcl | most of which was delayed by me not being comfortable with the thought of storing auto-generated output on the server (which i pay for, personally) | 16:22 |
| lkcl | and was finally resolved by a decision to run a mailing list *on* the CI server behind the VPN | 16:22 |
| lkcl | (it's jacob's personal machine) | 16:22 |
| lkcl | the idea being, if there is an error, that's all we care about, and can raise a bugreport about it manually. | 16:23 |
| Las[m] | So there is a CI machine? | 16:23 |
| lkcl | if there's no error, we don't care | 16:23 |
| lkcl | yes, but it's not active. | 16:23 |
| Las[m] | Setting up CI with Nix is trivial FYI | 16:23 |
| Las[m] | I got it built! I'll upload the svf file I got. | 16:29 |
| lkcl | ooooo cooool | 16:30 |
| Veera[m] | lkcl: can you set me a password for TALOS | 16:34 |
| lkcl | Veera[m], no, i will add you to sudoers | 16:34 |
| Veera[m] | lkcl: using sudo asks one. | 16:34 |
| lkcl | done. | 16:34 |
| lkcl | it should not ask for a password, now | 16:35 |
| lkcl | kylel, not quite done :) | 16:35 |
| ghostmansd-pc | lkcl: are there plans to support 128-bit? | 16:36 |
| Veera[m] | lkcl: ok | 16:36 |
| lkcl | still a couple more morphing steps to do | 16:36 |
| ghostmansd-pc | I have a vague impression there's, but I cannot get how it might fit | 16:36 |
| lkcl | ghostmansd-pc: there are about 1-2 instructions we may need, but they're part of the existing scalar ISA | 16:36 |
| ghostmansd-pc | I'm asking because, well, we'd have something else other than 63 (e.g. REGMAX-1) | 16:36 |
| lkcl | i can't remember what they are | 16:36 |
| lkcl | yes, the general plan is to justify XLEN as a proposal to the OpenPOWER ISA WG, *because* it is possible to set XLEN=128 for some future version of the spec | 16:37 |
| lkcl | and also XLEN=32... in the *scalar* ISA, nothing to do with SVP64 at all (or for XLEN=128, either) | 16:38 |
| ghostmansd-pc | this code RA <- (RS) & ([0]*48 || UI)[63-XLEN:63] | 16:38 |
| lkcl | the resources consumed by embedded implementations being FORCED to have 64-bit regfiles and datapaths, but never operating with anything other than MSR set to 32bit, is immense | 16:38 |
| ghostmansd-pc | it should also take 48 and 63 respectively then | 16:39 |
| ghostmansd-pc | not in this revision I think, but in the future for sure | 16:39 |
| lkcl | ... | 16:39 |
| ghostmansd-pc | https://bugs.libre-soc.org/show_bug.cgi?id=684#c9 | 16:39 |
| lkcl | jacob wasn't aware of the possibility of XLEN=128 at the time he wrote that | 16:40 |
| ghostmansd-pc | Granted that we have this possibility now, what's the code to be used? I like the Jacob suggestion way more than if clause everywhere. | 16:41 |
| lkcl | there's about 5 separate and distinct requirements to satisfy here, most of them quite nebulous / strategic, all related to "how will IBM's engineers who have been the sole exclusive maintainers of this spec for 20+ years view these changes" | 16:41 |
| lkcl | hell yes | 16:41 |
| ghostmansd-pc | But for 128-bit it's not scalable, at least not as it stands | 16:41 |
| lkcl | correct. | 16:41 |
| lkcl | which is why i suggested XTRUNC | 16:41 |
| ghostmansd-pc | Aha, got it. So basically we'll wrap all these with XTRUNC, which already contains the needed heuristics? | 16:42 |
| lkcl | i like the names XLCASTU and XLCASTS | 16:42 |
| lkcl | because we need both | 16:42 |
| lkcl | one would call EXTS behind the scenes but that's an implementation detail | 16:43 |
| ghostmansd-pc | Hm. I don't get what [0]*-8 is supposed to mean. | 16:44 |
| lkcl | that's definitely a bug | 16:44 |
| lkcl | it's impossible | 16:44 |
| ghostmansd-pc | RA <- (RS) ^ XTRUNC([0]*(XLEN-16) || UI) | 16:44 |
| lkcl | eeexactlyyyyy oh wait | 16:44 |
| lkcl | haha | 16:45 |
| lkcl | whooops | 16:45 |
| lkcl | urrrr... | 16:45 |
| ghostmansd-pc | Given this pseudocode, this seems possible :-) | 16:45 |
| lkcl | urrrrr.... | 16:45 |
| lkcl | it should just be | 16:45 |
| lkcl | RA <- (RS) ^ XCASTU(UI) | 16:45 |
| lkcl | because XCASTU will perform *either* zero-extending (to XLEN) *or* it will perform truncation (when XLEN=8) | 16:46 |
| lkcl | based on the width of UI, which it will know about, because UI is a SelectableInt | 16:47 |
| lkcl | and so has a width parameter | 16:47 |
| lkcl | but! | 16:47 |
| lkcl | you notice i said, "XCASTU" knows about XLEN? | 16:47 |
| lkcl | how can that be... *unless* XCASTU has access to "self.XLEN"? | 16:47 |
| lkcl | which is whyyyyy all the helper routines need to move to a class | 16:48 |
| lkcl | class Helpers: | 16:48 |
| lkcl | def XCASTU(self, ....): | 16:48 |
| lkcl | return something(self.XLEN) ... | 16:48 |
| lkcl | def EXTS(self, .....) | 16:48 |
| Las[m] | lkcl: https://ipfs.io/ipfs/QmRqDMWi3P4XyarB5mBXNpcvdBodyMjP1HweT656nCgb3u | 16:48 |
| lkcl | do_something_using_self.XLEN | 16:48 |
| lkcl | etc. etc | 16:48 |
| ghostmansd-pc | OK, and for those which put UI in the middle, it'd be XCASTU(UI || [0]*16)? | 16:49 |
| lkcl | yyyep | 16:49 |
| ghostmansd-pc | OK, it becomes much more clear | 16:49 |
| lkcl | Las[m], ack, just grabbing it | 16:49 |
| ghostmansd-pc | but now it looks 684 is blocked :-) | 16:49 |
| Las[m] | Now to try using this... | 16:50 |
| ghostmansd-pc | I mean that we _have_ to move helpers into the class first | 16:50 |
| lkcl | ghostmansd-pc, yyep. dependent on... yes. | 16:50 |
| lkcl | i sort-of kinda nebulously knew that, subconsciously | 16:50 |
| ghostmansd-pc | :-D | 16:51 |
| lkcl | ghostmansd-pc, so do raise the bugreport, i'll chip in when i see it and fill in some details | 16:51 |
| * lkcl afk, need to get up and walk about | 16:51 | |
| Las[m] | libresoc-litex fix: https://github.com/ngi-nix/libresoc-litex/commit/d1c6391d0c35d1b375e9f12253b2b9f9031e0c3c | 16:51 |
| ghostmansd-pc | OK, I'm raising the bug report | 16:51 |
| Las[m] | programmerjake: Could you merge this too? | 16:51 |
| * lkcl be interested to hear if that runs, Las[m] | 16:51 | |
| Las[m] | Yeah will definitely try, once I figure out how to use an FPGA! | 16:51 |
| lkcl | Las[m], programmerjake is not awake yet, and it's his mum's birthday today | 16:51 |
| lkcl | Las[m], also, i gave you write perms | 16:52 |
| lkcl | oh - do update the comment as well | 16:52 |
| lkcl | 1<<15 is no longer 0x8000 | 16:52 |
| lkcl | err... one of those might have been out-of-date, whoops | 16:53 |
| * lkcl _now_ afk :) | 16:53 | |
| ghostmansd-pc | ok, ping when you're back :-) | 16:53 |
| Las[m] | That line was made in one commit though, so you must either have written 12, or you had problems with 15 and set it to 12 temporarily | 16:55 |
| ghostmansd-pc | Luke, https://bugs.libre-soc.org/show_bug.cgi?id=712 | 17:11 |
| lkcl | ghostmansd-pc, got it | 18:48 |
| ghostmansd-pc | basic redirection class implemented, tests are in progress | 19:10 |
| ghostmansd-pc | currently class only has `xlen` on init (I suppose it's not its property, though), and its methods simply call global scope stuff | 19:11 |
| ghostmansd-pc | also parser has a list of such "helpers" which should be translated into the "self.XXX" call | 19:11 |
| ghostmansd-pc | and, well, I also inherit from this class in pywriter (IIRC class ISA) | 19:12 |
| ghostmansd-pc | let's see how it goes | 19:12 |
| ghostmansd-pc | lkcl: could you, please, talk with Maciej, so that he's aware of this task and its importance? | 19:14 |
| ghostmansd-pc | off-topic: https://libre-soc.org/irclog/%23libre-soc.2021-09-24.log.html#t2021-09-24T21:14:07 | 19:15 |
| lkcl | ha, funny, you noticed i had a couple of functions that already get redirected to "self.xxxx" | 20:02 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=6272a54e19e32d2985435c363cd6625d3fff4b83 | 20:03 |
| lkcl | neat trick! | 20:03 |
| lkcl | ah - please don't use "types". i absolutely cannot stand them. | 20:03 |
| lkcl | if you absolutely must have them, put them into a separate .pyi file, and commit them in the corresponding location | 20:04 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=e0058a290d5b2ea9e5847fe2256f4bc528175f37 | 20:04 |
| lkcl | types sounded like such a great idea but in reality they do absolutely nothing useful and severely hinder Liskov Substitution Principle | 20:04 |
| lkcl | i'd suggest simply have ISACaller inherit from ISACallerHelper | 20:06 |
| * lkcl going to try it anyway, see what happens | 20:06 | |
| lkcl | oh whoops | 20:08 |
| lkcl | xlen is not rebased against the right master branch | 20:08 |
| ghostmansd | Yes, and, also, there is a worse problem | 20:16 |
| ghostmansd | I'm struggling how to solve that one | 20:16 |
| ghostmansd | self.__module__ only works as long as we're in __main__ | 20:16 |
| lkcl | class.__something__.__something__ | 20:16 |
| lkcl | self.__class__._-something__ | 20:17 |
| lkcl | no wait | 20:17 |
| ghostmansd | Or, well, at least the trick worked when I tried it on simpler script | 20:17 |
| lkcl | there's a way to get it. | 20:17 |
| ghostmansd | But you liked it, right? | 20:17 |
| ghostmansd | I really wanted to avoid all this code duplication | 20:17 |
| ghostmansd | Having a method for each function | 20:17 |
| lkcl | __name__ | 20:17 |
| lkcl | yes. | 20:17 |
| lkcl | it's a good temporary hack | 20:18 |
| lkcl | ultimately each function will need to move into ISACallerHelpers | 20:18 |
| ghostmansd | Hm. Let me check with __name__ | 20:18 |
| ghostmansd | Yes | 20:18 |
| lkcl | but, actually, it can be done on-demand | 20:18 |
| ghostmansd | But, for now, I'd like to do it after changes in parser, and then convert on demand | 20:18 |
| ghostmansd | Yep | 20:18 |
| ghostmansd | You're reading my mind again :-( | 20:19 |
| lkcl | haha | 20:19 |
| ghostmansd | *:-) | 20:19 |
| ghostmansd | Because, well, not all depend on XLEN (actually most of them don't) | 20:19 |
| lkcl | can you please rebase xlen against latest master? | 20:19 |
| ghostmansd | Yes, sure | 20:19 |
| ghostmansd | Done | 20:20 |
| lkcl | star | 20:20 |
| cesar | lkcl: "python ~/src/soc/src/soc/simple/test/test_issuer.py nosvp64 ldst" is failing for me. | 20:20 |
| lkcl | i want to try a simulation against it | 20:20 |
| lkcl | if it works, pffh | 20:21 |
| lkcl | cesar, 1 sec let me check | 20:21 |
| lkcl | ah, i'm just rebuilding fixedarith and fixedshift | 20:21 |
| lkcl | which whoops | 20:22 |
| lkcl | ghostmansd, | 20:22 |
| lkcl | File "/home/lkcl/src/libresoc/openpower-isa/src/openpower/decoder/isa/fixedshift.py", line 374, in op_extswsli | 20:22 |
| lkcl | r = self.ROTL64(self.EXTS64(RS[XLEN // 2:XLEN - 1 + 1]), n) | 20:22 |
| lkcl | AttributeError: 'ISA' object has no attribute 'ROTL64' | 20:22 |
| * lkcl switching back to master branch | 20:22 | |
| lkcl | be with you in a sec, cesar | 20:22 |
| lkcl | rebuilding fixedarith almost done | 20:23 |
| lkcl | ok running now | 20:23 |
| lkcl | cesar, yep, they're all borked, aren't they | 20:24 |
| lkcl | actually, not all | 20:25 |
| lkcl | yes all :) | 20:26 |
| ghostmansd | lkcl: I think I know what's the issue, let me check it... | 20:29 |
| ghostmansd | I switched to running test_caller now, test_issuer takes too much time for such a simple issue | 20:30 |
| lkcl | ghostmansd, yehyeh | 20:30 |
| lkcl | we've cut the time down by adding command-like options | 20:30 |
| ghostmansd | I already use nosvp64 | 20:31 |
| lkcl | nosvp64 {insertpipelinename} | 20:31 |
| ghostmansd | Are there others I should know? | 20:31 |
| ghostmansd | Any docs on this? | 20:31 |
| lkcl | nosvp64 {insert list of pipelinenames} | 20:31 |
| lkcl | nope. | 20:31 |
| lkcl | see test_issuer.py | 20:31 |
| ghostmansd | Or the code is the best doc, lol? | 20:31 |
| ghostmansd | Ok | 20:31 |
| ghostmansd | I knew that in advance l | 20:31 |
| lkcl | too much going on | 20:31 |
| ghostmansd | Ok | 20:32 |
| lkcl | cesar, something today broke it, i'm binary-searching now | 20:32 |
| lkcl | cesar, kylel: commit f164672e4e | 20:34 |
| lkcl | ldst is broken by that one | 20:34 |
| * lkcl investigating | 20:34 | |
| lkcl | kylel: + #yield from setup_tst_memory(l0, self.test.mem) | 20:38 |
| lkcl | you commented that out | 20:38 |
| lkcl | all good | 20:39 |
| * lkcl rerunning all the ldst unit tests | 20:40 | |
| lkcl | cesar, git pull, should be good | 20:41 |
| lkcl | ghostmansd, ahhh hang on... | 20:43 |
| ghostmansd | I know | 20:44 |
| lkcl | ISACallerHelper is imported in things written by pywriter | 20:44 |
| lkcl | but not used | 20:44 |
| ghostmansd | I must use name exactly for this class | 20:44 |
| lkcl | best to just import it at ISACaller | 20:44 |
| lkcl | once, in caller.py | 20:44 |
| ghostmansd | ISACallerHelper.__module__ does the trick | 20:44 |
| lkcl | excellent | 20:44 |
| lkcl | i will do the inheritance in ISACaller | 20:45 |
| ghostmansd | Because otherwise it takes the module for inherited class | 20:45 |
| ghostmansd | Which, on second thought, makes perfect sense | 20:45 |
| ghostmansd | But not on the first, lol | 20:45 |
| cesar | lkcl: Confirmed fixed. Yay! | 20:46 |
| lkcl | ghostmansd, pushed to xlen branch | 20:46 |
| lkcl | don't do a force-push | 20:46 |
| lkcl | ghostmansd, confirmed, that works | 20:49 |
| lkcl | cesar, excellent | 20:49 |
| ghostmansd | I did, but with your commit :-) | 20:49 |
| lkcl | ghostmansd :) | 20:49 |
| lkcl | did you commit the getattr? | 20:49 |
| lkcl | answer yes | 20:50 |
| ghostmansd | Yes :-) | 20:50 |
| ghostmansd | Running tests | 20:50 |
| ghostmansd | I wanna finish it today | 20:50 |
| lkcl | have to re-run pywriter sigh | 20:50 |
| ghostmansd | Me too | 20:51 |
| lkcl | i can take care of cherrypicking | 20:51 |
| ghostmansd | If that works, lol | 20:51 |
| ghostmansd | You for sure saw I had these routines as set | 20:51 |
| ghostmansd | Quite ugly | 20:51 |
| ghostmansd | But at least more obvious than inspect | 20:51 |
| lkcl | pffh | 20:52 |
| lkcl | a code-comment would be a good idea | 20:52 |
| ghostmansd | Funny that I did it before your comment :-) | 20:52 |
| lkcl | :) | 20:52 |
| lkcl | test_caller.py works | 20:52 |
| ghostmansd | Because otherwise I'd have considered using inspect | 20:52 |
| ghostmansd | Yes, that one I checked | 20:53 |
| lkcl | but i only converted fixedshift and fixedarith | 20:53 |
| ghostmansd | Looking forward to test_issuer | 20:53 |
| ghostmansd | I only check test_add | 20:53 |
| lkcl | do add a comment on this one | 20:53 |
| lkcl | def __getattr__(self, attr): | 20:53 |
| lkcl | return getattr(sys.modules[ISACallerHelper.__module__], attr) | 20:53 |
| ghostmansd | Ok, once I prove it really works everywhere :-) | 20:53 |
| lkcl | "turns global function into class member, a bit better than using inspect" | 20:53 |
| lkcl | something like that :) | 20:53 |
| lkcl | i'm going to run the whole lot (entire pywriter) | 20:54 |
| lkcl | which takes a while | 20:54 |
| ghostmansd-pc | python3 src/openpower/decoder/pseudo/pywriter.py && cd ../soc/ && python3 src/soc/simple/test/test_issuer.py nosvp64 | 20:54 |
| ghostmansd-pc | that's what I do | 20:54 |
| lkcl | you can use noall to skip overwriting it | 20:54 |
| lkcl | pywriter noall fixedarith | 20:55 |
| lkcl | will *only* compile fixedarith | 20:55 |
| lkcl | very useful for saving time | 20:55 |
| lkcl | must really do without the All thing | 20:55 |
| ghostmansd-pc | that I usually do when I do some quick checks | 20:55 |
| ghostmansd-pc | e.g. test_caller.py | 20:55 |
| ghostmansd-pc | but now I'm running test_issuer on talos | 20:55 |
| ghostmansd-pc | so I want to recompile this all | 20:55 |
| lkcl | we're damn lucky in this case, that the change is, by coincidence, compatible with the old version | 20:56 |
| ghostmansd-pc | it's already done, the tests are running | 20:56 |
| lkcl | excellent | 20:56 |
| ghostmansd-pc | well, all files must be regenerated | 20:56 |
| ghostmansd-pc | because all .py files have now self.blah | 20:56 |
| ghostmansd-pc | instead of blah | 20:56 |
| lkcl | yehyeh | 20:56 |
| lkcl | but because of the introspection trick | 20:56 |
| ghostmansd-pc | ah, yes | 20:57 |
| lkcl | if you didn't run pywriter *it still worked* | 20:57 |
| ghostmansd-pc | it costed a little blood | 20:57 |
| lkcl | okaaay off we go | 20:57 |
| ghostmansd-pc | way less than I thought it would | 20:57 |
| ghostmansd-pc | I have a feeling it will work :-) | 20:57 |
| lkcl | i'll run the other test_caller*.py whilst test_issuer.py is going | 20:58 |
| ghostmansd-pc | still running, but I see a potential, lol | 20:58 |
| ghostmansd-pc | ok | 20:58 |
| lkcl | :) | 20:58 |
| lkcl | svp64.py good | 20:59 |
| lkcl | svp64_dct.py good | 20:59 |
| lkcl | svp64_ldst.py good | 21:00 |
| ghostmansd-pc | issuer's still running... | 21:00 |
| lkcl | yehyeh | 21:00 |
| lkcl | blast. overwrote the output log file | 21:00 |
| lkcl | damnit | 21:00 |
| lkcl | test_caller_shift_rot.py shiftrot2 good | 21:01 |
| lkcl | test_caller_fp.py good | 21:02 |
| lkcl | test_caller_svp64_fft.py good | 21:04 |
| lkcl | test_caller_bcd.py good | 21:05 |
| lkcl | test_caller_svp64_matrix.py good | 21:05 |
| lkcl | test_caller_svp64_mapreduce.py good | 21:05 |
| lkcl | i'm going to call this one ok :) | 21:06 |
| ghostmansd-pc | let's wait for issuer | 21:08 |
| ghostmansd-pc | still running | 21:08 |
| ghostmansd-pc | but from the code looks OK | 21:08 |
| ghostmansd-pc | if yes, I'll drop type annotation before comitting it | 21:08 |
| lkcl | too late already picked and pushed :) | 21:09 |
| ghostmansd-pc | lol | 21:09 |
| lkcl | wark-wark | 21:09 |
| ghostmansd-pc | ok, will continue tomorrow | 21:09 |
| lkcl | ack. | 21:10 |
| ghostmansd-pc | please check this https://libre-soc.org/irclog/latest.log.html#t2021-09-25T19:15:35 | 21:10 |
| lkcl | willdo. i'll add him to it | 21:10 |
| ghostmansd-pc | "Please read: A Personal Appeal from (X) Founder (Y)" | 21:10 |
| ghostmansd-pc | lol | 21:10 |
| lkcl | ehn? | 21:10 |
| ghostmansd-pc | that's from wikipedia funding | 21:11 |
| lkcl | oh, NLnet: they take 2 weeks but if it's been that long do ping them | 21:11 |
| lkcl | oh god | 21:11 |
| lkcl | yeahh | 21:11 |
| lkcl | like, "emotional blackmail is going to help" | 21:11 |
| lkcl | sigh | 21:11 |
| ghostmansd-pc | https://knowyourmeme.com/memes/events/2010-wikipedia-fundraising-campaign | 21:11 |
| * lkcl mmmmmmmeeeeemes | 21:12 | |
| ghostmansd-pc | :-D | 21:12 |
| ghostmansd-pc | hm, I see some load-store failures | 21:12 |
| ghostmansd-pc | shoud've updated repo, amirite? | 21:12 |
| ghostmansd-pc | granted that ldst discussion above | 21:13 |
| ghostmansd-pc | https://libre-soc.org/irclog/latest.log.html#t2021-09-25T20:20:56 | 21:13 |
| ghostmansd-pc | 9 failures, all come from ldst | 21:13 |
| ghostmansd-pc | everything else is fine | 21:13 |
| ghostmansd-pc | looks like OK, no need to revert :-) | 21:13 |
| lkcl | yep i have no ldst failures here | 21:14 |
| lkcl | all good | 21:14 |
| ghostmansd-pc | ok | 21:14 |
| ghostmansd-pc | I have to add 712 into the list of "DONE" items, but also tomorrow | 21:16 |
| ghostmansd-pc | actually it's way simpler than I described in the first comment | 21:16 |
| ghostmansd-pc | kinda proud of this hack | 21:16 |
| ghostmansd-pc | (even though it's still a hack) | 21:17 |
| lkcl | yehyeh no, i love it. | 21:17 |
| lkcl | no need, no need for speeeeed | 21:17 |
| ghostmansd-pc | no need for speed, only fast and furious, lol | 21:18 |
| lkcl | i love those films. | 21:18 |
| lkcl | so ridiculous they're great | 21:18 |
| ghostmansd-pc | :-D | 21:18 |
| ghostmansd-pc | I liked the game | 21:18 |
| ghostmansd-pc | most wanted was good one | 21:18 |
| ghostmansd-pc | dropping the donut on police... that's insane | 21:19 |
| lkcl | haha | 21:19 |
| ghostmansd-pc | ok see ya tomorrow, let me know if I need to drop a letter to nlnet | 21:19 |
| ghostmansd-pc | perhaps Maciej should also be CCed | 21:19 |
| ghostmansd-pc | I have no idea if he was luckier | 21:19 |
| lkcl | k | 21:20 |
| lkcl | yes good idea | 21:20 |
| lkcl | cc me | 21:20 |
| ghostmansd-pc | ok, but what address should I use? | 21:20 |
| ghostmansd-pc | same ones as the ones where I sent the requests? | 21:20 |
| ghostmansd-pc | or is there some representative? | 21:21 |
| lkcl | michiel@nlnet.nl and 2010-10P@nlnet.nl | 21:21 |
| ghostmansd-pc | rfp@nlnet.nl 2019-10P@nlnet.nl | 21:21 |
| lkcl | sorry | 21:21 |
| ghostmansd-pc | those were e-mails I used | 21:21 |
| lkcl | michiel@nlnet.nl and 2019-10P@nlnet.nl | 21:21 |
| ghostmansd-pc | aha, OK, will do it tomorrow | 21:21 |
| lkcl | don't bug the rfp@nlnet.nl except with actual RFPs | 21:21 |
| * lkcl salutes | 21:22 | |
| ghostmansd-pc | bb | 21:22 |
| kylel | lkcl, been debating what to do about the parameter list for run_test() | 21:22 |
| kylel | in regards to getting it into a nice loop for all states | 21:23 |
| kylel | kwargs with a dict? | 21:24 |
| kylel | leave as separate calls? | 21:25 |
| kylel | pad hdlrun with unused arguments? (pretend I didn't say that) | 21:27 |
| lkcl | kylel, to be honest i don't think it even matters | 22:48 |
| lkcl | as in: all runners are completely transparently independent of each other | 22:49 |
| lkcl | and, thanks to the State API, comparing one against the other is like, pffh, who cares | 22:49 |
| lkcl | (except for the names) | 22:50 |
| lkcl | but even there, the names (for debug purposes) come from the XXXState class | 22:50 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!