| *** Ultrasauce is now known as sauce | 02:54 | |
| Veera[m] | programmerjake: shall I update the script hdl-tools-yosys with support for cvc5 and smtlib2. Whether new bug to be opened or to report it in #835. Also yosys-0.13 is to be used with them or your provided link page versions (CI) to be used. | 03:15 |
|---|---|---|
| programmerjake | the versions to use for now are the ones in the gitlab-ci file in the build_on_yosys_smtlib2-expr-support-on-0.13 section -- do note that the sby commit there is missing some other stuff needed, it works for ci but will probably not work for other libre-soc projects. I'm waiting on the sby PR to be merged | 03:18 |
| programmerjake | so, imho it would be best to wait for that sby PR to be merged since then we can actually use sby master rather than having to make our own fork that merges both the stuff from that PR that hasn't yet been merged and from a different independent PR that already was merged. | 03:20 |
| programmerjake | PR to wait for: https://github.com/YosysHQ/sby/pull/170 | 03:20 |
| programmerjake | other PR: https://github.com/YosysHQ/sby/pull/161 | 03:21 |
| programmerjake | actually, now that I look at it, maybe it wasn't that one, but another PR...icr. i remember I was waiting on something though rather than just using the commit in #170 | 03:21 |
| programmerjake | since the commits in #170 don't include something that was already merged in sby master that iirc we need. | 03:22 |
| programmerjake | so, sorry, but I think we should just wait | 03:23 |
| Veera[m] | ok. | 03:26 |
| programmerjake | sorry for wasting your time | 03:27 |
| Veera[m] | not | 03:29 |
| lkcl | programmerjake, can i suggest to keep track of the PRs in the bugreport? | 08:43 |
| lkcl | but, also, if that takes too long we have to bear in mind that there's only 3 months left | 08:43 |
| lkcl | you cannot wait 2-3 weeks for a team outside of our control to react | 08:43 |
| lkcl | if we have to make a temporary fork of sby then we make a temporary fork of sby | 08:44 |
| programmerjake | I added it to the top comment. | 08:45 |
| lkcl | magic | 08:45 |
| programmerjake | we can just create a task for writing everything, and move all the funding to that one, that way getting paid doesn't need to wait on the PR | 08:46 |
| programmerjake | I'll keep waiting a bit tho | 08:46 |
| lkcl | yep good idea | 08:47 |
| programmerjake | if they haven't merged the PR by next week, we can think about making our own temporary sby fork then | 08:47 |
| lkcl | i've just created a repo anyway, which will help solve the stability issue | 08:48 |
| lkcl | dang the moving targets are creating a mess | 08:48 |
| lkcl | should have caught that a long time ago and used a git tag for everything | 08:48 |
| programmerjake | I'm brain-dead, icr what stability issue you mean | 08:48 |
| lkcl | :) dev-env-setup scripts breaking | 08:49 |
| programmerjake | oh... | 08:49 |
| programmerjake | imho if you change it to a tag or commit hash, using the upstream repo should still be fine...we can reasonably expect they won't move tags or delete commits | 08:50 |
| lkcl | which one's the yosys git repo needed? https://git.libre-soc.org/?p=yosys.git;a=summary | 08:50 |
| programmerjake | the git branch I'm using for yosys 0.13 is smtlib2-expr-support-on-0.13 | 08:52 |
| lkcl | ok | 08:52 |
| programmerjake | everything I submitted was merged upstream, so when we move off 0.13 it should all be there | 08:53 |
| programmerjake | for yosys at least | 08:53 |
| lkcl | not yosys-0.13-with-write_jny | 08:53 |
| programmerjake | yosys-0.13-with-write_jny is the tag for the 0.13 branch with stuff cherrypicked from upstream...before I added any of the smtlib2 stuff | 08:54 |
| programmerjake | basically I cherrypicked all the commits I needed to get nmigen tests to pass | 08:55 |
| lkcl | ahh ok | 08:55 |
| programmerjake | mostly just write_jny, but there are a few misc commits too | 08:55 |
| lkcl | frickin lot of work, sigh | 08:55 |
| lkcl | ok i'm re-running hdl-tools-yosys to make sure it's all good | 08:56 |
| lkcl | there's an msc student from the openpower academic group who's been very kindly tasked with checking that ls180 can be synthesised to GDS-II files with Cadence VLSI tools | 08:57 |
| programmerjake | well...speaking of a lot of work, i'm working on adding unsubscribe links to the build emails...discovered ssh-keygen can be used for signing and verifying files, so I'm using that for url signatures since it's likely to be done correctly and it's waay easier to use than installing openssl 3.0 so I can use and verify hmacs | 08:57 |
| lkcl | !! | 08:58 |
| programmerjake | what fun!!! about as much fun as breaking your arm | 08:58 |
| lkcl | it's USD 90 million worth of tools they've access to | 08:58 |
| programmerjake | it's interesting and useful but sounds like a total pain to get working | 08:59 |
| lkcl | and it's also highly significant: we'd be able to say that ls180 is synthesisable on much lower geometries than 180nm | 08:59 |
| programmerjake | that depends on if they're using much lower geometries or not... | 08:59 |
| lkcl | well, they've experience in dealing with that | 08:59 |
| lkcl | the tools don't care what you end up using | 09:00 |
| lkcl | they have access to the PDKs, they can run the synthesis and the DRC at those lower geometries | 09:00 |
| lkcl | without actually submitting to a Foundry | 09:00 |
| lkcl | the absolutely crucial bit of information for us is, "did it pass DRC" | 09:00 |
| lkcl | i'm going to ask Veera to add cvc5 to hdl-tools-yosys anyway. hmm under a separate bugreport. | 09:02 |
| programmerjake | ok, I'd recommend using the build instructions in the gitlab-ci file...iirc cvc5 needs java to build | 09:02 |
| lkcl | urrr fer f***'s sake. sigh | 09:03 |
| lkcl | whyyyyy | 09:03 |
| lkcl | :) | 09:03 |
| lkcl | no don't answer that lol | 09:03 |
| programmerjake | they use it for their parser generator | 09:03 |
| lkcl | ohh antlr most likely | 09:03 |
| programmerjake | yeah, antlr3 | 09:03 |
| lkcl | it's quite popular. | 09:04 |
| programmerjake | I've used it before, it's relatively nice | 09:04 |
| lkcl | there's a debian package for antlr3. | 09:05 |
| programmerjake | though I ended up switching to a packrat parser generator I wrote for some stuff, and just writing custom recursive-descent parsers for the rest | 09:05 |
| programmerjake | I tried installing the debian package, it ignores it | 09:05 |
| lkcl | nggh they need antlr3.4 | 09:05 |
| lkcl | yyep, debian has antlr3.2 sigh | 09:05 |
| lkcl | https://github.com/cvc5/cvc5/blob/main/INSTALL.rst | 09:05 |
| lkcl | ah well | 09:06 |
| * lkcl need to get up and go walk round the garden | 09:06 | |
| programmerjake | https://github.com/programmerjake/peg_parser_generator | 09:06 |
| programmerjake | eclipse integration for that parser generator I wrote: https://github.com/programmerjake/peg_parser_generator-eclipse | 09:07 |
| programmerjake | example grammar: https://github.com/programmerjake/peg_parser_generator/blob/master/test.peg | 09:08 |
| lkcl | oo bnf-like grammar, ooo | 09:10 |
| programmerjake | it actually uses something that imho is better than bnf: https://en.wikipedia.org/wiki/Parsing_expression_grammar | 09:11 |
| lkcl | it reminds me of yacc/bison | 09:11 |
| lkcl | ordered choices. interesting | 09:12 |
| programmerjake | the idea is it's never ambiguous | 09:12 |
| lkcl | i'm supposed to be afk in the garden! :) | 09:12 |
| programmerjake | well, I'm done for the day, gn | 09:54 |
| lkcl | night jacob | 09:55 |
| lkcl | cesar, i just emailed you about some RFPs for you. there are three, they each need their own separate email and separate subject-line! | 13:20 |
| lkcl | because they are three separate NLnet projects. | 13:20 |
| cesar | Amazing, thanks! I'll get to it, and send you the drafts. | 13:28 |
| openpowerbot | [mattermost] <lkcl> magic. it's almost EUR 5,000 for you - you did most of the work on TestIssuer's SV FSM so i found a budget for that | 13:29 |
| octavius | Apologies for being quiet, been studying and writing. Currently I'm comparing the SIMD and vector topologies. | 15:27 |
| octavius | From my current understanding, a vector architecture is sort of like a block of memory where VL determines how much of this memory the instruction will use, right? | 15:27 |
| octavius | Whereas SIMD has predefined register lengths, and thus you will need to regularly move data to/from main memory (or cache) if you code has more elements than a SIMD register can store. | 15:27 |
| octavius | *your code | 15:27 |
| lkcl | "block of memory" --> "block of register elements"... but yes | 15:30 |
| octavius | Ah ok | 15:31 |
| lkcl | Vectors -> variable-length blocks of register elements | 15:31 |
| lkcl | SIMD -> fixed-length blocks of register elements | 15:32 |
| lkcl | the problem with SIMD should be pretty damn obvious, if the SIMD fixed width is 16 elements, then how are you going to process only 15 elements? or 17? | 15:33 |
| lkcl | SIMD ISAs "solve" that as follows: | 15:33 |
| lkcl | * add an extra SIMD instruction to do 8 elements | 15:34 |
| lkcl | * add another to do 4 | 15:34 |
| lkcl | * add another to do 2 | 15:34 |
| lkcl | then you do a binary-calculation with branches, subtracting the number that you've covered, 8+4+2+1 | 15:34 |
| lkcl | and that way in a pre-preparation step with an *identical copy* of the entire inner loop of the algorithm, you | 15:35 |
| lkcl | [optionally] do 8 elements | 15:35 |
| lkcl | [optionally] do 4 elements | 15:35 |
| lkcl | [optionally] do 2 elements | 15:35 |
| lkcl | [optionally] do 1 element | 15:35 |
| lkcl | ohhh nooow we have rounded up to 16 elements, | 15:35 |
| lkcl | noooow we can do the 16-way SIMD inner loop | 15:36 |
| lkcl | (we're up to FIVE copies of the entire inner loop algorithm so far...) | 15:36 |
| lkcl | when i said last night that that sigarch "simd considered harmful" article massively understated things, it was because they deliberately only chose AVX-2 | 15:37 |
| lkcl | (and for MIPS, only the 2-wide SIMD) | 15:37 |
| lkcl | if they'd attempted to demonstrate with AVX-256 they'd have literally had to have written assembler code longer than the entire article | 15:38 |
| lkcl | bottom line is, it's kinda astounding that nobody has noticed how bad SIMD really is | 15:38 |
| lkcl | they just "put up with it" in a resigned fashion | 15:38 |
| octavius | That's insane :'( | 15:57 |
| octavius | So ifSo if for example I'm to add two vectors of length 15, vec(A) + vec(B). | 16:07 |
| octavius | SIMD has to generate 8-element SIMD, then 4-element, then 2, then 1. | 16:07 |
| octavius | Then the results are written into memory? Surely you don't need to do any more computation than that? | 16:07 |
| programmerjake | lkcl: please check https://bugs.libre-soc.org/show_bug.cgi?id=469#c45 | 16:10 |
| lkcl | programmerjake, ack | 16:13 |
| programmerjake | this too: https://bugs.libre-soc.org/show_bug.cgi?id=469#c45 | 16:14 |
| lkcl | responding, 1 sec, in the middle of something | 16:19 |
| octavius | I need to go, will be back in a few hours, no rush | 16:20 |
| ghostmansd | folks could you remind me a command to launch all tests for openpower-isa? | 16:27 |
| ghostmansd | I'm changing svp64py again, and don't want to break it like previously | 16:27 |
| lkcl | ghostmansd, lol | 16:31 |
| lkcl | mmm.... 1 sec... | 16:31 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=tree;f=src/openpower/decoder/isa;hb=HEAD | 16:32 |
| lkcl | any of those starting "test_caller_svp64" should do it | 16:32 |
| lkcl | ghostmansd, btw, you might have noticed, the entire meeting yesterday went completely off-agenda, but in a good way | 16:45 |
| lkcl | i found it funny, i explained to you privately how i was expecting it to go, blah blah, and we got thrown a curve-ball on limited time :) | 16:47 |
| ghostmansd | yeah I was also somewhat surprised, since I even should've taken part in agenda dedicated to binutils works :-) | 17:03 |
| ghostmansd | still it was a nice discussion | 17:03 |
| ghostmansd | OK I'll check test_caller_svp64 tests | 17:04 |
| lkcl | ghostmansd, oh fer god's sake :) https://bugs.libre-soc.org/show_bug.cgi?id=723 | 18:00 |
| lkcl | ya put a EUR 50 cents into a bugreport :) | 18:01 |
| lkcl | too late now because you've put in the RFP: do try to round things up to at least EUR 5 preferably 10 :) | 18:01 |
| lkcl | Veera[m], i added those 2 extra images, they're quite simple https://bugs.libre-soc.org/show_bug.cgi?id=839 | 18:02 |
| ghostmansd | lkcl, by the way I even had to ask here how to do it lol :-D | 18:33 |
| ghostmansd | and programmerjake explained that I had to do it a string! | 18:34 |
| ghostmansd | I don't remember why it was this way, perhaps I understood this 15 percent way too literally | 18:35 |
| ghostmansd | Ahem... Would it be way too much if the objdump "etalon" to be compared in test takes 2400+ lines?... Same for the assembler listing which is used as an input before being fed into binutils. | 18:38 |
| ghostmansd | https://pastebin.com/sQYfvnEx | 18:39 |
| ghostmansd | I guess binutils maintainers would beat the crap out of me. Also, on second thought, there's no need for this comparison to take place, eh? | 18:39 |
| programmerjake | ah, because python floats don't represent decimals exactly, so you need a string so the toml parser doesn't use a python float...cuz money needs to have exact arithmetic | 18:40 |
| ghostmansd | What'd be the canonical way to check each of these only once? I mean, I don't really bother how the insn would look like. I simply wanted to check some corner cases but keep assembly listing (and the corresponding dump) minimalistic. | 18:41 |
| ghostmansd | I think there must be something in itertools... | 18:41 |
| ghostmansd | I mean, this is OK to commit, it covers many cases well. But hell, post it on mailing list... | 18:43 |
| ghostmansd | Whoa 10420 lines for svremap... Way too long. | 19:32 |
| ghostmansd[m] | Ok, all done, but, as I mentioned, patches will be way too large. Any ideas? | 20:18 |
| ghostmansd[m] | On the other hand, this checks operands together, so perhaps this is good thing after all. | 20:25 |
| octavius | What does the "P64" in SVP64 mean? | 22:22 |
| octavius | I guess SVP64 is the same as SV (Simple Vectorisation)? | 22:22 |
| programmerjake | prefix 64-bit because the prefixed instructions are 64-bit in size | 22:25 |
| programmerjake | the idea is there may be a different instruction format and the P64 is needed to differentiate them...originally we were planning on having 16-bit instructions where the sv data was specified as part of a separate instruction that set the sv data for the next few instructions...that has stalled/been dropped | 22:28 |
| programmerjake | back when we were using risc-v instead of openpower, the format was called svp48 because it was a 16-bit prefix on a 32-bit instruction, giving a 48-bit instruction | 22:30 |
| octavius | Ah ok, thanks Jacob! | 22:52 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!