| lkcl | sorry programmerjake i actually really like the idea of auto-reading markdown for field-offsets: it's just that it's literally the 4th completely disparate system for field offsets introduced into the codebase | 01:05 |
|---|---|---|
| lkcl | things like that need to be discussed and planned | 01:06 |
| *** gnucode <gnucode!~gnucode@user/jab> has quit IRC | 02:48 | |
| programmerjake | so, if/when we need to parse the latex field definitions, we can maybe use the parser i wrote as a base, but not now. | 05:55 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@91.205.168.99> has joined #libre-soc | 05:56 | |
| programmerjake | it's more designed for when you need to parse lots of fields, where error checking is helpful cuz errors are much more likely...like why the pseudocode parser has nonzero error checking (though it is too close to zero imho) | 05:57 |
| programmerjake | as i said, i went overboard...sorry | 05:58 |
| programmerjake | oh, also: https://www.phoronix.com/news/AMD-openSIL-Replace-AGESA | 06:00 |
| programmerjake | hopefully it is 100% open, and not the 75% that is amdgpu | 06:00 |
| *** ghostmansd <ghostmansd!~ghostmans@91.205.168.99> has joined #libre-soc | 08:45 | |
| ghostmansd | Hi folks, I'm back from flight and vacation, and managed to check https://bugs.libre-soc.org/show_bug.cgi?id=910 | 08:48 |
| ghostmansd | Apparently I was confused, because I assumed that minmax has RA_OR_ZERO, and thought that binutils need to switch to RA0 operand | 08:49 |
| ghostmansd | But this is not the case: minmax instruction does not have RA_OR_ZERO input selectors | 08:50 |
| programmerjake | hmm, maybe it should? i added (RA|0) to the pseudocode but didn't think about the csv... | 08:52 |
| programmerjake | added to todo list in #1057 | 08:57 |
| programmerjake | apparently luke thought yes: https://bugs.libre-soc.org/show_bug.cgi?id=915#c5 | 08:59 |
| ghostmansd | I can handle it | 09:10 |
| ghostmansd | Just needed a confirmation :-) | 09:11 |
| ghostmansd | So, in minor_19.csv... | 09:12 |
| ghostmansd | ----000011,ALU,OP_MINMAX,RA,RB,NONE,RT,NONE,CR0,0,0,ZERO,0,NONE,0,0,0,0,0,0,RC,0,0,minmax,MM,,1,unofficial until submitted and approved/renumbered by the opf isa wg | 09:12 |
| ghostmansd | should be replaced with | 09:12 |
| ghostmansd | ----000011,ALU,OP_MINMAX,RA_OR_ZERO,RB,NONE,RT,NONE,CR0,0,0,ZERO,0,NONE,0,0,0,0,0,0,RC,0,0,minmax,MM,,1,unofficial until submitted and approved/renumbered by the opf isa wg | 09:12 |
| ghostmansd | correct? | 09:13 |
| programmerjake | yeah, probably. do run the unit tests, since i only know they work w/o RA_OR_ZERO | 09:14 |
| ghostmansd | if I create a separate branch, CI will pick it, right? | 09:15 |
| programmerjake | yes | 09:15 |
| ghostmansd | OK, pushed into branch | 09:15 |
| programmerjake | though it takes 40min to run since my server has a really old cpu | 09:15 |
| programmerjake | if you run pytest locally it'll likely be much faster | 09:16 |
| ghostmansd | which test do we have for it? | 09:16 |
| ghostmansd | I can run it on talos | 09:16 |
| ghostmansd | av_cases | 09:17 |
| programmerjake | if you just want to run the minmax test file by itself, it should be <1min, probably 5min if you run all tests in parallel | 09:18 |
| programmerjake | in order to run tests in parallel, you'll need pytest-xdist, icr if it's installed by default by our scripts | 09:19 |
| ghostmansd | anything I should run before this test? | 09:20 |
| programmerjake | make, probably | 09:20 |
| ghostmansd | pywriter, or something similar? | 09:20 |
| programmerjake | make covers all of that | 09:20 |
| ghostmansd | aha, I knew there's something I miss! | 09:20 |
| programmerjake | I optimized it so make should take <30s | 09:20 |
| programmerjake | see the .gitlab-ci.yml for the commands to run | 09:22 |
| programmerjake | mostly just make and: | 09:22 |
| programmerjake | SILENCELOG='!*,default' pytest -n auto -v src/openpower --maxfail=5 | 09:22 |
| ghostmansd | I see that we install binutils-powerpc64-linux-gnu binutils-powerpc64le-linux-gnu | 09:25 |
| ghostmansd | Likely we should use dev-env-setup/binutils-gdb-install script instead | 09:26 |
| ghostmansd | Launched pytest | 09:29 |
| ghostmansd | How to install pytest globally in chroot? | 09:30 |
| programmerjake | pip | 09:31 |
| programmerjake | or just install it for your user | 09:31 |
| programmerjake | python3 -m pip install --user pytest-xdist | 09:31 |
| ghostmansd | ============================================================================== 5 failed, 187 passed, 4 skipped, 1 xfailed, 245 warnings in 161.46s (0:02:41) =============================================================================== | 09:32 |
| ghostmansd | Will check master now | 09:32 |
| programmerjake | yeah, something broke, master only should have 2 errors | 09:35 |
| programmerjake | something broke on your branch or in your chroot | 09:35 |
| programmerjake | i'd guess you're missing something in your chroot, you may want to just wait for ci to finish | 09:39 |
| ghostmansd | OK :-) | 09:40 |
| ghostmansd | 1 question: I see that openpower/isatables/RM-1P-2S1D.csv is generated | 09:40 |
| ghostmansd | Why do we commit it, then? | 09:40 |
| programmerjake | idk, cuz that's what luke decided? | 09:41 |
| ghostmansd | lol | 09:41 |
| programmerjake | oh, nvm, i know why...because we want to be able to see it on the wiki and the wiki doesn't run svanalysis.py | 09:42 |
| ghostmansd | k then | 09:42 |
| programmerjake | since it's technically part of the svp64 specification | 09:42 |
| ghostmansd | yeah seems you're right about configuration | 09:43 |
| ghostmansd | master also has a lot of failures | 09:43 |
| ghostmansd | I'll wait for CI then | 09:43 |
| programmerjake | do note that ci only reports the first 5 errors, so if it says 5 errors there may be many more | 09:45 |
| programmerjake | i chose to have it do that because otherwise the whole error report goes past the 4MB log length limit where gitlab just ignores all further output | 09:46 |
| programmerjake | making it really hard to see what failed | 09:47 |
| lkcl | programmerjake, yes. i like the idea, the commit is recorded so can be picked up later | 09:54 |
| lkcl | nohup pytest-3 -v -n 8 | 09:55 |
| lkcl | if you set to -n auto it can overload your machine | 09:55 |
| lkcl | > use dev-env-setup/binutils-gdb-install script instead | 09:56 |
| lkcl | yes... and update all documentation to match | 09:56 |
| programmerjake | oh, my desktop picks n=32, the build server picks 8 | 09:56 |
| lkcl | don't recommend to people that they should run "-n auto" on personal machines without warning them of the consequences | 09:57 |
| lkcl | on my laptop it puts such a high loadavg that it becomes unresponsive | 09:57 |
| programmerjake | well...generally builds are expected to use all cpu cores, right?... | 09:57 |
| lkcl | i'm forced to limit those as well | 09:58 |
| lkcl | which is why i remove all occurrences of "make -j $nproc" from all build scripts whenever it is added | 09:58 |
| lkcl | what is reset_xflags()? | 09:58 |
| lkcl | and why is it not present? | 09:59 |
| programmerjake | maybe you should just run your whole chroot under cpuset (or whatever the name is), that way all builds that reasonably expect to use all cores can, just they only see however many cores you selected | 09:59 |
| lkcl | too much effort both for me and for new developers | 10:00 |
| programmerjake | reset_xflags is a function from powerisa v3.1 that i haven't yet added | 10:00 |
| lkcl | do add functions as stubs if they are used, or comment out the unit tests | 10:01 |
| lkcl | i don't mind code being added as long as it isn't actually in use | 10:01 |
| programmerjake | i left it uncommented so you can see if fpscr is recognized, i'll fix it soon | 10:01 |
| ghostmansd | FAILED src/openpower/decoder/isa/test_caller_fmv_fcvt.py::TestFMvFCvtCases::test - AttributeError: reset_xflags | 10:02 |
| ghostmansd | FAILED src/openpower/decoder/isa/test_caller_svp64_ldst.py::DecoderTestCase::test_sv_load_dd_ffirst_excl - AssertionError: 2 != 1 | 10:02 |
| ghostmansd | = 2 failed, 349 passed, 75 skipped, 19 xfailed, 748 warnings in 1877.08s (0:31:17) = | 10:02 |
| ghostmansd | Seems like the same as for master | 10:02 |
| ghostmansd | Merging? | 10:03 |
| lkcl | go for it | 10:03 |
| programmerjake | hopefully much faster than how long you've taken to fix test_sv_load_dd_ffirst_excl | 10:03 |
| programmerjake | thx ghostmansd! | 10:03 |
| ghostmansd | thanks to you, actually :-) | 10:04 |
| ghostmansd | my job was quite a simple one | 10:04 |
| lkcl | yes i know. that's a significant intrusive change in ISACaller which i'm... how-to-say-delicately... "working up the energy to tackle" | 10:04 |
| lkcl | VLi=0 the load or store must *not* actually happen | 10:05 |
| ghostmansd | bringing the CI is a real job and time-saver | 10:05 |
| ghostmansd | pushed to master | 10:05 |
| ghostmansd | now I can update binutils | 10:05 |
| lkcl | but in the case of a load it does have to happen but just not actually go into the register | 10:05 |
| lkcl | i.e. you read the data from memory, then test it | 10:05 |
| ghostmansd | for the record, we also have setvl affected by the same issue | 10:05 |
| ghostmansd | so I'll update it too | 10:06 |
| lkcl | if the test fails you must not actually store in RT. | 10:06 |
| lkcl | ghostmansd, yes please, but watch out for unit tests on that one... oh wait... hang on... | 10:06 |
| lkcl | in setvl it does things slightly differently | 10:06 |
| ghostmansd | lkcl, I mean updating setvl in binutils | 10:06 |
| lkcl | the pseudocode actually looks at the contents of RA (the 5-bit) by itself | 10:07 |
| lkcl | ahhh | 10:07 |
| ghostmansd | nothing to be changed for openpower-isa | 10:07 |
| ghostmansd | it's just binutils having RA instead of RA0 | 10:07 |
| ghostmansd | for minmax, both code bases were incorrect | 10:07 |
| ghostmansd | for setvl, only binutils's the sucker | 10:07 |
| programmerjake | well, as i recommended before: all element ops that succeed should always write all their outputs, all that VLi=0 should do is adjust VL *after* that element writes to RT | 10:07 |
| lkcl | no. | 10:07 |
| lkcl | that's VLi=1 mode | 10:08 |
| lkcl | what you've described as "recommended" is exactly what VLi=1 is for | 10:08 |
| lkcl | VLi=0 is, by definition, "all elements that succeed on a test" | 10:09 |
| lkcl | VLi=1 is, by definition, "all elements tested" | 10:09 |
| programmerjake | well, icr the polarity of VLi but i mean the one that ends up with VL=<index-of-last-successful-op> rather than VL=1+<index-of-last-successful-op> | 10:09 |
| lkcl | you're asking for VLi=0 to be defined as being "identical to VLi=1" | 10:10 |
| lkcl | i.e. make it pointless | 10:10 |
| lkcl | and that in turn destroys key functionality | 10:10 |
| programmerjake | no, i'm asking for VLi=0 to be defined as identical to VLi=1 except afterwards it subtracts one from VL | 10:11 |
| lkcl | no. not happening | 10:11 |
| lkcl | LD/ST is a special case that needs a little more thought to implement | 10:11 |
| programmerjake | *not*: runs last op then tests results and proceeds to not write them | 10:11 |
| lkcl | Arithmetic/Logical/CR-ops VLi=0/1 is perfectly fine and logical | 10:12 |
| lkcl | the answer is no and that was final the last time you raised this. | 10:12 |
| lkcl | ghostmansd, am re-running the unit tests locally to double-check | 10:13 |
| ghostmansd | https://salsa.debian.org/Kazan-team/mirrors/openpower-isa/-/jobs/4194582 | 10:13 |
| ghostmansd | For the record, I've been looking at this job on CI | 10:13 |
| programmerjake | if a load page-faults, then it *failed* hence shouldn't write RT. if a load reads a zero, it *succeeded* and should write RT=0, but changing VL -= 1 is still useful | 10:13 |
| lkcl | ah you are confusing page-fault with data-dependent-fail-first | 10:14 |
| lkcl | please do read the specification. | 10:14 |
| lkcl | it is slightly alarming the number of times i have had to ask you to do that (read the specification) | 10:14 |
| lkcl | https://libre-soc.org/openpower/sv/ldst/ | 10:14 |
| lkcl | sections 1.6 and 1.7 | 10:15 |
| programmerjake | well, you said reads 0 then proceeds to not write it, which sounds like data-dependent-fail-first to me | 10:15 |
| lkcl | yes. | 10:15 |
| lkcl | that's *not* the same as a page-fault. | 10:15 |
| lkcl | DD-ffirst is the *actual data returned by the load* | 10:16 |
| lkcl | whereas fault-first is whether the underlying hardware caused a LD/ST-related excception that *prevented* the actual data from *being* returned | 10:16 |
| lkcl | it's explained very clearly in the specification | 10:17 |
| programmerjake | well, imho, for ddff, that's wrong...the load succeeded, so it should succeed 100% including writing registers...it just returned 0 so future element ops aren't run | 10:17 |
| lkcl | no it should not. | 10:17 |
| programmerjake | for avoid-page-fault fail-first, not writing is 100% logical | 10:17 |
| lkcl | the load succeeded *and if VLi=1* the write to the registers should be performed | 10:17 |
| programmerjake | well, i disagree | 10:18 |
| lkcl | but if the load succeeded *and if VLI=0* then if the test **OF THE DATA LOADED** fails the test this should **NOT** proceed | 10:18 |
| lkcl | that's because you don't understand it. | 10:18 |
| programmerjake | it unnecessarily makes element ops a bit more complex | 10:18 |
| lkcl | please take the time to ask the questions "why is this necessary, what have i missed?" | 10:19 |
| lkcl | DD-FF gates whether the *write to the regfile* takes place | 10:19 |
| lkcl | not whether the entire operation should, as an atomic entity, take place in its entirety yes or no | 10:20 |
| programmerjake | i understand how you designed it, i just think you designed it in a way that makes it unnecessarily more complex | 10:20 |
| lkcl | that's VLi=1 | 10:20 |
| lkcl | it's very simple to implement. | 10:20 |
| lkcl | an OoO Micro-Architecture simply inserts the DD-FF testing in as a Shadow Hold on the write operation | 10:20 |
| lkcl | just like on predication | 10:20 |
| lkcl | and branches | 10:20 |
| lkcl | and exceptions | 10:20 |
| lkcl | and interrupts | 10:21 |
| lkcl | so in hardware terms it is very simply exploiting pre-existing hardware that you absolutely have to have anyway | 10:21 |
| lkcl | but that also tells you why it exists: it stops the *write to regfile* from happening | 10:22 |
| lkcl | not | 10:22 |
| lkcl | stops the entire operation from happening | 10:22 |
| lkcl | you're thinking as a software developer in terms of "this instruction is atomic", not in terms of a hardware architect | 10:22 |
| lkcl | the difference is huge. in terms of say FP exceptions, anything that overflows can be prohibited from damaging the regfile | 10:23 |
| programmerjake | well, imho stopping the write isn't super useful in sw, what is the useful part is adjusting VL down by one | 10:23 |
| lkcl | i just literally described a use-case where that opinion is invalid. it was crossover though | 10:24 |
| lkcl | to continue | 10:24 |
| lkcl | if you are forced to detect the overflow within a hot-loop it reduces the performance of the hot-loop | 10:24 |
| ghostmansd | lkcl, is the test OK? | 10:25 |
| lkcl | whereas if instead VLi=0 stops the damage to the regfile from occurring, but provides a "notice" at least (if Rc=1), then a special branch to overflow-handling-scenario code can be performed | 10:25 |
| lkcl | ghostmansd, 76% completed | 10:25 |
| ghostmansd | can I remove remote minmax_ra0 branch? | 10:25 |
| ghostmansd | Aha, staying tuned, please ping me when it's completed | 10:26 |
| lkcl | ghostmansd, might as well, i'm just being cautious | 10:26 |
| lkcl | the reduction in instruction count is quite significant | 10:26 |
| ghostmansd | that's perfectly reasonable | 10:26 |
| programmerjake | well, for strcat-like things, we specifically want the write to occur to write the nul, but we don't want VL to include the nil... | 10:27 |
| lkcl | oh - *and* there are scenarios where VLI=1 are also necessary, such as linked-list-pointer-chasing as well as strncpy | 10:27 |
| lkcl | that's taken care of by following up with an sv.cmpi. please read the strncpy example and take the time to understand it | 10:28 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/test_caller_svp64_ldst.py;h=a54ada320bce720a0de9cd566f9e023412df5909;hb=c44cd164b385a18fb635e7087c2a253c30d9c81c#l41 | 10:28 |
| programmerjake | where you have strcat followed by something that needs to operate on the non-zero bytes | 10:28 |
| lkcl | programmerjake, taken care of already | 10:28 |
| lkcl | 50 "sv.cmpi/ff=eq/vli *0,1,*16,0", # compare against zero, truncate VL | 10:29 |
| lkcl | but yes, making absolutely sure that all use-cases are covered is part of the NGI Search grant responsibility | 10:30 |
| programmerjake | actually, the fail-first needs to be on the load, since the code you have rn will read out of bounds | 10:30 |
| lkcl | hope like hell it's all good | 10:30 |
| programmerjake | cmpi after reading out of bounds is still reading out of bounds | 10:31 |
| lkcl | it can't read out of bounds | 10:31 |
| lkcl | it can only test from 0..VL-1 | 10:31 |
| programmerjake | but VL-1 may be beyond the bounds of the input str, reading out of bounds with the sv.lbzu/pi | 10:32 |
| lkcl | how? the length (VL) is restricted to the bounds (n) | 10:33 |
| programmerjake | so imho that example is broken when you can have page faults and sigsegv for reading beyond the terminating nul byte | 10:33 |
| lkcl | (using CTR) | 10:33 |
| lkcl | wait | 10:33 |
| lkcl | you're again confusing page-faults (LD/ST-**FAULT**-First) | 10:33 |
| lkcl | with **DATA**-dependent Fail-First | 10:34 |
| programmerjake | strncpy just guarantees the output is valid for n, the input may be shorter | 10:34 |
| lkcl | please READ the specification. | 10:34 |
| lkcl | and come back to me with a summary of what you have read | 10:34 |
| lkcl | section 1.6 and 1.7 | 10:34 |
| programmerjake | when the input is shorter, that sv.lbzu/pi *will* read beyond the input, because it isn't a page-failt-avoiding fail-first | 10:34 |
| lkcl | no it will not, because VL will have by that point been reduced down | 10:35 |
| lkcl | ghostmansd, all good | 10:35 |
| lkcl | 41 "mtspr 9, 3", # move r3 to CTR | 10:35 |
| lkcl | 61 "sv.bc 16, *0, -0xc", # decrement CTR by VL, stop at zero | 10:35 |
| ghostmansd | Perfect! | 10:35 |
| programmerjake | where, the ddff is *after* the load | 10:35 |
| lkcl | yes it is. | 10:36 |
| ghostmansd | I was afraid I'll have to update this comment: https://bugs.libre-soc.org/show_bug.cgi?id=910#c8 | 10:36 |
| lkcl | and VL will be within bounds on the LD | 10:36 |
| lkcl | as defined by CTR | 10:36 |
| lkcl | it's good that you're checking because this does need checking | 10:37 |
| programmerjake | no it won't, because VL/CTR is set by the output length, strncpy doesn't know the input length until it reads the terminating nul | 10:37 |
| programmerjake | and since that load isn't ffirst it will read past the nul | 10:38 |
| lkcl | ahh ok so a difference between input-length (implicit) and output-length (n) | 10:38 |
| programmerjake | this is before it goes around the loop even once | 10:38 |
| lkcl | yes it will read past the nul, and that then allows the sv.cmpi to perform the test | 10:38 |
| lkcl | but it will *not* overrun the *output* length, which is critically important | 10:39 |
| lkcl | so the stbu does not result in data-corruption | 10:39 |
| programmerjake | no, it'll read past the nul and segfault, not even getting to the cmpi, when the nul is right before an unmapped page | 10:39 |
| lkcl | no, it will *not* read past the nul and segfault. | 10:40 |
| lkcl | that is prevented by *LD-Fault-First*. | 10:40 |
| lkcl | please for goodness sake for the third time *read the spec* | 10:40 |
| programmerjake | why? it is *not* ld-fault-first | 10:40 |
| programmerjake | it's just plain ld | 10:40 |
| lkcl | (i realise i haven't set it to /ff because there's no actual way to test LD/ST-faulting in the simulator) | 10:41 |
| lkcl | (ISACaller doesn't actually have /lf - sorry not /ff) | 10:41 |
| programmerjake | ah, so that's why | 10:41 |
| programmerjake | unimplemented :) | 10:42 |
| lkcl | indeed. so much to do, sigh :) | 10:42 |
| programmerjake | should probably add a comment that it should be ld-fault-first | 10:42 |
| lkcl | good idea | 10:42 |
| programmerjake | once that's done, we both agree it should work :) | 10:43 |
| lkcl | the problem with implementing Load-Fault is that it requires completely different behaviour from ISACaller in order to accurately test it | 10:45 |
| programmerjake | well, we could fake faults for unittests and implement page-table-walking later... | 10:45 |
| lkcl | oh page-table-walking is already implemented | 10:46 |
| lkcl | i had to add it for testing against microwatt-linux-5.7 | 10:46 |
| programmerjake | e.g. add: if addr not in defined_addresses: return page_fault() | 10:46 |
| lkcl | and the mmu.bin microwatt unit test | 10:46 |
| *** ghostmansd <ghostmansd!~ghostmans@91.205.168.99> has quit IRC | 10:46 | |
| lkcl | which is behaviour that needs to be added as options to ISACaller at startup | 10:47 |
| lkcl | "force-an-exception-if-a-load-or-store" occurs is a good way to do it, tbh | 10:48 |
| lkcl | as a new option to ISACaller constructor | 10:48 |
| lkcl | i need breakfast. | 10:48 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@91.205.168.99> has quit IRC | 11:04 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@91.205.168.99> has joined #libre-soc | 11:05 | |
| programmerjake | oh, btw, "add stub reset_xflags function" -- no point, the pseudocode uses like a dozen new functions, just wait till i implement them | 11:07 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@91.205.168.99> has quit IRC | 12:41 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.54.10> has joined #libre-soc | 12:44 | |
| *** choozy <choozy!~choozy@75-63-174-82.ftth.glasoperator.nl> has joined #libre-soc | 13:06 | |
| *** octavius <octavius!~octavius@92.40.168.80.threembb.co.uk> has joined #libre-soc | 14:35 | |
| octavius | lkcl, sorry for the lack of communication recently, been busy with other things. Looking at the microwatt sim today, and I forgot to mention the trace waveform file. | 14:42 |
| octavius | In the makefile, --trace flag passed in to generate the VCD trace file. | 14:42 |
| octavius | In the microwatt-verilator.cpp, the if VM_TRACE variable is defined, the trace file *should be* updated twice per clock cycle, and the setup code resembles the example in the Verilator manual (section "How do I generate waveforms (traces) in C++?"). | 14:42 |
| octavius | The issue I'm seeing is that the 'microwatt-verilator.vcd' file is created when the microwatt-verilator is first run, but afterwards it is not updated. Converting this empty vcd file to fst and viewing in gtkwave shows only the state of signals at time 0. | 14:42 |
| octavius | What I'm expecting instead, is for it to update as the simulation runs. | 14:42 |
| octavius | Have I missed something? I haven't passed any flags to the microwatt-verilator binary (other than the hello_world.bin to load). | 14:42 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.54.10> has quit IRC | 15:13 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@91.205.168.99> has joined #libre-soc | 15:14 | |
| lkcl | octavius, you have to wait for a file-flush | 16:20 |
| lkcl | and/or pass in options to have verilator write out with fsync. | 16:20 |
| lkcl | you'll need to look up the manual. | 16:20 |
| lkcl | and/or as usual ask around on the interwebs | 16:21 |
| octavius | Ok, then I'll leave it out of the tutorial for now. I was also able to run micropython. | 16:23 |
| lkcl | awesome! it's a little slow isn't it but functional | 16:26 |
| lkcl | hmmm... creating vcd traces is kinda important | 16:27 |
| lkcl | i have vague recollections of leaving things running for several minutes | 16:27 |
| lkcl | then getting bored and looking up the verilator compile-time options to write out trace files more frequently | 16:27 |
| *** tplaten <tplaten!~tplaten@195.52.25.107> has joined #libre-soc | 16:38 | |
| octavius | "creating vcd traces is kinda important", yeah, you're right. I'm looking through some tutorials | 16:44 |
| octavius | The wiki page is starting to look more comprehensive: | 16:45 |
| octavius | https://libre-soc.org/HDL_workflow/microwatt_tutorial/ | 16:45 |
| octavius | If you want, I can join some of this back to the original page. The reason I made a new one is just to focus on microwatt only (so the user sanitises the flow first) | 16:45 |
| *** octavius <octavius!~octavius@92.40.168.80.threembb.co.uk> has quit IRC | 17:15 | |
| tplaten | status update: currently reading https://libre-soc.org/openpower/sv | 17:52 |
| *** choozy_ <choozy_!~choozy@75-63-174-82.ftth.glasoperator.nl> has joined #libre-soc | 18:08 | |
| *** choozy <choozy!~choozy@75-63-174-82.ftth.glasoperator.nl> has quit IRC | 18:14 | |
| lkcl | tplaten, the PDF version may be easier but ultimately it's the same thing | 18:55 |
| lkcl | https://ftp.libre-soc.org/simple_v_spec.pdf | 18:55 |
| lkcl | although a couple (new) pages need adding. | 18:55 |
| lkcl | octavius: merging it back is better, as it's effectively a duplicate (and therefore a maintenance headache) | 18:57 |
| lkcl | as a general rule if there's an existing page please don't duplicate it | 18:57 |
| tplaten | 433 pages | 19:07 |
| tplaten | going to have first look tomorrow | 19:56 |
| *** tplaten <tplaten!~tplaten@195.52.25.107> has quit IRC | 20:14 | |
| ghostmansd[m] | tplaten, there's an unreplied email about binutils. Looking forward to get an answer. | 20:51 |
| markos_ | ghostmansd[m], he did send to the list that there was a bounced mail to you | 21:15 |
| markos_ | also got an error sending a mail to | 21:15 |
| markos_ | <ghostmansd@gmail.com>: host gmail-smtp-in.l.google.com[64.233.167.27] | 21:15 |
| markos_ | said: | 21:15 |
| markos_ | 550-5.7.26 This mail is unauthenticated, .......... | 21:15 |
| markos_ | So I'll use the mailing list or the chat instead | 21:15 |
| ghostmansd[m] | WAT | 21:16 |
| ghostmansd[m] | Does it happen on the direct mail? | 21:16 |
| markos_ | no idea, I can send a test mail to you if you like | 21:16 |
| ghostmansd[m] | I've never met this thing before. What does it even mean, bounced email? | 21:17 |
| markos_ | well, error, 550 means the user was unreachable/wrong mailbox | 21:17 |
| markos_ | bounced mail is something else | 21:17 |
| markos_ | means that the server is unreachable so the mail could not be delivered to the server -because of server being temporary offline, but that does not mean the mail is wrong/non-existent | 21:18 |
| markos_ | this definitely reached the server, but was rejected | 21:18 |
| ghostmansd[m] | Hm. Perhaps this is caused by the fact that my email is in fact ghostman.sd, not ghostmansd? But these are the same in Gmail. | 21:18 |
| ghostmansd[m] | And I always use undotted form | 21:18 |
| markos_ | just sent a test mail to this address | 21:19 |
| ghostmansd[m] | markos, I got it :-) | 21:19 |
| markos_ | not from a gmail account | 21:19 |
| markos_ | ok so the mail works | 21:19 |
| ghostmansd[m] | subj is test mail | 21:19 |
| markos_ | yup | 21:19 |
| ghostmansd[m] | Hm. Pretty damn strange. | 21:19 |
| ghostmansd[m] | Ok so Tobias replied somewhere? | 21:20 |
| markos_ | so something on tplaten's message | 21:20 |
| markos_ | tell you what, I'm going to forward his mail to both of you | 21:20 |
| markos_ | btw, are you subscribed to the list? | 21:21 |
| ghostmansd[m] | Ok, ping me after you send it :-) | 21:21 |
| ghostmansd[m] | Not sure which one you mean | 21:21 |
| markos_ | you should be, fwiw, it's not that heavy traffic | 21:21 |
| ghostmansd[m] | libresoc? | 21:21 |
| markos_ | libresoc-dev | 21:21 |
| markos_ | actually libre-soc-dev | 21:22 |
| ghostmansd[m] | Yes, I think so | 21:22 |
| ghostmansd[m] | At least I sometimes get updates on the project | 21:22 |
| markos_ | sent | 21:22 |
| ghostmansd[m] | For today I have a message from Tobias about daily kan-ban for 07 May | 21:23 |
| markos_ | that's the one :) | 21:23 |
| markos_ | that's where I copied the text from :) | 21:24 |
| ghostmansd[m] | Ah OK | 21:24 |
| ghostmansd[m] | That's the one I missed | 21:24 |
| ghostmansd[m] | I assumed I'd get some reply in the chain where I raised the question :-) | 21:24 |
| markos_ | well, now that I've restablished comms, I can quietly disappear in the background :) | 21:26 |
| ghostmansd[m] | Thank you :-D | 21:30 |
| ghostmansd[m] | The reason I'm somewhat curious is that I've been developing this, I guess, for a year or so already, and I need to at least be aware of what Tobias is going to show or present | 21:31 |
| *** choozy_ <choozy_!~choozy@75-63-174-82.ftth.glasoperator.nl> has quit IRC | 23:57 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!