| Veera[m] | <lkcl> "if you can re-run it, in a new..." <- I will use hdl-yosys-tools; and rerun in a new chroot and adjust script accordingly. | 00:00 |
|---|---|---|
| programmerjake | removing xdot and graphviz from the apt install line reduced nmigen-gf's CI time from 11:37 to 8:42 | 00:49 |
| programmerjake | @lkcl, i already removed xdot and graphviz before you responded ^ | 01:25 |
| lkcl | programmerjake, that's not surprising | 09:42 |
| lkcl | Veera[m], Erik approved your account access to Silicon Server | 10:04 |
| lkcl | also the other server is one i've heard about which apparently has these absolutely monstrous FPGAs, 1 million LUT4s, with 25 gigabit SERDES | 10:04 |
| lkcl | they're intended for OpenCAPI testing apparently | 10:04 |
| lkcl | they're not even available for sale | 10:04 |
| Veera[m] | Yeah. I read my mail earlier about this. I may try after sometime. | 10:16 |
| lkcl | do say thank you to them! | 11:29 |
| lkcl | programmerjake, i have a sneaking intuitive feeling you might find RippleLSB useful instead of attempting to use an adder and assuming that yosys will remove the XORs | 11:39 |
| lkcl | https://git.libre-soc.org/?p=nmutil.git;a=blob;f=src/nmutil/ripple.py;hb=HEAD | 11:39 |
| lkcl | generally it's not a good idea to rely on yosys: it's an external tool that could end up changing and be utterly broken | 11:40 |
| lkcl | forcing us to have to critically rely on either patches or a fixed version | 11:40 |
| lkcl | which in turn has serious consequences if there are two "fixes", both in different versions of yosys, that we then have to forward-port | 11:41 |
| lkcl | all-round maintenance nightmare in other words | 11:41 |
| lkcl | https://www.linkedin.com/posts/lkclnet_inspiration-leadership-activity-6875068528232333312-Jl3w?utm_source=linkedin_share&utm_medium=member_desktop_web | 13:12 |
| lkcl | toshywoshy, Veera[m] got the nextpnr-xilinx auto-install set up, you should be able to build ls2 for the arty-a7 (you bought one, right?) | 13:24 |
| lkcl | markos, it'd be interesting to hear how you get on with the nexys_video board on that score. we'll have to add the xc7-200t to the list of binaries/databases though | 13:25 |
| lkcl | programmerjake, nmutil is definitely the right place to put clmul, it's that ridiculously common | 13:27 |
| markos | haven't got it yet | 13:27 |
| lkcl | it does however need work: removing BitwiseXorReduce and replacing it with the one-line nmutil.utils.tree_reduce() function | 13:28 |
| lkcl | markos, be fascinated to know how it works out. nexys4 (or, nexys_video) is supposed to be supported. | 13:29 |
| markos | yeah, I expect to have it early next week | 13:29 |
| markos | at least the board, no idea about hyperram | 13:29 |
| lkcl | https://gitlab.com/nmigen/nmigen-boards/-/blob/master/nmigen_boards/nexys4ddr.py | 13:29 |
| lkcl | need to double-check the schematics to ensure it's the right definitions | 13:30 |
| lkcl | do you know where a PDF is for it? | 13:30 |
| * lkcl starts looking | 13:30 | |
| lkcl | was it this one you got? https://digilent.com/reference/programmable-logic/nexys-4-ddr/start | 13:31 |
| lkcl | hm that's the 100t. you got a 200t didn't you | 13:31 |
| * lkcl goes to grep the irc logs | 13:31 | |
| lkcl | https://www.mouser.co.uk/datasheet/2/690/nexys_video_rm-846323.pdf | 13:34 |
| lkcl | mmm mumble mumble, it'll need a nmigen-boards entry. which won't be hard to do | 13:34 |
| lkcl | they're already defined here https://github.com/litex-hub/litex-boards/blob/master/litex_boards/platforms/digilent_nexys_video.py | 13:36 |
| lkcl | so conversion is dead easy | 13:36 |
| markos | that's the one: https://eu.mouser.com/ProductDetail/424-410-316 | 14:19 |
| lkcl | great, i've recorded the links to everything here https://gitlab.com/nmigen/nmigen-boards/-/issues/1 | 15:25 |
| octavius | Has anyone had an ImportError when testing an nmigen module that uses the GTKWave nmutil functions? Not sure whether this is an issue on my end (wrong pip module perhaps?): "ImportError: cannot import name 'GTKWColor' from 'vcd.gtkw' (/usr/local/lib/python3.7/dist-packages/pyvcd-0.1.7-py3.7.egg/vcd/gtkw.py)" | 16:16 |
| octavius | Actually no, this is a different issue. Commenting out the gtkwave stuff, I now get a ModuleNotFoundError with nmigen.sim | 16:17 |
| octavius | Looks like something's wrong with my modules, or paths | 16:18 |
| markos | lkcl, damn, I forgot to ask, there are 2 hyperram pmods, 64/256MB, which one should I have bought? | 16:47 |
| cesar | octavius: Please update pyvcd. | 16:51 |
| octavius | cesar: this is the one I installed via pip3 "pyvcd-0.1.7-py3.7.egg (0.1.7)" | 16:53 |
| cesar | PyPI site shows there is a 0.3.0 already. | 16:56 |
| cesar | 0.1.7 is likely too old. | 16:56 |
| octavius | Thanks cesar, looks like one of scripts mucked up the version for me, updating works in a new chroot (I should probably get debian instead of devuan on this laptop) | 18:10 |
| programmerjake | > programmerjake, nmutil is definitely the right place to put clmul, it's that ridiculously common | 18:58 |
| programmerjake | then we run into the reference code wiki underlay problem all over again...imho we should leave it in nmigen-gf because it *is* a GF(2)[X] operation. (that syntax means the ring of polynomials with coefficients in GF(2) with the pklynomial's variable being X) | 18:58 |
| programmerjake | lkcl ^ | 19:08 |
| programmerjake | also clrem is nearly just as common...it is the operation used by crcs...clmul is just a fast way of implementing clrem by a constant | 19:11 |
| lkcl | programmerjake, argh yeah i grok that logic. | 20:24 |
| lkcl | annoying sigh | 20:24 |
| lkcl | commit 101f6dfcd0aaa3155f56e2728a0b4b5343bd4dd5 (HEAD -> master, origin/master, origin/HEAD) | 20:27 |
| lkcl | fix code luke broke | 20:27 |
| lkcl | programmerjake, i was going to fix it. i broke it, my responsibility to fix it. | 20:27 |
| lkcl | next time in the commit message do remember to include what was done ("added missing module argument wot luke broke") | 20:28 |
| programmerjake | it's obvious from the diff, i removed the ", m" since m isn't used in the function you added it to | 20:31 |
| lkcl | that was a hint for you to use it to create the temporary Signals() | 20:32 |
| lkcl | https://bugs.libre-soc.org/show_bug.cgi?id=784#c8 | 20:32 |
| lkcl | programmerjake, mmmm.... you're right about Ripple(). the Mux-cascade remains (and is awful) | 20:34 |
| lkcl | let me try synth on it | 20:34 |
| lkcl | urr yuk. still remains. damnit. | 20:35 |
| lkcl | that's a problem in Ripple that'll need to be fixed | 20:35 |
| lkcl | ok let me make some notes in the bugreport, because strategically, Ripple() is critical. it's going to be used in the set-before-first Vector instructions | 20:36 |
| lkcl | and extensively in the PartitionedSIMD operators | 20:36 |
| lkcl | because it's used in PartitionBool, PartitionedShift etc. etc. | 20:37 |
| lkcl | so it's a huge deal you caught this now. | 20:37 |
| lkcl | can i leave it with you to fix Ripple() - optimise it in terms of the add-trick - and then use it in clmul? | 20:38 |
| programmerjake | i have an idea for how to fix ripple, converting it into a parallel prefix-sum with depth O(log N) | 20:39 |
| programmerjake | ripple isn't used in clmul...i'm assuming you mean cldivrem | 20:39 |
| lkcl | yeerr.. yes! | 20:40 |
| * lkcl waking up slowly | 20:40 | |
| programmerjake | :) | 20:41 |
| lkcl | my mum called, woke me up, so i might as well do something | 20:43 |
| * lkcl hates code that won't run as stand-alone modules | 20:44 | |
| programmerjake | hmm...you could maybe run it using something like python -m nmigen_gf.reference.test_... | 20:46 |
| lkcl | the other code won't run either | 20:46 |
| lkcl | $ python3 gf_reference/gfpmul.py | 20:46 |
| lkcl | Traceback (most recent call last): | 20:46 |
| lkcl | File "gf_reference/gfpmul.py", line 1, in <module> | 20:46 |
| lkcl | from .state import ST | 20:46 |
| lkcl | ModuleNotFoundError: No module named '__main__.state'; '__main__' is not a package | 20:46 |
| programmerjake | python -m nmigen_gf.reference.gfpmul works | 20:49 |
| lkcl | yes, that makes sense, but is a botch-job-workaround | 20:49 |
| * lkcl pondering | 20:49 | |
| lkcl | local-imports are something that i've never been able to get my head around, and found them to be f***** irritating | 20:50 |
| programmerjake | python -m nmigen_gf.reference.test_cl_gfb_gfp works, i just ran it | 20:50 |
| lkcl | it's the fact that "python gf_reference/gfpmul.py" doesn't that's bugging me | 20:51 |
| programmerjake | imho python packages have a poor design...that's why local imports don't work | 20:51 |
| markos | lkcl, quick one, happyram pmod, 64MB or 256MB? | 20:51 |
| lkcl | markos, large as possible | 20:51 |
| lkcl | 64 Mbit is only 8 m*byte* | 20:52 |
| markos | good | 20:52 |
| lkcl | 256 mbit is only 32 mega-*byte* | 20:52 |
| lkcl | you'll definitely not be able to run linux in 8 megabytes | 20:52 |
| lkcl | 32 megabytes is pushing it | 20:52 |
| markos | ah crap, that's MBit | 20:52 |
| markos | "it" is barely visible... | 20:53 |
| lkcl | programmerjake, it probably made sense to the designers when they put it together, sigh | 20:53 |
| lkcl | markos, yeah with RAM you really have to watch out for that. all DDR3/4 ICs are given in terms of the total bit density *not* the byte density | 20:53 |
| lkcl | because they're internally lined up in x4, x8, x16 banks | 20:54 |
| programmerjake | hoping they make 3D ram soon...yay 64TiB ram! | 20:54 |
| lkcl | :) | 20:56 |
| * lkcl nggghhhh streeeeess | 20:57 | |
| lkcl | moooo | 20:57 |
| lkcl | what's the difference between | 20:57 |
| lkcl | gf_reference/state.py and | 20:57 |
| programmerjake | 256TiB is 131072 by 131072 by 131072 assuming 1 bit per cell | 20:57 |
| lkcl | src/nmigen_gf/reference/state.py? | 20:57 |
| lkcl | ah hell, a symlink, darn it | 20:58 |
| programmerjake | src/.... is the canonical python package location that's installed using setup.py | 20:58 |
| lkcl | yeah that's a botch-job | 20:58 |
| lkcl | still doesn't compute | 20:59 |
| lkcl | $ python3 src/nmigen_gf/reference/gfpmul.py | 20:59 |
| lkcl | Traceback (most recent call last): | 20:59 |
| lkcl | File "src/nmigen_gf/reference/gfpmul.py", line 1, in <module> | 20:59 |
| lkcl | from .state import ST | 20:59 |
| lkcl | ModuleNotFoundError: No module named '__main__.state'; '__main__' is not a package | 20:59 |
| programmerjake | use -m | 20:59 |
| lkcl | no, you're missing the point | 20:59 |
| lkcl | fixing the layout so that it is *not* necessary to botch-workaround with "-m" is the point | 21:00 |
| lkcl | i believe this is the thing i was talking about with package_dir in setup.py | 21:00 |
| lkcl | that the layout can be fixed (without the symlink) by specifying the right package_dir option | 21:00 |
| * lkcl going to try this: | 21:01 | |
| lkcl | package_dir={"": "src", "reference": "gf_reference"}, | 21:01 |
| programmerjake | those files are part of a package...running directly with python file.py causes python to say effectively "oh, so you want me to pretend that file is independent of all the files around it and it isn't in a package, sure...import not found" | 21:01 |
| programmerjake | package_dir like that doesn't work, already tried | 21:02 |
| lkcl | drat. | 21:02 |
| lkcl | ok. | 21:02 |
| lkcl | next one: remove local imports, i can't stand them anyway. | 21:02 |
| lkcl | i think find_packages() is the "dumb" function, which recursively-walks the source directory. | 21:03 |
| lkcl | i vaguely remember doing this by hand... errr... 18+ years ago | 21:03 |
| lkcl | everyone doing hand-walking and explicit listing of packages "inspired" the creation of find_packages() | 21:04 |
| programmerjake | do remember the files in gf_reference should be short and to-the-point since they're embedded in bitmanip.mdwn and we want to not have a bunch of spurious lines there | 21:04 |
| lkcl | yehyeh. each line will be explicit "from nmigen_gf.reference.state import ...." | 21:04 |
| programmerjake | find_packages isn't the problem, even writing my own find_packages didn't fix it | 21:05 |
| lkcl | @@ -1,4 +1,4 @@ | 21:05 |
| lkcl | -from .log2 import floor_log2 | 21:05 |
| lkcl | +from nmigen_gf.reference.log2 import floor_log2 | 21:05 |
| lkcl | ] | 21:05 |
| lkcl | ahh problem gone. | 21:05 |
| lkcl | exxxcellent | 21:05 |
| programmerjake | see semantics of package_dir | 21:05 |
| lkcl | lkcl@fizzy:~/src/libresoc/nmigen-gf$ python3 gf_reference/gfpmul.py | 21:05 |
| lkcl | lkcl@fizzy:~/src/libresoc/nmigen-gf$ | 21:05 |
| lkcl | ahhh, now i'm happy | 21:05 |
| lkcl | +++ b/gf_reference/state.py | 21:06 |
| lkcl | @@ -1,4 +1,4 @@ | 21:06 |
| lkcl | -from .log2 import floor_log2 | 21:06 |
| lkcl | +from nmigen_gf.reference.log2 import floor_log2 | 21:06 |
| lkcl | lkcl@fizzy:~/src/libresoc/nmigen-gf$ python3 gf_reference/test_cl_gfb_gfp.py | 21:07 |
| lkcl | Ran 23 tests in 2.861s | 21:07 |
| lkcl | OK | 21:07 |
| * lkcl oleeeeee | 21:07 | |
| programmerjake | > A package: dir entry in the package_dir dictionary implicitly applies to all packages below package, so the foo.bar case is automatically handled here. | 21:07 |
| programmerjake | https://docs.python.org/3.7/distutils/setupscript.html | 21:07 |
| lkcl | lkcl@fizzy:~/src/libresoc/nmigen-gf$ nosetests3 | 21:09 |
| lkcl | Ran 68 tests in 94.336s | 21:09 |
| lkcl | OK | 21:09 |
| lkcl | hurrah. all good | 21:09 |
| programmerjake | you're running duplicate tests cuz of both gf_reference and src/nmigen_gf/reference | 21:10 |
| programmerjake | `pytest -n auto src` works around that | 21:10 |
| lkcl | i'm good with that :) | 21:15 |
| lkcl | i don't mind. | 21:15 |
| lkcl | my brain seems strangely fixated on nosetests3. some sort of automatic reaction i'm finding hard to resist :) | 21:16 |
| lkcl | meeting in 45m btw | 21:16 |
| lkcl | one hour earlier | 21:16 |
| lkcl | is that right? | 21:16 |
| lkcl | urrr... | 21:16 |
| lkcl | 21:00 UTC | 21:17 |
| lkcl | https://www.timeanddate.com/worldclock/timezone/utc | 21:17 |
| lkcl | lx0 jn cesar toshywoshy markos ^ | 21:18 |
| lkcl | anyone else who'd like to join let us know we can privately send the jitsi link (so it doesn't show up in public logs) | 21:19 |
| lkcl | [ab]using add just because carry-propagation is efficiently implemented as a well-known algorithm, sigh | 21:23 |
| lkcl | totally get it - also totally want to throw up :) | 21:23 |
| lkcl | https://libre-soc.org/openpower/sv/bitmanip/ looks pretty frickin awesome | 21:25 |
| lkcl | thanks to the embedded reference code | 21:26 |
| lkcl | the fact that it's executable code and has unit tests, that's damn cool | 21:26 |
| * lkcl salutes programmerjake | 21:26 | |
| lkcl | what that means in particular is, the code - which is also the documentation - sort-of becomes part of the Compliance Test Suite | 21:29 |
| programmerjake | :) | 21:35 |
| programmerjake | lkcl, the bitmanip bdep op is a vsx instruction, so we probably want to add a scalar non-vsx one rather than just having the existing one | 21:45 |
| programmerjake | <lkcl> "salutes programmerjake..." <- thx! | 21:46 |
| programmerjake | <lkcl> "that was a hint for you to use..." <- oh, i had just been using the submodule's inputs as the temporary Signals | 21:52 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!