<ZirconiumX>
nMigen does a lot of implicit widening
<ZirconiumX>
Which is a good thing, to be honest
<Sarayan>
yeah
Asuu has joined #nmigen
Asu has quit [Ping timeout: 272 seconds]
<MadHacker>
Perhaps a .safe_eq that makes noises and doesn't widen?
<MadHacker>
maybe "strict" not "safe".
chipmuenk has joined #nmigen
<awygle>
with m.Strict():
<awygle>
>_>
<MadHacker>
I think you'd need to unstrictify rather frequently, and not necessarily have it carry throughout the hierarchy. Maybe .seq and keep the typing down. :)
<awygle>
with m.DefaultNetType("none"):
<ktemkin>
with m.ThisTimeIMeanIt():
<ZirconiumX>
with m.Unsafe():
<tpw_rules>
awygle: augh
<ktemkin>
with m.fStrictVolatileBitFields():
<MadHacker>
with m.MakeMeSuffer(): at this point.
<awygle>
Lol I like ZirconiumX's suggestion
<ZirconiumX>
:3
<tpw_rules>
with m.Funsafe()
<ZirconiumX>
I'm actually not sure which is more cursed: opt-in unsafety or opt-in safety
<whitequark>
ouch
* whitequark
carefully marks the last four hours as a superfund site
<daveshah>
better put the irc logs in a high temperature incinerator
<whitequark>
i think eq with different sizes should be a lint because we can never turn it into a hard error in legacy code
<whitequark>
however, it could have a few different sub-lints, some of them deny-by-default (Werror for the folks who know C)
<whitequark>
making it a hard error in nmigen code but not nmigen.compat code is of course technically easy but it would impede any migration of code so it seems bad conceptually
<whitequark>
making it a lint makes it easy to gradually upgrade
Guest30583 has quit [Quit: Nettalk6 - www.ntalk.de]
<awygle>
when not trolling, i agree with you
thinknok has quit [Ping timeout: 272 seconds]
chipmuenk has quit [Quit: chipmuenk]
<awygle>
whitequark: is this a good time to chat about either nmigen-stdio streams or an nmigen ILA?
Asuu has quit [Quit: Konversation terminated!]
<whitequark>
let's talk about an ILA
<whitequark>
and about streams once i'm done with cxxsim, which should be not far off
<whitequark>
streams are... hefty
<awygle>
okie dokie
cr1901_modern has left #nmigen [#nmigen]
<awygle>
so i need an ILA
<awygle>
i have the start of a litescope port
<awygle>
but i'd like to plug it in more deeply
<awygle>
my first-order thought was "eat a yosys post-synth netlist, poke extra wires in for ILA purposes" (details intentionally left vague)
<awygle>
but i expect you have some Ideas
<whitequark>
yeah. why go through yosys?
<whitequark>
i mean, that'd mean we can only use ILA with the FOSS toolchain
<whitequark>
plus yosys doesn't let you use hierarchical net names (and is very ill-structured to add proper support for that) so you'd need to thread the ports manually
<awygle>
the reason i was thinking yosys was because you really want to be able to look at wires post-synth
<whitequark>
and if you don't `synth -noflatten` then you no longer have any correspondence between nmigen signals and yosys signals
<whitequark>
hm
<awygle>
and idk how accessible that stuff is for the proprietary toolchains
<whitequark>
do you want to be able to insert probes without resynthesis?
<awygle>
ideally, yes
<whitequark>
do you have any design that takes a significant time to synthesize in yosys, compared to pnr?
<awygle>
no
<awygle>
i don't actually care about the resynthesis, just about net name stability
<whitequark>
can you elaborate?
<daveshah>
Doing insertion post synth is the first step to post pnr insertion
<whitequark>
i'm imagining that you would insert probes by specifying the nmigen Signal objects, in which case the actual name is moot. those are still deterministic
<daveshah>
Ideally using partial reconfiguration in the long run
<whitequark>
daveshah: i agree, but it seems foolish to implement this in nmigen now while the backends are clearly not ready, and potentially have to redo everything later
<whitequark>
while also not having any simpler ILA at all
<daveshah>
Yes, makes sense
<whitequark>
for example, i don't yet know how to trace signals from nmigen to nextpnr with flatten in synth
<whitequark>
but working on cxxsim will involve doing more or less that
<whitequark>
should we delay adding an ILA until cxxsim lands? I don't see why we should
<awygle>
(sorry, phone call, back in a sec)
<daveshah>
The ILA core, triggering, etc is presumably all common anyway
<daveshah>
Starting with pure nMigen does seem sensible
<daveshah>
The other advantage of post synth insertion would be being able to see inside Verilog cores
<awygle>
okay back. i see two advantages to post-synth insertion. the first is as dave says, seeing inside Instances, which iiuc is basically impossible with a pure nMigen design
<whitequark>
not quite
<whitequark>
you can use late bound wires (I just came up with that term)
<awygle>
the second is that nMigen is intentionally supportive of metaprogramming-type stuff which it seems to me would have the potential to make it tricky to track a signal to a wire. it's the same problem Verilog has with `generate for` type constructs but writ much larger.
<whitequark>
so since the bulk of the logic is written in nmigen (unless you have a radically different plan in mind) you can emit wires for probes of things nmigen can't see that yosys can connect later
<whitequark>
(perhaps with something like _TECHMAP_REPLACE_)
<daveshah>
There is a hierconn attribute that is in this direction
<whitequark>
as for metaprogramming, what do you mean it's tricky to track a signal to a wire?
<daveshah>
Essentially for fudging hierarchical referencing, but it only works with flatten atm
<whitequark>
verilog.convert_fragment returns two things, the verilog text and a mapping from signal objects to hierarchical wire names
<awygle>
a third advantage (though perhaps not a relevant one here) is that if the design core was at the yosys level and only the interface was in nmigen, it would be useful to all OSS toolchains, not just nmigen. which would be nice if we can swing it
<whitequark>
daveshah: oh cool! so i think that can basically work as-is
<whitequark>
i'm 100% on board with pushing generic flow improvements to yosys. that's why i did cxxrtl the way i did it
<awygle>
mhm
<whitequark>
there was some pushback towards making it nmigen-only
<whitequark>
but it's not clear that the best place for ILA to live in is yosys synthesis pipeline
<awygle>
sure, that's why i said "my first-order thought", and wanted to discuss it with you and dave, who understand such things much more deeply than i do right now
<whitequark>
makes sense
<daveshah>
It seems like this should be one of the options down the line, not necessarily the only one
<whitequark>
yep, i agree
<awygle>
i agree with that yeah
<whitequark>
awygle: does the information about the name map returned from convert_fragment influence your opinion on this?
<whitequark>
imo the main problem isn't tracking signals to wires, but rather actually getting a hold of signals themselves
<awygle>
whitequark: it makes me more sanguine with "start with nmigen and add post-synth stuff later if at all"
<whitequark>
cool
<awygle>
"can't introspect Instances" is the only disadvantage that would be a show-stopper for me
<awygle>
(or well, a serious downside. nothing's a "show-stopper" per se.)
<whitequark>
I think we can hack up something non-invasive that will let you introspect instances
<whitequark>
I mean, I think you can just make a Signal and set hierconn on it
<whitequark>
with no special actions from nmigen itself
<daveshah>
Yep
<whitequark>
speaking of which, attributes on signals should be unsafe by default
<whitequark>
since they can totally break any guarantees nmigen provides
<whitequark>
that's going to be quite a PITA to implement without annoying everyone too much
<awygle>
i'm slightly behind the times here and haven't quite made the connection between hierconn and ILAs and instances and whatnot, can you give me like, a glossary view?
<awygle>
happy to get out the shovel but want to call before i dig, so to speak
<awygle>
... why am i speaking in metaphors today.
<daveshah>
With hierconn, you create a signal called \cell_name.wire_name_in_cell with the hierconn attribute set
<daveshah>
Then you flatten the design and that wire is connected to wire_name_in_cell inside the cell
<daveshah>
That gets you Instance introspevtion
<whitequark>
hm
<daveshah>
*introspection
<whitequark>
can we make it so that the signal name is immaterial and the attribute's value specifies the path?
<whitequark>
well
<whitequark>
if it's a string, no need to break existing semantics
<whitequark>
nmigen doesn't ever guarantee you names, and i can see getting duplicates
<daveshah>
I haven't looked at it but I see no reason why not
<whitequark>
for example if you somehow end up sampling the same signal in an instance twice
<whitequark>
ok, cool
<whitequark>
awygle: have you looked at microscope?
<awygle>
oh, i get it. so nmigen would output a signal called \my_verilog_instance.the_wire_i_want, and then yosys would glue it to the_wire_i_want in my_verilog_instance. and nmigen already has the names because of the fragment thing whitequark said, and so we can make it all work together. yes?