<emily>
for values of "everyone" equal to "non-embedded linux" at best, and then taking debian derivatives out of that is an even bigger chunk
<emily>
meanwhile macos ships with a version of bash from 2007, embedded linux and bsds often not at all
<whitequark>
ktemkin: that works individually but then i wouldn't see what most people trying to use it will
<awygle>
that does seem to have fixed it
<awygle>
so that's good
<ktemkin>
whitequark: yeah, sorry; that wasn't really a suggestion -- my "~"-terminating statements are meant to be tongue-in-cheek
* emily
apologises for her pedantry :v
<ktemkin>
emily: you'd think that 'embedded linux' folks would know better, but when last I checked, running *openembedded* required /bin/sh to be a symlink to bash
<ktemkin>
(admittedly, when last I checked was like six years ago, but yeah)
<emily>
often you're dealing with e.g. busybox ash or worse, in my experience
<emily>
build scripts tend to be a total unportable mess though, yeah
<emily>
the real lesson from shell script hell is to just write as few shell scripts as possible
<whitequark>
yeah
<ktemkin>
thank gods we've learned from our mistakes and modern scripting languages never do things like use the same binary name for multiple incompatible language dialects
* ktemkin
goes back to writing python
kmtd has joined #nmigen
kmtd has quit [Client Quit]
<whitequark>
ktemkin: remember how ruby would change syntax in incompatible ways in patch versions?
<ktemkin>
lol, yeah; I think I stopped using ruby _before_ they implemented a coherent concept of patch versions
<ktemkin>
I drifted away from ruby while 2.0 was either upcoming or very new
<whitequark>
they did that in 1.9 too
<ktemkin>
yeah; (I'm saying they didn't actually agree to keep anything compatible until something like 2.1, so I never actually saw them -stop-)
<whitequark>
oh, they didn't agree for it yet
<whitequark>
not for syntax i think
<whitequark>
~half a year ago there was a discussion someone linked to me
<whitequark>
but i think no actual decision
<ktemkin>
I think rather fondly back on ruby; but it's very much become one of those languages that I don't think I'd ever pick up again
<ktemkin>
the language is a bit ambiguous as to what'd require a "teeny" (patch) version bump, but particularly the goal of `user can safely upgrade ruby to a new teeny version without having to rebuild and reinstall already installed libraries` seems like it'd preclude them from both meeting their versioning scheme and making breaking syntax changes in 2.1+
<ktemkin>
dunno if in practice that was interpreted only as applying to the actual API/ABI and not e.g. to the language specification; as that seems like it'd be way out there
<cr1901_modern>
awygle: http://ix.io/2bPA Hmm I vaguely recall having to do this step as well, but I must've done it a while ago...
<whitequark>
ktemkin: the changes in question were treated as bugfixes
<whitequark>
but it *did* change the grammar
<cr1901_modern>
whitequark: Just to be crystal clear from rereading plat.py... if using diamond, yosys is only run while the jinja templates are being instantiated?
<cr1901_modern>
Oh, I was just curious. I misunderstood why changing sh to bash was the only fix needed.
<cr1901_modern>
Because I thought yosys was run in the script _after_ diamond_env was run
<whitequark>
changing sh to bash has nothing to do with nmigen
<whitequark>
their tools are just broken
<cr1901_modern>
Anyways, while free toolchains aren't ready yet: if yosys is ever necessary in the diamond (or other proprietary toolchains) backends, won't the CXX library mismatch happen?
<cr1901_modern>
Eh, I guess I won't worry about it
<whitequark>
yosys is necessary in the diamond backend
<whitequark>
it's just never run in the environment where diamond sets up LD_LIBRARY_PATH
<whitequark>
specifically for this reason
<whitequark>
that is also why NMIGEN_ENV_* exist, and you don't just source the diamond environment script before running nmigen
<whitequark>
it's not just convenience, it's actually required for it to work
<awygle>
whitequark: so i was playing with building litex under nmigen and there seem to be quite a few things it uses missing from nmigen.compat (and documented that way). just wondering if those are by and large in need of some architectural decision, or just the work hasn't been done yet? specifically looking at genlib.misc, for the most part
<awygle>
fwiw i was able to just copy most of migen's genlib.misc, replace a couple things, and build it without issue, although i have no idea if it like.... works
<whitequark>
awygle: yeah it should be OK to just copy genlib.misc over
<whitequark>
feel free to do a PR
<awygle>
mk, i'll make a pr
<awygle>
now litex _does_ fuck with private classes of fhdl.structure
<awygle>
which i imagine is a bad idea to just grab and go with
<awygle>
but i'll tackle that another time lol
<whitequark>
what does it do?
<awygle>
i don't really understand the under-the-hood mechanics well enough to know for sure, but it does import _Value and _Fragment directly
<whitequark>
can you open a meta-issue documenting what it does and where so we can discuss it?
<awygle>
mostly to call isinstance on them it looks like
<awygle>
sure, will do
<whitequark>
oh
<whitequark>
ugh, isinstance()
<whitequark>
i know how to make that work transparently but it's kind of a horrifying hack
<cr1901_modern>
This also came up when litex duplicated all the FHDL classes for its own variant of omigen...
<awygle>
i'm tempted to say the best solution here is to actually replace those with nmigen equivalents
<awygle>
since litex has expressed interest in doing that anyway
<cr1901_modern>
FWIW, litex eventually _did_ start using omigen directly and FHDL mismatches disappeared
<cr1901_modern>
definitely feasible I would think
<awygle>
but i want to more properly understand what exactly they're trying to do, so i'll endeavour to do that
<awygle>
there's also gotta be people we can ask lol
<cr1901_modern>
awygle: /join #timvideos and #litex?
<cr1901_modern>
mithro would be one person to ask
mithro has joined #nmigen
<cr1901_modern>
D-did I just summon mithro :o?
<whitequark>
(i /query'd)
<mithro>
Hi!
sorear has joined #nmigen
<awygle>
hi mithro. do you know what litex needs with _Value and _Fragment and the like from migen.fhdl.structure? why is it accessing these private classes?
<awygle>
context - discussing what it would take to get litex building under nmigen (even with nmigen.compat)
<mithro>
awygle: _florent_ would be a much better person to ask :-)
<mithro>
awygle: I'm more a "manager" these days and don't get much time to actually write litex code :-(
<cr1901_modern>
Is "LFE5UM-45F-8BG381C" one of those devices that requires a license? Because I get "failed to create project" consistently when trying to run the blinky from versa_ecp5 in nmigen boards
<cr1901_modern>
(I manually changed the toolchain to Diamond to test something)
<whitequark>
cr1901_modern: versa comes with an evaluation license, yes
<whitequark>
or maybe not evaluation? i think i never activated mine
<whitequark>
don't have patience to deal with flexlm bullshit
<cr1901_modern>
okay, good to know
<cr1901_modern>
Well trying to create a project consistently fails and I never... bypassed flexlm. How difficult is it?
<TD-Linux>
"git clone nextpnr" /me runs
<awygle>
it's evaluation yes
<whitequark>
TD-Linux: nextpnr can't do derived clocks or IOB timing
<awygle>
for a year
<whitequark>
also back when i wrote Yumewatari it didn't have QoS/QoR enough for even PCIe Gen1
<whitequark>
almost but not quite
<TD-Linux>
the colorlight board demo also misses timing but I haven't tried comparing it to diamond yet
<awygle>
this is a dumb question but what does litex actually _do_? like i get the soc stuff but why does it have its own board and platform abstractions?
<awygle>
and its own verilog generator, and and and...
<cr1901_modern>
awygle: See DM
<cr1901_modern>
err privmsg
<whitequark>
awygle: because migen has been consistently hostile to integrating changes litex needed, basically. litex used to be a complete migen fork
<awygle>
ah
<awygle>
is there an nmigen equivalent of PulseSynchronizer?
<whitequark>
feel free to grab PulseSynchronizer from that PR and submit it on its own
<whitequark>
and we should coordinate with Luke to re-add the rest
<awygle>
oh this is an _issue_ not a PR, i was confused briefly :p
<awygle>
yeah sure, sounds good
<whitequark>
it's a PR
<whitequark>
it just got turned into an issue during repo migration
<awygle>
yeah, i get it now
<_whitenotifier-3>
[nmigen] whitequark commented on issue #47: WIP: Expand and document lib.cdc - https://git.io/Jv8LS
<awygle>
whitequark: is there any kind of python style linter i should run before sending this PR?
<awygle>
i'd hate to waste your time with "you moron, no tabs" kinds of problems
<whitequark>
awygle: i normally just edit this kind of style nits myself to avoid bothering contributors
<whitequark>
generally it's just 4 spaces, 2 newlines between toplevel entities
<whitequark>
(the latter comes from pep8)
<awygle>
Mk, ideally that's correct already...
<ktemkin>
related: I need to stop being bad and just implementing things in my own projects' libraries that maybe should be in {nmigen-*} >.>
* ktemkin
eyes nmigen-stdio somewhat guiltily
<_whitenotifier-3>
[nmigen] awygle opened pull request #321: Add PulseSynchronizer to nmigen.lib.cdc. - https://git.io/Jv8tw
<ktemkin>
were there plans/discussions/etc for -stdio captured anywhere?
<ktemkin>
I'm at the point where I keep implementing things in e.g. LUNA where it seems like effort might be better spent on doing something more standard/upstream
<_whitenotifier-3>
[nmigen] codecov[bot] edited a comment on pull request #321: Add PulseSynchronizer to nmigen.lib.cdc. - https://git.io/Jv8tF
<ktemkin>
awygle: I saw that discussion; but missed any higher-level discussions that may have preceded it (e.g what's in scope for -stdio, etc.)
<awygle>
oh, we talked about that too. nmigen-soc is basically busses and registers, nmigen-stdio is standard i/o peripherals attached to the aforementioned stream abstraction
<awygle>
nmigen-soc would contain a stream-to-axi4stream converter (for example)
<awygle>
at least that's my understanding
<awygle>
whitequark: adding PulseSynchronizer to nmigen.compat.genlib.cdc, i notice there's a "test_compat.py" but it doesn't seem to be used anywhere. are compat tests expected? if so, where can i find an example?
<_whitenotifier-3>
[nmigen] codecov[bot] edited a comment on pull request #321: Add PulseSynchronizer to nmigen.lib.cdc. - https://git.io/Jv8tF
<ktemkin>
what needs to be {investigated, discussed, etc} in order to move the stream abstraction forward?
<ktemkin>
it seems like what's lacking in that GH issue is identification of any weaknesses of the litex::stream architecture that might be addressed when creating the nmigen one
<whitequark>
so displacer is word_select on lhs, and chooser is word_select on rhs?
<whitequark>
why does split exist?
<awygle>
No clue
<whitequark>
more of a rhetorical question yea
Asu has joined #nmigen
felix_ has joined #nmigen
<Sarayan>
Hey whitequark-sempai, what's the nitty-gritty of an integrated logic analyzer?
ronyrus has joined #nmigen
proteus-guy has quit [Ping timeout: 240 seconds]
proteus-guy has joined #nmigen
proteus-guy has quit [Ping timeout: 240 seconds]
levi has quit [Ping timeout: 272 seconds]
levi has joined #nmigen
proteus-guy has joined #nmigen
ronyrus has quit [Remote host closed the connection]
Asu has quit [Remote host closed the connection]
Asu has joined #nmigen
EmilJ has joined #nmigen
ronyrus has joined #nmigen
<EmilJ>
Hey, do I understand it correctly that nmigen is so new that I can't see what features it provides over migen without first learning migen and then reading the source code of nmigen?
<EmilJ>
I'm just looking for a good HDL to sink my teeth into to become the Ultimate Arch Mage of Synthesis, without my purity being challenged with high paying jobs due to me learning archaic things people in The Industry are already using
<ZirconiumX>
EmilJ: nMigen is generally much better designed
<ZirconiumX>
It simulates faster too
<ZirconiumX>
And with nmigen.compat you can run old Migen code by just patching the imports
<EmilJ>
sweet
<EmilJ>
do you think it's a good tool to put together a RISC-V core for learning purposes?
<awygle>
Sarayan: did you have a specific aim? i'm currently hacking litescope to bulid under nmigen (through Extreme Violence to both litescope and litex codebases....) and i also started trying to wrap sump2, but currently there are no ILAs targeting nmigen
<MadHacker>
EmilJ has quit [Read error: Connection reset by peer]
<Sarayan>
awygle: making debugging the stuff I write in nmigen easier is my aim
<awygle>
I share this goal for sure
<awygle>
Integrating with the language the way that e.g. Clarity works in diamond is more complex
<awygle>
wq and I discussed this a while back
<awygle>
But either porting an existing core or writing a new one for nmigen should be easier
<awygle>
the litescope test suite has been pegging a core of this machine for like.... 30m or more. i wonder if i broke it or if it really takes this long...
<awygle>
it's definitely not supposed to take that long, without modification it takes 14 seconds
<whitequark>
yeah it's definitely looping
<whitequark>
possibly a race condition somewhere
<whitequark>
i think pysim2 exposes a few of those
<awygle>
current plan is to actually _port_ some of this stuff away from nmigen.compat and see if that fixes it. any suggestions as to where to focus?