<_whitenotifier-3>
[nmigen] whitequark edited a comment on issue #479: Add `proc -nomux` to Yosys and migrate to it - https://git.io/JUTqh
<_whitenotifier-3>
[nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±13] https://git.io/JUkwE
<_whitenotifier-3>
[nmigen/nmigen] whitequark ad9fe67 - Deploying to gh-pages from @ 5b01499901d45400c58fba184c3ba6702d012858 🚀
jeanthom has quit [Ping timeout: 265 seconds]
Yehowshua has quit [Remote host closed the connection]
<_whitenotifier-3>
[nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±2] https://git.io/JUkrL
<_whitenotifier-3>
[nmigen/nmigen] whitequark fde242a - hdl.ast: clarify exception message for out of bounds indexing.
<_whitenotifier-3>
[nmigen] whitequark closed issue #488: Change error message for IndexError for increased clarity - https://git.io/JUU6R
<_whitenotifier-3>
[nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±13] https://git.io/JUkrm
<_whitenotifier-3>
[nmigen/nmigen] whitequark 7e8b818 - Deploying to gh-pages from @ fde242aa47bed6ca692d292e44bc525bdf6f4e59 🚀
Yehowshua has joined #nmigen
<Yehowshua>
`letters = Array(ord(i) for i in "Hello, world! \r\n")`
<Yehowshua>
That snippet of nMigen code is very elegant I think
<Yehowshua>
Saw it in luna
* whitequark
would write it as `letters = Array(b"Hello, world! \r\n")`
<Yehowshua>
oh wow
<Yehowshua>
even better
<Yehowshua>
showoff
<whitequark>
pfff :p
<whitequark>
it's literally my job to know this kind of fine detail!
<Yehowshua>
>>> bus_factor(whitequark)
<Yehowshua>
Nan
<Yehowshua>
You see, that can be good an bad
<Yehowshua>
**and
<whitequark>
oh, i *hate* being a single point of failure
<Yehowshua>
hehe
<whitequark>
it is quite important for me to make sure that nmigen, in near term even, has at least one maintainer i generally trust with language design issues
<Yehowshua>
One small business owner once told me "nobody does it like you"
<Yehowshua>
That can be hard
<whitequark>
yes, but on the other hand, i'm not magic
<whitequark>
whatever principles and experience i rely on, can be transferred. not perfectly, but "most of the way there" is fine
<whitequark>
it certainly helps a budding language to have one person with a specific plan in charge, but there's nothing i want to avoid more than becoming a "BDFL"
<whitequark>
not only my experience isn't *so* valuable that it should override the insight of others (there's a reason i discuss nearly every language change in meetings!), but also, the "for life" part only looks good if you don't look up what happened to the original BDFL
<Yehowshua>
What i've observed is maintainership gets transferred naturally to those who make the most insightful/freequent contributions
<Yehowshua>
At least that was the case for ESR
<whitequark>
that's common, yeah
<whitequark>
or, sometimes it transfers to the person who runs away the slowest :p
<Yehowshua>
I read through a bulk of the nmigen source last winter. Its not so hard to learn
<Yehowshua>
Getting maintainers for GCC is probably a lot harder
<whitequark>
oh, it's quite easy to read the entire thing
<whitequark>
what's a lot harder is evolving it in a consistent way that also doesn't make the life of downstream worse
Yehowshua has quit [Remote host closed the connection]
<whitequark>
people sometimes try to introduce language changes in pull requests dropping with no previous discussion, and well
<whitequark>
lots of questions left aside. is this feature consistent with the rest of the language? will it introduce footguns? will it interfere with future evolution?
<whitequark>
will it be easy to teach?
<ktemkin>
I don’t know if there’s a good way to have maintainership be a shared/not-crushing burden.
<ktemkin>
I’ve never found one.
<whitequark>
grim
<ktemkin>
dunno; maybe the answer is just to not be me =P
<whitequark>
can't say I have strong counterexamples
Yehowshua has joined #nmigen
<Yehowshua>
Open source is weird like that. Everybody wants an open codebase, but usually a few people bear 95% of the brunt making it work
<whitequark>
it's harder for something like a language, or perhaps a library with a really intricate API, because you actually have to have someone making hard decisions
<whitequark>
you can't just accept PRs as they roll in
<Yehowshua>
The maintainer of homebrew reviews maybe a couple hundred PRs a month. Very much respect him because he often has to repeat feedback, but is very patient
<whitequark>
something i'd like to explore for nmigen is checklists
<whitequark>
checklists for new and existing platforms, for language changes, for standard library changes
<whitequark>
take the knowledge maintainers use to guide contributors and write it down
<ktemkin>
the hard part is conveying the general vision to others
<whitequark>
also true
<ktemkin>
especially for others who want to do things but haven’t borne the burden of steering something like this
<ktemkin>
whitequark: tbh, one of the reasons nMigen works is because you‘re filling the role of “vision-haver & decider”
<whitequark>
in the docs i'm writing (ok well i'm mostly merging PRs this week but you get the idea), i plan to have a page dedicated to rationale and history of its features
<whitequark>
surprisingly few languages have that
<ktemkin>
if you want to spread that role out, you need to have other people with the same sense of “what nMigen should be”
<whitequark>
say, std::iostream. i had to dig out the rationale for that out of *HOPL*
<whitequark>
ktemkin: yep and yep
<whitequark>
i mean, it's not so much a question of "want" as one of "have to"
<d1b2>
<TiltMeSenpai> I think one of the hardest things for any library of meaningful size is conveying code style
<whitequark>
i watched how rust evolved, and by whom
<whitequark>
i think it's on its 3rd generation of designers
<d1b2>
<TiltMeSenpai> with any codebase of a decent size, it's only a matter of time before a feature comes in that makes you go "this doesn't feel like it fits, but I can't express why"
<whitequark>
yeah
<whitequark>
one thing that might help nmigen in particular is that i'd really like to keep it small, prefer composability over concrete features
<whitequark>
it won't have types, in the traditional PL sense, ever. it's the C89 of HDLs, building with amorphous chunks of bits
<Yehowshua>
Well now's a good time as any I suppose
<Yehowshua>
whitequark, what's your Vision for nMigen?
<whitequark>
i'm not sure if i have something so grand
<Yehowshua>
That's one thing to consider - and the other is, what makes people like nMigen
<Yehowshua>
And then see if those align
<whitequark>
i'm building a neat little language that tries to do RTL really well and other things preferably not at all
<d1b2>
<TiltMeSenpai> I think one of the advantages of python is it's trivial to have one or more nmigen standard libraries exist as seperate packages
<d1b2>
<TiltMeSenpai> meaning nmigen itself only really has to worry about "what can I not express with existing primitives"
<whitequark>
i can see it being, roughly speaking, finished. not that it'll stop evolve, but that it'll fill the niche it aims at to the point of diminishing returns
<whitequark>
kinda like C is finished, even though the spec grows constantly
<Yehowshua>
I' m actually curious to hear other's opinions on this channel. Why not chisel, or bluespec?
<whitequark>
TiltMeSenpai: pretty much. well, I don't think that alternative standard libraries, specifically, are very viable
<whitequark>
because the stdlib integrates with platforms
<whitequark>
(the stdlib also has a bunch of helpers and a bunch of interoperability stuff, which is fine; but it *has to exist* because it needs to integrate with platforms)
<whitequark>
Yehowshua: honestly, my Vision, if you will, is to have a HDL that works for me and not against me, one that would be useful to lots and lots of people
<Yehowshua>
That's pretty simple I think.
<Yehowshua>
Good
<whitequark>
I started working on it because I needed something to build Glasgow upon
<whitequark>
Verilog? absurd. oMigen? well, I started out with it, but it has so many flaws that aren't going anywhere without a redesign
<Yehowshua>
I use nMigen because it feels natural. It reflects the way I think about hardware.
<whitequark>
means I succeeded :)
<Yehowshua>
With verilog, I have to translate those thoughts when I design
<Yehowshua>
Also, running tests in nMigen is very easy to do
<whitequark>
tbh the nMigen testbench story kinda sucks
<Yehowshua>
You can get a similar level of ease with CocoTb, but you're still interfacing with verilog or VHDL
<Yehowshua>
Hm, what testbench paradigm do you prefer?
<whitequark>
I know people figure it out, but I still think the interface is waaaay too crude and irritating
<whitequark>
well
<whitequark>
it's not really a different paradigm
<whitequark>
Settle() should not be explicit in testbenches. that's basically it
<Yehowshua>
Oh yeah
<Yehowshua>
Actually I appreciate that its not
<Yehowshua>
Its revealed subtle bugs for me before
<whitequark>
as in
<whitequark>
you shouldn't be able to observe unstable signal values in a testbench
<whitequark>
where by "unstable" I mean "about to change on the next delta cycle"
<whitequark>
there's a more important reason as well
<whitequark>
consider the FIFOs. in oMigen, FIFOs had simulation helpers that let you read or write a byte using `yield from`
<whitequark>
the problem was that this always consumed 2 cycles because it didn't have Settle() at all
<Yehowshua>
So with nmigen, I use sim.add_process instead of add_sync_process
<Yehowshua>
That allows me to do multiple sim.runs one after another
<Yehowshua>
while not rebuilding the AST in very large unit tests
<Yehowshua>
using sync_process add an extra Tick in between every sim.run call
DaKnig has quit [Ping timeout: 240 seconds]
<whitequark>
oh, interesting approach
DaKnig has joined #nmigen
<whitequark>
I haven't specifically designed it to be used like that, but I think it's a good way to utilize that API
<whitequark>
anyway, about those helpers
<Yehowshua>
anyways, back to your settle question
lkcl_ has quit [Ping timeout: 240 seconds]
<whitequark>
they face two problems
<whitequark>
first, they need to wait for a tick and then read the new state of the flag. hence, Settle()
<whitequark>
second, when you enter the helper, well, you don't know if the simulation has settled or not
<Yehowshua>
I wrote a reciever simulation model that was changing a signals state multiple times a delta
<Yehowshua>
Settle helped me catch that
<Yehowshua>
or maybe settle helped me create that haha
<whitequark>
the old API is probably not going anywhere for a while; there's really no technical reason to rip it out aggressively
<whitequark>
since both the old (current) API and the new (planned) API use the exact same foundation
Yehowshua has quit [Remote host closed the connection]
<whitequark>
there really should be three kinds of simulator processes
<whitequark>
one that replaces a comb function, one that replaces a sync function (similar to add_sync_process but you couldn't send any simulator commands like Settle() from it so that it doesn't do things that are impossible in hardware), and one for writing testbenches, where Settle() is automatic
<whitequark>
speaking of the bug you had
<whitequark>
I think it's entirely realistic to make an automatic race condition detector, similar to TSAN
<whitequark>
but for gateware
<_whitenotifier-3>
[nmigen/nmigen] whitequark pushed 8 commits to cxxsim [+3/-0/±13] https://git.io/JUkK3
<_whitenotifier-3>
[nmigen/nmigen] whitequark 4456d5a - _toolchain.cxx: new toolchain.
<_whitenotifier-3>
[nmigen] whitequark commented on issue #455: cxxsim: synchronous assignment inside If statement is not executed - https://git.io/JUkis
<_whitenotifier-3>
[nmigen] whitequark commented on issue #455: cxxsim: synchronous assignment inside If statement is not executed - https://git.io/JUkMk
<_whitenotifier-3>
[nmigen] BrettRD opened issue #492: How do you make a bounded up-down counter without modulo? - https://git.io/JUII0
emeb has joined #nmigen
<Degi>
Can I somehow view the generated logic three as a visual representation in nmigen simulations?
<Degi>
*tree
<Lofty>
Hmm. You could dump it to RTLIL/Verilog and use Yosys' show command to get a graphviz file
<whitequark>
yup
<Degi>
Oh cool
<Degi>
I guess its the .vcd file?
<Degi>
Hm nah
<whitequark>
./yosys netlist.il -p show
<Degi>
Awh it says that for formats different than 'ps' or 'dot' that only one module must be selected
<lkcl>
Degi: "apt-get install xdot graphviz"
<DaKnig>
ideally, as an objective for the long term, would cxxsim use the same python API as in pysim? or some different thing on the C-level?
<DaKnig>
would it even benefit from using C-level co-sim in terms of speed?
<whitequark>
DaKnig: it already does use the exact same api
<whitequark>
that's kind of the point
<DaKnig>
I see
<DaKnig>
can I see an example of using ValueCastable?
<DaKnig>
another question : I passed a Record as one of the ports of my module to sim.write_vcd; I expected the values inside it to be spilled into the gtkw file, but instead it did not show up at all. is that intended?
<whitequark>
DaKnig: ValueCastable is not merged yet...
<whitequark>
regarding Record, not quite
<whitequark>
i'm not sure if it qualifies as a bug but it definitely qualifies as inconvenience
<whitequark>
the Record redesign will fix this
<DaKnig>
what I think should be the behavior: at least have it under a separate category, or just call the signal `recordname.signalname`
<DaKnig>
should I make an issue about that? enhancement issue I mean ofc
<whitequark>
the signals inside the record are already called that
<whitequark>
it's a bit tricky to implement what you suggest right now for boring legacy reasons
<DaKnig>
I dont see them then; not even in the hierarchy view
<whitequark>
yeah, it's a bug
<whitequark>
it should either show them or crash with a TypeError or w/e
hitomi2507 has quit [Quit: Nettalk6 - www.ntalk.de]
<Degi>
Ahh I can do 'show crc' to show the submdule
<Degi>
Do things further down the toolchain do further optimizations?
<Degi>
It is a relatively long logic chain but it still meets 499 MHz heh
<daveshah>
Degi: yes, there are lots of optimisations along the way. Have a look at the opt_ family of passes which do mostly coarser-grained optimisations; then abc does some very fine-grain AIG optimisations before mapping
<daveshah>
in the case of synth_ecp5; one of the first steps is to flatten the netlist, to enable cross-hierarchy optimisations
<DaKnig>
so many optimizations are locked behind removing the processes though :(
<Degi>
Oops Dot Viewer just took a minute or two to show up.
<lkcl>
Degi; that means that you've an above-average complex design