<lkcl>
supersat, good question! :) for me it's usually ner/nur-mee-gen with the first phonetic at 1.5x normal speed.
<lkcl>
on the basis that ennnnn-mee-genn takes longer to say :)
<lkcl>
kaucasus, i'm a bare-metal vim user (over 50 xterms, no mouse-hints) myself, backed up by ctags. "ps aux | grep vim | wc" -> 3,500 is my latest record :)
<lkcl>
however you've got me curious, now.
<lkcl>
a quick debian package search shows there's extensions for things like django
<lkcl>
which would tend to suggest that certain coding conventions aren't "normally-supported-out-of-the-box"
<lkcl>
meaning, a pylint-nmigen plugin would be a likely end-result at some nebulous undefined time in the future
<lkcl>
ok, ran it... i have to say, it'll get quite tiresome, quite quickly :)
<lkcl>
C0103: Variable name "m" doesn't conform to snake_case naming style (invalid-name)
<lkcl>
these are all standard conventions or over-warnings
<whitequark>
linter tools tend to produce underwhelming results, especially for dynamic languages, for languages without strong community consensus on code style, and for eDSLs
<whitequark>
nMigen hits all three
<whitequark>
for this reason I don't recommend any linter tools as the project lead, though of course anyone using nMigen can follow their personal preferences
<Chips4Makers[m]>
I do think some form of static typing support in nMigen is not impossible, regardless of coding style/conventions.
<whitequark>
that's a different question
* lkcl
agrees
<Chips4Makers[m]>
But three of the four errors listed by Luke could be catched by static typing.
<lkcl>
it's an odd one, bringing over HDL engineering conventions to software
<lkcl>
i think whitequark (correct me if wrong?) understood you to be asking about type-enforcement on nmigen language constructs
<lkcl>
like BlueSpec does?
<Chips4Makers[m]>
Just that functions/methods expect a certain type for an argument declare it that way and that if they return a value of certain value also declare that.
<Chips4Makers[m]>
* that functions/methods that expect a
<lkcl>
you mean "import typing"?
<whitequark>
the issues start when you need higher order types
<lkcl>
code written with types drives me nuts. i'm literally unable to read it.
<whitequark>
handling parametric classes still doesn't seem impossible, but it's an amount of work comparable to, if not exceeding, that of the rest of nMigen
<lkcl>
paradoxically i'm absolutely fine with c/c++.
<lkcl>
parametric classes? can you give an example (online, one link is fine)?
<whitequark>
consider, say, AsyncFIFO
<whitequark>
the types of the signals in its interface depend on the width parameter you pass
<lkcl>
ohh yeah
<lkcl>
yeah got it
<whitequark>
handling that on its own is nontrivial but clearly possible; how to nicely integrate that with the Python `typing` module is an open question
<whitequark>
it's possible that the eventual nMigen type system will end up disjoint with the Python `typing` one, as unfortunate as that would be
<lkcl>
that'd be burdensome to maintain.
<whitequark>
that's up to the maintainers to decide
<lkcl>
true
<lkcl>
just an observation
<Chips4Makers[m]>
I agree it was a PITA. And likely not free of conflcts either; currently only check code with Pylance and I do expect problems when checking with mypy.
<Chips4Makers[m]>
Actually my PDKMaster data structures were inspired by nmigen data structures except that I don't do type checking in 'if isinstance'. I made my typing clean version of a collection class that acts both as array and member access through getattr.
<whitequark>
in general, I'm more interested in an nMigen-internal type system that would be useful for defining and checking inter-module interfaces than in integrating with Python type checkers
<whitequark>
if we can do both, that's awesome, but otherwise the former is clearly more useful for a HDL with a focus on metaprogramming
<lkcl>
whitequark: so (like Bluespec), things like, "you can't typecast a ClockSignal to a Signal without a very special converter"?
<Chips4Makers[m]>
Why I like type checking is that you get feedback, error reporting during code entry and not at run time.
<whitequark>
sure
<lkcl>
my experiences with BlueSpec - for what it's worth - were quite shockingly instructive.
<lkcl>
i worked with IIT Madras to create a pinmux autogenerator
<whitequark>
the issue is that Python isn't easily amenable to type checking in general, and nMigen complicates it by not being designed with `typing` in mind
<lkcl>
the lowRISC team used it as inspiration to create the Earl Grey fabric auto-generator
<lkcl>
with the team's *top* Engineer, we literally had to spend an HOUR each time, often twice a day, looking through the Bluespec PDF to find a workaround for type-casting
<lkcl>
it got so embarrassing, the amount of his time being taken up, that i had to sometimes spend one or two days doing absolutely nothing
<whitequark>
well-designed type systems let you work faster, not the opposite
<whitequark>
(without making any particular statement on Bluespec's, here, as I haven't used it myself)
<lkcl>
well, BlueSpec as you are no doubt aware provides a 100% guarantee that the resultant output is 100% synthesiseable (if it compiles).
<lkcl>
and because it's in Haskell they have a Formal Correctness guarantee behind that simple-sounding assertion
<lkcl>
the IIT Madras team's first ever ASIC, in 22nm, worked first time. none of them had even ever done an ASIC before
<lkcl>
it was a stunning achievement
<whitequark>
Verilog sets a really low bar, but yes
<lkcl>
:)
<lkcl>
one of the things i am *so* delighted with about nmigen is the deterministic behaviour
<lkcl>
combined with the flexibility of _not_ having typing interfere with what needs to be done
<whitequark>
again, if your type system interferes with your work, get a better type system
<lkcl>
Cat(*list).eq(a_Record/a_Signal) is one of my favourite elegant constructs
<whitequark>
just like the language itself, the type system should feel like an extension of your mind, not something tacked on later to restrict it
<lkcl>
that's where Bluespec falls over, badly, making it something that Academics love
<whitequark>
(C and to some extent C++ set a really low bar here)
<lkcl>
(and mission-critical environments)
<lkcl>
if nmigen was used extensively in mission-critical commercial environments i could see a genuine need for type-casting / type-checking
<whitequark>
we already have an ad-hoc type system in nmigen-boards
<lkcl>
would it help with Formal Correctness Proofs at all?
<whitequark>
and then a half of another one in nmigen-soc
<lkcl>
ohh, the Pins and Attrs specs?
<whitequark>
once your designs get complex enough, the choice isn't "do you use a type system or not", it's more of "do you design a type system or let downstream projects grow their own organically"
<lkcl>
we reaally need to move the pinmux / auto-peripheral-fabric-generator forward in Libre-SOC
<lkcl>
basically a port of the work i did for IIT Madras to nmigen
<whitequark>
no, the nmigen_boards.resources package
* lkcl
investigating
<whitequark>
e.g. SPIFlashResources looks like a constructor function, but it's really a type
<whitequark>
because it defines an interface that an SPI flash resource is expected to adhere to, whether it is being defined with `SPIFlashResources` or not
<whitequark>
in nmigen-soc, there's for example `wishbone.Interface`, serving a very similar role
<lkcl>
those look remarkably similar to what i did for IIT Madras
<whitequark>
these are very basic design elements, yes
<lkcl>
except the focus there was on outputting the type information into CSV / JSON files
<whitequark>
(which makes it a bit surprising that so few HDLs include them out of the box)
<lkcl>
and... i think.... looking at them... it *should* be very easy to pick up those JSON/CSV files and automatically call the required type/function (SPIFlashResources, etc)
<lkcl>
btw although it was AXI-based, the work for IIT Madras even auto-generated memory fabric
<lkcl>
allocated and connected up IRQs, and allocated Memory-mapped peripheral space
<lkcl>
it worked
<lkcl>
but the end result was some of the worst-maintainable code i've ever written
<lkcl>
i won't be making that mistake again! and, very unfortunately, i've seen it done at least 2 times by other HDL teams.
<lkcl>
so i'm delighted that nmigen-boards and nmigen-soc exist, and are well-written
<lkcl>
it'll make the task of writing a fabric-SoC-auto-generator a hell of a lot simpler and cleaner
<whitequark>
that's the intent, yes
<lkcl>
i don't know if you can imagine trying to deploy PHP-style "template" techniques, five to six levels deep, using __str__ overrides and code-fragments, outputting Bluespec source code (or Verilog source code in the other projects i've seen)?
<lkcl>
once you've done it, and it seems so... natural, the results make you want to cry :)
<whitequark>
I can
<whitequark>
I've seen... no, five to six levels deep is about as bad as I've seen
<lkcl>
where instead with nmigen, the intent here is to have CSV/JSON files that are easy to write on the one hand (and have auto-generators creating PDF Technical Ref Manuals, device-tree files, GPIO header files for u-boot and linux kernel - this is exactly what EarlGrey in OpenTITAN does)
<lkcl>
and on the other, dynamically auto-generate nmigen-soc/boards fabric interconnect *at runtime* but *not* output actual python code-fragments
<lkcl>
actually instantiate the class instances right there, on-demand, from reading the (same) JSON/CSV files
<lkcl>
Chips4Makers[m] you saw the hoops i had to go through when trying to do that with Litex :)
<lkcl>
the "industry standard" practice of hand-writing JTAG Boundary Scan, hand-writing peripheral interconnect, and then the IO ring / corona, when they can all be auto-generated from a single simple JSON/CSV file, seems to be to be quite, quite mad :)
<lkcl>
anyway. must get on
<Chips4Makers[m]>
Actually for me the place to do this is not in JSON/CSV but in the nmigen Platform class.
<lkcl>
the reason i chose to implement a fire-break of JSON/CSV is so that there is a machine-readable format / spec for other tools to use
<lkcl>
someone may wish to write a "device-tree writer" in a totally different (non-python) language
<lkcl>
or, a PDF-specification-creator, again, not in python at all.
<lkcl>
i _personally_ prefer python but saw it as an impediment to empowering others if restricting things entirely to python.
<lkcl>
but yes, the plan is to *pick up* the JSON/CSV files and create a totally dynamic nmigen Platform class
<lkcl>
exactly how litex works, fundamentally, just without migen and without wildcard imports which i find are again a major impediment for code-navigation.
<lkcl>
i lost count the number of times i had to use "grep -r" to cope with litex's wildcard imports
<lkcl>
not helped by the fact that the class names are identical (dozens of classes named "Platform").
<Chips4Makers[m]>
I would go the other way, add JSON/CSV export functionality to the Platform class.
emeb has joined #nmigen
<whitequark>
I agree with Chips4Makers and this is something that's already planned
<whitequark>
(not in that exact form perhaps, but conceptually so)
<lkcl>
that's... a major redesign and throwing away a significant body of work that's been in development and active use for 3 years, unfortunately.
<lkcl>
and is already tied in to the Libre-SOC design
<lkcl>
now, that's not to say that it isn't possible (because of the very abstraction / sub-division)
<lkcl>
but it would be... quite strange to throw out existing proven code and put in extra work to replace it without a very good reason
<lkcl>
that was, exactly as the comments say, a "get-it-done" hack
<lkcl>
the key function is pinspec() which, duh, creates a PinSpec object
<whitequark>
the needs of Libre-SOC and the needs of the nMigen community at large are not necessarily the same
<lkcl>
the similarity to nmigen-boards resource/type functions should be obvious / clear
<lkcl>
we're developing ASICs and developing for FPGAs.
<lkcl>
i've found that those "needs" are usually because other people are significantly behind the advancements that we're pushing at an accelerated pace
<lkcl>
and, being under time and financial pressure, it results in mis-communication.
<lkcl>
it's not a "needs" issue at all, it's a time/communication issue
<lkcl>
and because we're at the fore-front, people in the commercial ASIC world are noticing
<lkcl>
(not the open hardware community)
<whitequark>
that's quite an arrogant statement
<lkcl>
that in turn means that there are public conversations i *can't have* right now
<lkcl>
arrogant is a combination of ignorance and ego.
<lkcl>
if you know differently, i'm quite happy to be told otherwise
<lkcl>
which is the total opposite - by definition - of "arrogant"
<lkcl>
this because, in a practical sense, we're under time pressuer
<lkcl>
consequently if you know of efforts that would save us time and resource, i *really* want to hear about them.
<lkcl>
i'm not here to be everybody's friend, i'm here to get an engineering job done.
<lkcl>
under time pressure. that means accepting reality and cutting to the chase. even if that's viewed as "not very nice" or "arrogant".
<lkcl>
i do appreciate it's quite pathological.
<lkcl>
now, i don't mind *at all* collaborating (and saving a huge amount of time in the process), we've funding coming out of our eyeballs to help make things happen
<lkcl>
more people means more uptake, and so on.
<lkcl>
but if i can't trust people to listen and include us in the community designs, then we have no choice, for our customers and business relationships that need to be satisfied, to leave everyone else behind.
<lkcl>
which would be rather sad and unfortunate
<lkcl>
i can't give specifics there because it's commercially confidential.
<Chips4Makers[m]>
I am with whitequark on this one. I don't see how JSON/CSV fits in the nmigen framework. That said I think once proper support is in Platform using your JSON/CSV on *Platform object should be trivial.
<agg>
yea, some custom csv format is fine for one specific project but i'd rather have those features inside nmigen itself, and you can always write (or already have) a parser for that format for your project that loads it into the nmigen stuff
<agg>
it's not throwing away your existing work, which already can't be part of nmigen
<agg>
and it sounds like it wouldn't be difficult for you to keep using csvs but load them into the python, as you already do, right?
<agg>
not every project using nmigen is trying to solve the same sorts of problems as libresoc, so they have different needs due to being different projects
<Sarayan>
libresoc is the project that does powerpc-derived cpu cores and gpus?
<agg>
i'm sure you've had a bunch of ideas that could be very useful! and one way or another, if it makes sense, perhaps the concepts can end up in nmigen, and maybe over time you can port to using the nmigen-provided implementations, right?
<jn>
Sarayan: yes
<ktemkin>
lkcl: “i’m not here to be everyone’s friend” <— we *are* still going to need you to be kind and courteous to our maintainers; there’s enough load on them already without having to constantly repeat that nMigen exists for purposes other than to support libresoc, or making them repeatedly re-justify decisions that have been made already
<ktemkin>
(just be aware: if we find there’s anyone who can’t be appropriately respectful, or who winds up continuously adding stress or workload in their communications — including ones outside IRC — they’ll be removed from community spaces, for everyone’s good)
peepsalot has joined #nmigen
peeps[zen] has quit [Ping timeout: 245 seconds]
emeb has quit [Ping timeout: 265 seconds]
emeb has joined #nmigen
<lkcl>
ktemkin, of course. and in return i expect people likewise to be respectful of the needs that i have.
<lkcl>
which has, to be absolutely honest, been really stretched at times.
<lkcl>
i haven't said anything because i've been too busy.
<lkcl>
consequently people *assume* i am the one being the... {insert inappropriate derogatory word}
<lkcl>
ktemkin, i have a goal to achieve. if i were to be a {insert completely inappropriate derogatory word}, that would be counter-productive, would it not?
<lkcl>
therefore, logically and by deductive reasoning we *may* conclude that i will, in fact, be respectful - and expect others to be likewise
<lkcl>
understood?
<ktemkin>
getting the solution to a problem you want is not a "need"; it's not nMigen's purpose to help you solve your exact problems in the way you want to solve them; but rather to be a tool for the broader community in a direction established by its maintainers
<ktemkin>
a primary requirement for that to happen is that maintenance does not become a burden on its maintainers' and designers' mental healths; it's quite necessary for everyone involved to not be mentally harmed by getting things done
peeps[zen] has joined #nmigen
<ktemkin>
don't confuse not giving you what you want with "being disrespectful" -- you're neither entitled to anyone here's work nor entitled for nMigen to go in a direction that makes your job easier
peepsalot has quit [Ping timeout: 265 seconds]
bvernoux has quit [Ping timeout: 245 seconds]
<ktemkin>
"therefore, logically and by deductive reasoning we *may* conclude that i will, in fact, be respectful" <-- I certainly hope you will. Keep in mind that an important part of being respectful is not pushing back once maintainers have tendered a decision. Pushing back against them makes the role of being a maintainer a lot more stressful -- and I'm personally not willing to risk that load contributing to whitequark burning out.
<ktemkin>
Discussion of decisions before they're fully made is fine; but once a final decision *is* made, please be respectful of it and respectful of e.g. wq's time and mental health.
kaucasus has quit [Quit: Client closed]
mwbrown has joined #nmigen
<mwbrown>
lofty: you were right, the evaluation warning on Quartus went away without a peep, haha
<mwbrown>
like it never even happened
<lofty>
Quality software, ain't it?
<lofty>
And also Mistral got some improvements, so that's nice
<mwbrown>
I saw! There was some buzz on twitter about adding MLAB support. Would love to try out Mistral one of these days
<mwbrown>
unrelated: I think the onebitsquared discord bridge bot died
<mwbrown>
as of 10/2, possibly related to the Let's Encrypt root change (I just had to fix ZNC myself)
<whitequark>
cc Qyriad
<Qyriad>
I think we're not even the ones running that bridge anymore; I'll do some poking, thank you