<cr1901>
What's a singleton in the context of FPGA toolchains?
<cr1901>
>how are singletons supposed to be handled?
<mwk>
a one-off special block on the device
<mwk>
eg. the hard CPU in devices that have one, the special block that allows you to connect to JTAG and handle custom opcodes, the special block that controls FPGA startup procedure, ...
<mwk>
basically any kind of cell that there can only be one of
<mwk>
the underlying problem here is that, how to put it, these blocks often have interfaces that are made of many "sub-interfaces" and you want to connect to them from many points across your hierarchy
<mwk>
eg. a hard CPU block that is represented as one cell in the final netlist actually has multiple AXI buses (in both directions), IRQ lines, clock inputs/outputs, and whatnot; the JTAG primitive on (at least early) Xilinx devices has actually two separate interfaces for adding two distinct opcodes; the STARTUP primitive is basically a loose grouping of several functions which you may want to poke from various
<mwk>
parts of the design
<cr1901>
This sounds like outside the scope of what nmigen can handle right now?
<mwk>
so for good abstraction, you want to actually request the particular sub-interface you need within a module, then have the flow gather all the connections that should go into a given singleton, instantiate it exactly once, and insert termination connections for any unused functions
<mwk>
yes, hence why we're talking about it as a future direction
<cr1901>
For the MachXO2 EFB, you get a single wishbone interface for all the hard IP... what would be nicer is to have some address decoding that's not exposed to the user that allows you get get a register range for the hard IP you actually want >>
<cr1901>
(plus a wrapper IP for accessing the flash since accessing the flash just plain sucks without it)
<cr1901>
But that feels like a nmigen-soc thing more than something nmigen proper should handle
<mwk>
mmm, that's a somewhat harder case of actually having to add logic
* cr1901
is minddumping
<mwk>
while the Xilinx primitives I know are really of the "just split up the pin groups" kind
<cr1901>
Not expecting/looking for solutions, just want to type out the stream of text before I forget :)
<_whitenotifier-1>
[YoWASP/yosys] whitequark pushed 1 commit to develop [+0/-0/±1] https://git.io/JrqLE
<mwk>
also there's another problem for Xilinx specifically: nMigen itself is instantiating the STARTUP primitive, to implement safe synchronous initialization behavior, and this prevents any nMigen code from instantiating it manually (despite the nMigen-inserted code only observing one output of the primitive)
<mwk>
which means it has to be ficed within nMigen somehow
<cr1901>
That's not ideal for someone who doesn't know they're singletons (or there's a very limited amount that PNR can actually place).
<d1b2>
<TiltMeSenpai> Xilinx aside, nmigen is just python, why not handle nmigen singletons as python singletons?
<mwk>
that... is completely not a solution to anything?
<tiltmesenpai[m]>
hmm maybe I need to read the conversation
<tiltmesenpai[m]>
can you not wrap the nmigen Instance in a python singleton? Though that might not solve multiple things trying to claim the interface
<mwk>
what even is a python singleton?
<mwk>
like, that's not a first-class language concept in python
<mwk>
either way, the point isn't to implement an Instance that prevents itself from being created twice; the point is to merge the uses of it throughout the design
<mwk>
think multiple calls to the Instance constructor with disjoint i_/o_/a_/p_ arguments
<mwk>
or maybe even not disjoint — there's no reason not to use a single output in multiple places
<cr1901>
I think Python singleton would be analogous to the "GoF Design Patterns" singleton. Tho I have NFI how to impl that in Python
<cr1901>
or lazy_static in Rust
<cr1901>
Or (better) OnceCell
<mwk>
yeah, but that doesn't solve anything
* cr1901
shrugs :P
<cr1901>
"If nmigen already instantiated this and you ask for a second one, raise an exception"
<cr1901>
oh wait, I guess you could do "on error resume next" for that
<mwk>
in current nMigen you already get an error if you instantiate a singleton twice, in PnR
<cr1901>
Well, yes. But that's what I was thinking of when I said "That's not ideal for someone who doesn't know they're singletons"
<mwk>
moving it to happen in nMigen doesn't accomplish all that much; the point is to have functionality that *allows* this, by merging the instantiations
<cr1901>
Feels like the earlier the error is, the less logs you have to look at to diagnose
<cr1901>
and PNR is fairly late
<mwk>
true, but also: this is *not the point*
<cr1901>
ahhh
<cr1901>
Will read logs more closely, I stopped when I got to my question re: "what is a singleton"
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #nmigen
<cr1901>
Lovely. I resize my client, and it crashes.
<cr1901>
Welp, scrollback is gone lmao
<mwk>
you know this channel has public logs, right?
<cr1901>
Yes. I wanted the scrollback open to find something else
<whitequark>
mwk: re nMigen instantiating `STARTUP` primitives: it's not a hard blocker because this happens only if you don't instantiate the `sync` domain yourself
<whitequark>
but I agree that nMigen doing this is a very good argument in favor of having first-class singleton support
<Sarayan>
I think more most non-ff, non-ram blocks, and if we limit to the cyclone v, we can reuse a simplified form of the intel primitives for mistral
<Sarayan>
simplified as in "drop the inoput/output registers, let the toolchain infer them when needed"
bvernoux has joined #nmigen
<Sarayan>
Another style question: Imagine I'm implementing an IntelPlatform method to grab a dsp block. Said block has 5 possible modes (plus a number of parameters) like 3x9x9, 2x17x18, 1x27x27 and two more I forgot. Should I 1/have 5 methods, one per mode 2/add a string parameter 3/add an enum parameter, but I'm not sure how one create and uses enums 4/something else?
<whitequark>
that's not currently something that platforms are expected to provide
<Sarayan>
they provide ffs but not dsp blocks?
<whitequark>
at the moment, the functionality of `<Vendor>Platform` is just things that other parts of nMigen need
<whitequark>
they don't provide FFs so much as IO gearboxes
<Sarayan>
ok, then where do I put the method that makes Instances
<whitequark>
you can request DDR FFs via `platform.request`, so the vendor platforms have to know how to lower that
<whitequark>
that
<whitequark>
*again, helpers for generating DSP blocks are not currently something that platforms are expected to provide
<whitequark>
it's not out of scope, but it would require a design cycle and an RFC
<whitequark>
similar to the other feature like that, helpers for generating PLL blocks
<Sarayan>
Something somewhere has to wrap creating that kind of stuff into something sane
<Sarayan>
yeah, pll is the same
<Sarayan>
and hps, and etc
<whitequark>
right now that's not something that nMigen does
<whitequark>
that's something I want to change, but this change would be separate from adding Mistral support to `IntelPlatform`
<whitequark>
since it would add a stable public API with a support obligation
<Sarayan>
my aim is to be able to write not-mister-but-on-the-same-hardware cores 100% in nmigen
<Sarayan>
because I hate verilog, and vhdl is not my best buddy either
<Sarayan>
and avoid quartus along the way because urgh (plus you probably can do insane things when you understand the hw that you can't do with quartus, like leverage partial reconfiguration for state saving)
<Sarayan>
that requires being able to reach the useful resources, e.g. plls, dsps, ram and hps comms.
<Sarayan>
so any hint on how things should be done would be quite helpful
<whitequark>
sure
<Sarayan>
trick is, it's very cyclone-v specific, so I'm really not sure what clean means
<whitequark>
you can always use `Instance`s in your code, right?
<whitequark>
and wrap them in any way you'd like
<Sarayan>
yeah, but it hinders readability quite a lot
<Sarayan>
because it's not semantic
<whitequark>
is it different from the other platforms currently supported?
<Sarayan>
I'm not sure
<Sarayan>
grepping on pll finds nothing
<Sarayan>
grepping on dsp not much either
<whitequark>
no other platforms give you helpers for PLLs, DSPs, or CPU cores
<whitequark>
for memories you use the generic nMigen `Memory` primitive
<Sarayan>
*something* should
<Sarayan>
yeah, memory should be inferred
<whitequark>
I agree that helpers for PLLs or DSPs would be useful
<whitequark>
I won
<Sarayan>
it's better everywhere, especially for cxxrtl
<whitequark>
*I won't accept them upstream as a part of Mistral support for `IntelPlatform`
<whitequark>
in my view, these are two unrelated improvements, only one of which requires a design cycle
<Sarayan>
when I implement it it's going to generate instances that are compatible between quartus and mistral if at all possible (and it's much more possible for these blocks than ff/gpio it seems)
<Sarayan>
so it's essentially orthogonal
<whitequark>
to expand a bit, a design for PLL/DSP helpers would take into account every currently supported platform, and possibly some currently unsupported ones
<whitequark>
it's a large collaborative project drawing on the experience of people working with many different device families
<Sarayan>
hmm, there's a fundamental point on which we may not be entirely aggreeing
<Sarayan>
you want generic stuff, like Memory, and that makes perfect sense
<whitequark>
no
<whitequark>
I want both
<Sarayan>
but I'd also want target-specific stuff, which may or may not be used to implement the generic stuff, but is independant in any case
<whitequark>
so I want an abstraction, yes, but I want the platform-specific helpers to be consistent in their design between the platforms
<Sarayan>
I'm not sure that's possible, honestly
<Sarayan>
I mean, dsp, you're not even consistent within the intel family afaict
<Sarayan>
even when dropping registering
<whitequark>
if it's not, then I'm not sure if such platform-specific helpers should be part of core nMigen at all
<whitequark>
because they'll end up being just collections of code that the people contributing happened to find useful, with no other overarching design intent
<Sarayan>
I see it a lot like the mmx support in compilers. You can do asm(), but that sucks, you can have the compiler generate stuff, especially in amd64, but you also have the specific compiler-known methods to have something in the middle
<Sarayan>
(I forgot the name of those methods)
<whitequark>
intrinsics?
<Sarayan>
yeah that
<Sarayan>
it would be the intrinsics of cycloneV in a way
<whitequark>
mm, intrinsics are roughly equivalent to what `Instance`s are
<Sarayan>
Nah, Instance is a lot closer to asm than intrinsics, I feel
<whitequark>
inline assembly, in some compilers, is based on direct textual substitution, and in others it approximates that
<whitequark>
with nMigen that'd be analogous to inline Verilog
<Sarayan>
as in nmigen has to trust what you put in the Instance, while an intrinsic, in nmigen's case, would know the signal sizes and presences, could verify the compatibility of settings
<whitequark>
intrinsics let you pull constructs otherwise accessible only in assembly into C or C++ code by bridging them to the C/C++ type systems and expression syntax
<whitequark>
that's something I want `Instance` to eventually be able to do
<whitequark>
it's currently not because, well, it's an enormous amount of work to extract this data
<whitequark>
but it's in-scope
<Sarayan>
well, I can do it for the cyclonev, that would give you a start
<whitequark>
that still requires a design cycle first
<whitequark>
(the other thing is that nMigen's type system is weaker than even C's)
<whitequark>
I also think that maybe this kind of database should be collected as a part of the Yosys project
<whitequark>
Yosys has blackbox information already, yes, that gives you list of ports and their directions
<whitequark>
doesn't give you the clock-data relationship between ports
<Sarayan>
synthesis is going to be "interesting" anyway
<whitequark>
so maybe we can get that in Yosys and then extract it in nMigen, via nmigen-yosys or something
<Sarayan>
well, given the need for design cycles, I'm going to do something that's probably going to start with an import cyclonev as cv and I'll port that to whatever all this becomes. And we'll have it as an information source meanwhile
<whitequark>
sounds good!
<Sarayan>
and if I end up REing the cyclone 10 too (you know what they say, it's only the first time that hurts) we'll see how things generalize, if at all
<lkcl>
mwk: there's two different types of python singletons.
<lkcl>
1) you declare a global variable inside a python module. you can actually put the "global" keyword in front of it to make it clear that's what you're doing
<lkcl>
2) this is the really odd one: you declare a function with a *mutable type* as its default parameter, make sure that it's clear in the documentation never to override that parameter, and return it
<mwk>
lkcl: oh for gods sake, did anyone ask you to explain?
<lkcl>
then when you want to access that (global, singleton) object, you do so by calling the function which gets it
<lkcl>
this is regularly done by mistake when people do things like "def fred(x, y, z=dict()): ..."
<lkcl>
z's (mutable dict) parameter *is* a python singleton
<lkcl>
mwk: i am very shocked by how rude your response is, mwk
<lkcl>
why did you feel compelled to be so rude and make me feel unwelcome here?
<whitequark>
what makes one feel unwelcome is being explained, unprompted, things one already understands
<mwk>
... after explicitely saying, in the same backlog that prompted it, that *actual singleton pattern is not an answer to anything*
<whitequark>
it's even worse if it's unrelated to the question being discussed, yes
<lkcl>
except there's ways to do that are inclusive and welcoming and there are ways that are deeply offensive
<whitequark>
it shows a lack of consideration for the person you're talking to, and to everyone else in the channel
<lkcl>
mwk, if you had said, "thank you for explaining, but i already know that. also, you may not have got round to reading the full thread yet, here is a reminder"
<lkcl>
that would have been respectful, wouldn't it?
<lkcl>
i'm sorry you feel clearly frustrated by me not having completely finished reading the entire thread before responding
<lkcl>
i had got up to here: "<mwk> what even is a python singleton?"
<Sarayan>
in any case a python singleton wouldn't at this point help because in nmigen the modules are setup in a tree, not a dag
<lkcl>
Sarayan: ahh ok. i understand. and that would be quite a big intrusive change throughout nmigen.
<Sarayan>
perhaps it sohuld be a dag, perhaps the solution would be something else, but in any case it's really not supported at this point, sadly
lkcl was kicked from #nmigen by whitequark [Kicked by @whitequark:matrix.org : your behavior has consistently shown a lack of consideration and respect towards others in this channel]
<whitequark>
hm, what happened here exactly
<mwk>
hm?
<Sarayan>
err, you're the one asking? I guess your cyborg part did a kick without telling you ? :-)
<lkcl>
* You have been kicked from #nmigen by whitequark (Kicked by @whitequark:matrix.org : your behavior has consistently shown a lack of consideration and respect towards others in this channel)
lkcl was banned on #nmigen by ChanServ [*!*@we.will.rock.you.bnc4you.xyz]
lkcl was kicked from #nmigen by ChanServ [User is banned from this channel]
<mwk>
whitequark: it shows up as a simple kick on the irc side
<mwk>
matrix display glitch?
<whitequark>
did it via ChanServ now
<whitequark>
I don't know. some sort of Matrix glitch
* anuejn
applaudes
<ktemkin>
well, I'm glad he's gone; he was starting to be quite the antagonist
kaucasus has quit [Quit: Client closed]
xiretza[m] has quit [Write error: Connection reset by peer]
psydroid has quit [Read error: Connection reset by peer]
programmerjake has quit [Write error: Connection reset by peer]
david-sawatzke[m has quit [Read error: Connection reset by peer]
mikolajw has quit [Write error: Connection reset by peer]
jevinskie[m] has quit [Read error: Connection reset by peer]
Niklas[m] has quit [Read error: Connection reset by peer]
RobTaylor[m] has quit [Read error: Connection reset by peer]
dcallagh has quit [Read error: Connection reset by peer]
tiltmesenpai[m] has quit [Read error: Connection reset by peer]
emilazy has quit [Write error: Connection reset by peer]
kaji has quit [Write error: Connection reset by peer]
pho has quit [Write error: Connection reset by peer]
Chips4Makers[m] has quit [Read error: Connection reset by peer]
CarlFK has quit [Write error: Connection reset by peer]
cesar has quit [Read error: Connection reset by peer]
jamwaffles[m] has quit [Read error: Connection reset by peer]
emilazy has joined #nmigen
whitequark has joined #nmigen
cesar has joined #nmigen
kaji has joined #nmigen
psydroid has joined #nmigen
Niklas[m] has joined #nmigen
CarlFK has joined #nmigen
dcallagh has joined #nmigen
jevinskie[m] has joined #nmigen
programmerjake has joined #nmigen
mikolajw has joined #nmigen
Chips4Makers[m] has joined #nmigen
tiltmesenpai[m] has joined #nmigen
david-sawatzke[m has joined #nmigen
RobTaylor[m] has joined #nmigen
xiretza[m] has joined #nmigen
jamwaffles[m] has joined #nmigen
pho has joined #nmigen
emeb_mac has joined #nmigen
jfng[m] has joined #nmigen
emeb_mac has quit [Quit: Leaving.]
<key2_>
Hi :)
key2_ is now known as key2
<whitequark>
hi key2_ !
peeps[zen] has joined #nmigen
peepsalot has quit [Ping timeout: 245 seconds]
<FL4SHK>
Message for lkcl when they read the backlog: Yes, it's "natural and obvious" to expect that `ElemRef` would "just work" with `Cat`, `Repl`, `Mux`, and other nMigen AST language constructs.
<FL4SHK>
Why? Because it's just slices of a `Signal`
<Sarayan>
FL4SHK: lkcl got kickbanned, you're talking to the abyss
<FL4SHK>
Oh my
<xiretza[m]>
well, the channel still has public logs
<_whitenotifier-1>
[nmigen-boards] bl0x opened pull request #185: Add support for cmod_a7 board. - https://git.io/JrV6X
<FL4SHK>
neat
<FL4SHK>
I thought about buying a bunch of those
<FL4SHK>
And building like, a SIMD machine.
<tiltmesenpai[m]>
hmmm just a thought experiment, would nmigen have uses for the py 3.10 structural pattern matching?
<tiltmesenpai[m]>
I don't even know how features requiring a newer version of python than the minimum supported would even work but pattern matching is shiny and I wanna poke it
<mwk>
would you like to use pattern matching within nmigen itself, or in code written using nmigen?
<tiltmesenpai[m]>
I think the former, though practically speaking it would likely have to be a wrapper around nmigen constructs
<mwk>
I don't quite see any applications in the second case
<tiltmesenpai[m]>
something like transformation passes around matching a Signal turning into a Switch, or matching a state turning into an FSM
<whitequark>
that's not really nmigen's job
<mwk>
nmigen doesn't work by converting python control structures to its internal IR; that's why you use `with m.If`, not `if`
<tiltmesenpai[m]>
yeah I'm just thinking about how it would work, I don't think it's a serious suggestion
<Sarayan>
Sometimes I wonder if I'd classify nmigen as HDL or HDL generator
peepsalot has joined #nmigen
peeps[zen] has quit [Ping timeout: 252 seconds]
<tiltmesenpai[m]>
hmm actually ignore me, it looks like the match statement is designed to be a control structure, not so much to emit a data structure describing the entire match structure
<tiltmesenpai[m]>
so I mean it might be possible to integrate structural matching into nmigen but it would 100% be abusing the way python works
<_whitenotifier-1>
[nextpnr] whitequark commented on issue #2: All errors become WASM traps - https://git.io/JrHPg
<_whitenotifier-1>
[nextpnr] whitequark edited a comment on issue #2: All errors become WASM traps - https://git.io/JrHPg
<_whitenotifier-1>
[nmigen-boards] bl0x synchronize pull request #185: Add support for cmod_a7 board. - https://git.io/JrV6X
<_whitenotifier-1>
[nmigen-boards] bl0x commented on pull request #185: Add support for cmod_a7 board. - https://git.io/JrQqm
<_whitenotifier-1>
[nmigen-boards] bl0x synchronize pull request #185: Add support for cmod_a7 board. - https://git.io/JrV6X
<lofty>
Well, add another person to the list of people more comfortable in this channel now lkcl's gone
<cr1901>
I recently realized who lkcl was- from another project- and I remember reading on another IRC channel that he was difficult to work with there as well. Didn't say anything because this is all I remember (years ago), and "I remember hearing" is nebulous.