nyanotech has quit [Remote host closed the connection]
nyanotech has joined #glasgow
<d1b2>
<attiegrande> @whitequark - i had a look at supporting yowasp-yosys this week, but didn't get too far
<d1b2>
<attiegrande> am I correct that glasgow leans heavily on LatticeICE40Platform (from amaranth), which does most of the lifting, and ultimately resolves yosys at present?
<d1b2>
<attiegrande> so this is more of a patch to amaranth than glasgow(?)
<whitequark[cis]>
it just needs to set an environment variable when calling the build
<d1b2>
<attiegrande> oh!
<d1b2>
<attiegrande> AMARANTH_USE_YOSYS (?)
<whitequark[cis]>
(this is kind of why I wanted to do it myself... others tend to lack context and often don't acquire it as quickly. but we went through that before, so eh)
<whitequark[cis]>
it's simply YOSYS
<whitequark[cis]>
AMARANTH_USE_YOSYS is for the yosys that is used for conversion to Verilog
<d1b2>
<attiegrande> ok, i didn't think that was correct
<whitequark[cis]>
(this part is fairly confusing yeah)
<whitequark[cis]>
(I'm actually going to stop relying on Yosys for Verilog conversion eventually, but it's there for now)
<whitequark[cis]>
you need to set YOSYS, NEXTPNR_ICE40, and ICEPACK to the right values
<whitequark[cis]>
but that's the easy part, the hard one is adding some code to make sure those (or whatever else the user environment provides) are indeed valid executables that we can get the versions of
<whitequark[cis]>
well, hard*er*, it's more annoying than hard per se
<d1b2>
<attiegrande> out of curiosity, what did you put just before the YOSYS above? (i presume it's denoting a code block, but renders as a square for me / in discord)
<whitequark[cis]>
(another env var is documented there, I forgot)
<whitequark[cis]>
on the matrix side it's a `
<whitequark[cis]>
but the Matrix to IRC bridge translates it to some mIRC specific code
<whitequark[cis]>
and the IRC to Discord bridge doesn't do anything with it
<d1b2>
<attiegrande> hah, fair enough
<d1b2>
<attiegrande> i wondered... the first is a box, the presumably trailing is missing
<whitequark[cis]>
I want to stop using d1b2 and run our own Matrix to Discord bridge for Glasgow and Amaranth because honestly I'm tired of the non-puppeting bridge d1b2 is
<whitequark[cis]>
I have most of the infra for this, actually
<whitequark[cis]>
I just need to test it on staging and coordinate the rollout of a bridge that potentially causes very many new IRC connections with the Libera staff
<whitequark[cis]>
they've been happy with me bridging channels so far but as I get more experience operating it I'm getting more ambitious with my goals
<d1b2>
<attiegrande> sounds good!
<whitequark[cis]>
and that's something that needs to be approached with care
<whitequark[cis]>
then you will be an IRC user attiegrande|d1b2
<whitequark[cis]>
and a Matrix user @1bitsquared_attiegrande:catircservices.org
<d1b2>
<attiegrande> sounds good
<whitequark[cis]>
and all of this would work transparently with no one getting confused and trying to respond to d1b2 directly
<d1b2>
<attiegrande> i'll always be grumpy when people grab 'attie' before i became present on the platform
<whitequark[cis]>
awww
<d1b2>
<attiegrande> 🙃
<d1b2>
<attiegrande> i've now properly understood the "required tool" mechanism in amaranth - it's good, well done
<d1b2>
<attiegrande> I initially just skimmed over it / didn't see the env var stuff
<whitequark[cis]>
perfect ^^
<d1b2>
<attiegrande> glasgow's pyproject.toml lists yowasp-yosys... but _BuiltinYosys calls for amaranth-yosys... is there a preference (or both?)
<d1b2>
<attiegrande> I'd guess that if anything, amaranth-yosys is missing some features?
<d1b2>
<attiegrande> think I answered my own question... yowasp-yosys and yowasp-nextpnr-ice40, not amaranth-yosys, correct?
<Wanda[cis]>
amaranth-yosys is a minimal build with no synthesis capabilities, used only for RTLIL -> Verilog conversion
<Wanda[cis]>
amaranth depends on it so it doesn't pull in the whole toolchain for non-yosys synthesis case
<d1b2>
<attiegrande> yeah, that's what i settled on - thanks!
jevinskie[m]1 has joined #glasgow
<jevinskie[m]>
TYVM!
<jevinskie[m]>
[Catherine](<https://matrix.to/#/@whitequark:matrix.org>) and anyone else who knows about the bridgeocolypse: any pointers to setting up my own irc bridge for other channels? I’m thinking about #litex and some other channels that may not take any actions?
<jevinskie[m]>
Or maybe I should just ditch Matrix and use something like https://thelounge.chat Though a native client would be preferred but there don’t seem to be any good iOS IRC clients even if I set up a bouncer like znc
jstein has joined #glasgow
<whitequark[cis]>
jevinskie: use heisenbridge in bouncer configuration
<d1b2>
<attiegrande> what's the preferred way to check icepack's version? or is the mere existence good enough?
<d1b2>
<attiegrande> (i don't see a --version type option)
<whitequark[cis]>
uhh let's see
<whitequark[cis]>
ok so if it's not a yowasp one, then just hash the binary.
<whitequark[cis]>
crude but effective
<d1b2>
<attiegrande> sure
<d1b2>
<attiegrande> ... and for yowasp, just accept whatever?
<whitequark[cis]>
no
<galibert[m]1>
"Icepack is a Python library for solving the equations of motion of glacier flow."... not that one I expect?
<whitequark[cis]>
for yowasp you can get the exact version using importlib.metadata
<d1b2>
<attiegrande> oh, duh... ta
<whitequark[cis]>
see the Python documentation for that one; plus grep the sources of my projects (yowasp, amaranth) to see how to use it with older Pythons
<d1b2>
<attiegrande> yeah
<whitequark[cis]>
this is also much faster than calling the binary, potentially, bc it might have to compile
<d1b2>
<attiegrande> do you have insight into how often the binary changes / how many hashes i should be seeking?
<whitequark[cis]>
sorry, I don't understand the latter question
<d1b2>
<attiegrande> i'll take the latest from oss-cad-suite as a start, but...
<galibert[m]1>
Ahhhhh, bitstream generator part of icestorm which is itself for the lattice support
<whitequark[cis]>
lattice ice40 specifically
<d1b2>
<attiegrande> re last question: .../oss-cad-suite/bin/icepack is MD5: af4d76174e4ac024bf8163c2ca753866
lolock has joined #glasgow
<d1b2>
<attiegrande> do you think there might be more versions / hashes i should also accept in recent releases?
<d1b2>
<attiegrande> (i'm happy to go pull a handful of releases and see for myself, just wondering if you know off the top of your head)
<whitequark[cis]>
uhhh, what?
<whitequark[cis]>
why would you accept a handful of hashes?
<galibert[m]1>
which is the glasgow fpga, makes perfect sense now
<whitequark[cis]>
I'm not suggesting you whitelist versions; I'm saying you should record versions (and hash them into the cache key for when we cache bitstreams, eventually)
<d1b2>
<attiegrande> to give an equivelant of >= x.y (?) ... more than happy for just one, but if people are running an older toolchain, the hash might not match
<whitequark[cis]>
oh
<whitequark[cis]>
it won't work
<whitequark[cis]>
we cannot predict what hash someone would have on their Gentoo system
<d1b2>
<attiegrande> hah
<whitequark[cis]>
or NixOS or any other source based distro
<whitequark[cis]>
for icepack, I think there's been basically no bugs/changes as far as I remember
<d1b2>
<attiegrande> tempted to just accept whatever exists, and we can revisit if there are issues?
<whitequark[cis]>
yes
<whitequark[cis]>
but definitely bake it into the cache key anyway
<d1b2>
<attiegrande> ok, thanks
<d1b2>
<attiegrande> will do (when I get to that task)
<whitequark[cis]>
thank you
<Wanda[cis]>
we seem to recall some issue on ice40 regarding memory clock polarities, though not sure if it was solved in icestorm or nextpnr
<whitequark[cis]>
I'm still not really sure why the eagerness to do version comparisons?
<whitequark[cis]>
I don't recall ever having to handle a bug that boiled down to "update Yosys"
<whitequark[cis]>
I suppose it is good to have this functionality but I don't understand why you went for it... in Amaranth this is quite important because Amaranth writes a Yosys script in the Verilog backend that uses some Yosys commands that have changed over the years
<d1b2>
<attiegrande> oh okay, I used amaranth for inspiration, more than happy to remove it
<whitequark[cis]>
don't need `other_candidates`, don't need `version_args` (you don't even use it), `ToolchainAutodetect` -> probably just `Tool`, merge `get_version_info` with `check`
<d1b2>
<attiegrande> a simple "is there a binary on the path" for all three satisfies?
<whitequark[cis]>
instead of setup mutating the environment I think you should make it easy to fill out a new dict with the additional parameters (which will later get used in the Glasgow build process)
<d1b2>
<attiegrande> I spotted "version_args" too
<whitequark[cis]>
well you'll need version info later, but if you're not handling that yet, you can just toss it... I personally would build a module that handles both, test it, and then introduce it gradually
<whitequark[cis]>
I'm tempted to just implement it myself rather than communicating every requirement precisely, to be honest
<whitequark[cis]>
it would be faster and involve less back-and-forth
<whitequark[cis]>
there's a fair bit of subtlety later, i.e. I think it makes good sense to have a single environment variable that switches between yowasp toolset and native toolset
<whitequark[cis]>
and you aren't handling importlib.metadata for yowasp at all
wifasoi[m] has left #glasgow [#glasgow]
esden[m]1 is now known as esden[cis]
<d1b2>
<attiegrande> sure, let's talk more later?
<d1b2>
<attiegrande> I was hoping to take some pressure off you - still happy to talk things through, or let you take it on
<d1b2>
<attiegrande> rolling versioning and other info require for caching into this does make sense
<d1b2>
<attiegrande> *required
cr1901_ is now known as cr1901
<whitequark[cis]>
yep sure
<d1b2>
<esden> Are we having a meeting today?
<whitequark[cis]>
I think so!
<whitequark[cis]>
attie, are you around? electroniceel?
<electronic_eel>
i'm here
<whitequark[cis]>
so... technical progress from the previous time: nothing besides attie working on yosys toolchain invocation above
<whitequark[cis]>
personal: my health is getting better and better by the week, so that's great
<electronic_eel>
nice to hear!
<whitequark[cis]>
oh wait, Wanda doing things was this week?
<Wanda[cis]>
last week
<Wanda[cis]>
but the meeting in the meantime didn't happen
<whitequark[cis]>
no, the one before that
<whitequark[cis]>
right
<whitequark[cis]>
then, add to the technical progress list: Wanda ported everything off amaranth.compat
<whitequark[cis]>
which is excellent news and very good job on her side
<Wanda[cis]>
also we have Python 3.11 support now
<d1b2>
<attiegrande> i'm here, sorry for lateness
<whitequark[cis]>
oh, also excellent
<electronic_eel>
oh, both points sound very good!
<d1b2>
<attiegrande> re health: fantastic to hear!
<whitequark[cis]>
social-ish? point: the Matrix room #glasgow:libera.chat is going away at the end of month due to what I can only describe as organizational incompetence (not on Libera's side)
<whitequark[cis]>
so I set up #glasgow-interface-explorer:matrix.org that is bridged to IRC using my infrastructure which actually works well
<d1b2>
<esden> it is great to hear that you are feeling better and improving!
<electronic_eel>
whitequark[cis]: so that is why you are "[cis]" now...
<d1b2>
<attiegrande> apologies ... wanda, are you aka mwk?
<whitequark[cis]>
re bridging: I am considering doing my own double puppting bridge for Matrix<>Discord, therefore bridging IRC, Matrix, and Discord together
<d1b2>
<esden> @whitequark let me know when you do that, I am happy to remove the irc bridge for the glasgow and amaranth channels whenever you are up for it.
<whitequark[cis]>
meaning that someone talking on IRC will see Discord users (that actually talk in the channel) as e.g. esden|d1b2 user
<whitequark[cis]>
it will require more coordination from your side, esden, to set up webhooks and do a trial run
<whitequark[cis]>
so it's not quite as simple as that
<d1b2>
<esden> Yes this is what I am expecting. I am here for it 😄
<d1b2>
<esden> the size of that label is about 20mm wide and 6mm high
<whitequark[cis]>
oh, this looks quite alright to me
<Wanda[cis]>
(btw, glasgow currently doesn't work on python 3.12, which will be released in 3 months; there's a build error on two of the dependencies that we can't do much about at this point, but it may be worth manually hacking around that issue and checking if anything else is broken)
<whitequark[cis]>
those dependencies are optional in spirit
<Wanda[cis]>
(the problem is aiohttp, which I think is only required by one applet?)
<whitequark[cis]>
yes
<d1b2>
<esden> In any case. Current info included in text is lot and serial number.
<whitequark[cis]>
and not one most people care about
<whitequark[cis]>
esden: y/n on amending the Manufacturer field for 1b2 devices to say 1bitsquared?
<whitequark[cis]>
in the USB firmware
<whitequark[cis]>
this means you get your own serial block completely non intersecting with anyone else, at the very least
<d1b2>
<esden> Yes that would be good
<whitequark[cis]>
and if you want you can put like "1bitsquared Lot 1" there or sth
<whitequark[cis]>
okay, can someone file this as a bug?
<d1b2>
<attiegrande> spec looks great
<whitequark[cis]>
I can do this next time I pick Glasgow up... potentially just tomorrow
<d1b2>
<attiegrande> re mfg field - this is a firmware change?
<whitequark[cis]>
tomorrow I wanted to fix a bunch of OSS bugs that're on me
<whitequark[cis]>
yes
<d1b2>
<attiegrande> will do
<whitequark[cis]>
firmware and config block
<galibert[m]1>
It’s not a bug, it’s a feature
<whitequark[cis]>
lol
<whitequark[cis]>
i stand corrected
<electronic_eel>
yeah, the label spec looks good. i rarely see barcodes with properly separated fields.
<d1b2>
<esden> @electronic_eel the above gist has the spec document linked
<d1b2>
<esden> @whitequark so I guess regarding the firmware, there will be a setting that can be switched to select manufacturer?
<d1b2>
<esden> I am not 100% clear how this will work.
<electronic_eel>
esden: yeah, i know the specs. it is just that on many products i checked the manufacturers don't use them, they just cobble something together
<d1b2>
<esden> this is why I am using the spec, and recently checked labels from mouser and digikey, they use the same spec these days
<d1b2>
<esden> mouser wants "us" to use the spec too when sending them hardware
<whitequark[cis]>
@esden: it would be a command line option that lets you flash anything you want to the "manufacturer" field in the EEPROM
<d1b2>
<esden> @whitequark great! thanks 🙂
<d1b2>
<attiegrande> @whitequark - is this also a resize to support the extra characters (IIRC?)
<whitequark[cis]>
this seems easier than maintaining e.g. a list of known manufacturers
<whitequark[cis]>
@attiegrande: no, the serial stays the same length
<whitequark[cis]>
manufacturer is a different USB strings
<whitequark[cis]>
s/strings/string/
<d1b2>
<esden> here are a few boxes for the glasgow cases, with product labels