futarisIRCcloud has quit [Quit: Connection closed for inactivity]
Asu has joined #nmigen
Ultrasauce_ is now known as Ultrasauce
Asuu has joined #nmigen
Asu has quit [Ping timeout: 258 seconds]
rohitksingh has quit [Ping timeout: 244 seconds]
Asu has joined #nmigen
Asuu has quit [Ping timeout: 272 seconds]
lkcl has joined #nmigen
Asu has quit [Ping timeout: 240 seconds]
Asu has joined #nmigen
thinknok has joined #nmigen
thinknok is now known as jeanthom
FFY00 has quit [Remote host closed the connection]
Asuu has joined #nmigen
Asu has quit [Ping timeout: 256 seconds]
TD--Linux has quit [Changing host]
TD--Linux has joined #nmigen
TD--Linux is now known as TD-Linux
FFY00 has joined #nmigen
<ZirconiumX>
You can't use Case to Switch over multiple values, can you?
<miek>
iirc you can do Case(a, b) to match a or b
<ZirconiumX>
Ah, thank you
emilj has joined #nmigen
Asu has joined #nmigen
Asuu has quit [Ping timeout: 256 seconds]
<ZirconiumX>
Would it be possible to detect matching (through Value.matches or Case) against the wrong Enum type, if a signal is declared with an enum decoder?
<ZirconiumX>
I just noticed that I was doing that and was wondering if it would be catchable
<whitequark>
theoretically yes, practically the infrastructure for it is not ready
<ZirconiumX>
Mm, I see
<ZirconiumX>
Enhancement issue, perhaps?
<whitequark>
sure
<whitequark>
in general, nmigen should have more of a type system than it does now
<_whitenotifier-9>
[nmigen] ZirconiumX opened issue #384: Catch matching on an enum of the wrong type - https://git.io/JflVY
<awygle>
Issue #385 - have you heard of these "type" things? those might be cool to have
<ZirconiumX>
So, given that simulator state is not serialisable (as far as I know?), what's a good hack to get something equivalent?
<awygle>
import pickle
<awygle>
(not a serious suggestion)
<emily>
it seems to me that it would be a good thing for simulator state to be serialisable
<awygle>
i agree with that, with the caveat that i have absolutely not done the work to think it all the way through
Asuu has joined #nmigen
Asu has quit [Ping timeout: 246 seconds]
Asuu has quit [Ping timeout: 240 seconds]
Asu has joined #nmigen
rohitksingh has joined #nmigen
<whitequark>
the problem with serializing simulator state is uh
<whitequark>
how are you going to reassociate it with signasl?
<whitequark>
signals aren't serializable either
<ZirconiumX>
Somewhere in the simulator it stores the values of Signals, right?
<whitequark>
yep
<whitequark>
i can serialize that for you no problem
<whitequark>
it's basically a single hashmap
<whitequark>
i mean
<whitequark>
it's literally a hashmap
<ZirconiumX>
And then deserialise it to get the state of all the signals
<whitequark>
huh?
<ZirconiumX>
Well, to restore the state of all signals
<whitequark>
how do you serialize the keys of the hashmap?
<whitequark>
signals are identified by their, well, object identity
<whitequark>
if you deserialize a signal it's a new signal
<ZirconiumX>
Does nMigen have no other way of identifying a signal?
<ZirconiumX>
What I'm looking for is essentially to preserve as much state as possible, (or at least enough state to construct all other state), make a change of some kind, and then reload the simulator with the saved state
<whitequark>
unrealistic
<whitequark>
you're basically asking for incremental nmigen builds
<whitequark>
and its structure is fundamentally hostile to this
<whitequark>
i tried to make an EDA package in the style of nmigen once
<whitequark>
it would have to assign persistent identifiers to "signals" (components)
<whitequark>
i never solved it
<whitequark>
it's equivalent to incremental builds
<whitequark>
or rather, a prerequisite
<whitequark>
(once you can match signals between builds the rest becomes almost trivial)
<whitequark>
there are basically two paths here
<whitequark>
one, you can radiclally change how python works and make it so that you can edit live python coe
<whitequark>
pretty much modify an existing closure
<whitequark>
a bit like vc++'s edit and continue works
<ZirconiumX>
It's increasingly feeling like the reason we can't have nice things is Python
<Sarayan>
but otoh the reason you currently do have nice things is pytonh too
<whitequark>
you'd have the same problem in uh
<whitequark>
in verilog too?
<daveshah>
Yeah, I've thought a bit about incremental stuff with Yosys/nextpnr
<whitequark>
in virtually any way you implement a HDL in that does not constrain the changes you can make
<daveshah>
but autoidx and line number derived names in Yosys pretty much screws you before you've even got to abc
<daveshah>
and I can't think of a reasonable way around that
<whitequark>
yosys even has it a bit easier because it can preserve sub-netlists; it doesn't currently do IPO
<whitequark>
it "just" has to prove netlist equivalence
<daveshah>
Netlist hashing might even be strong enough
<daveshah>
But it still gets quite tricky trying to find suitable anchors
<whitequark>
a simulator like nmigen's pysim does not have that luxury though
<whitequark>
because everything in a sim affects everything else
<whitequark>
so you're left trying to guess the actual nature of a change
<whitequark>
on the other hand *if* your editor lets you observe the changes *as they are done* you don't need that
<whitequark>
you can just see that a signal was added or removed
<whitequark>
so even if it's a signal with the same name, size, and location, you know it's actually different.
<ZirconiumX>
I would be happy with nMigen trying to be best effort, even if it requires something like manually assigning anchors
<ZirconiumX>
The time spent doing that would still be less than the time spent trying to get to a given point
<Sarayan>
pysim is so slow that it is in practice unusable
<Sarayan>
use cxxrtl, it will change your life
<Sarayan>
there's just no comparison
<Sarayan>
and under linux its seriously not hard to use
<Sarayan>
(no idea under anything else)
<ZirconiumX>
Sarayan: I can't imagine cxxrtl helping the savestate issue much
<whitequark>
pysim isn't that slow, you're just using it outside of its desired domain
<whitequark>
migen's simulator was never intended for *integration* tests
<whitequark>
it was made for writing small unit tests of small modules
<whitequark>
that you can use pysim even in principle for your entire system is a testament to how much faster it became
<awygle>
I always think about the differential dataflow stuff in the context of this topic (incremental changes to simulated code)
<whitequark>
ooh?
<awygle>
Mhm. Gimme a bit and I'll try to expand on the thought... (lunch)
<awygle>
mk so it seems like the differential dataflow stuff might be a good way to handle the "i have a netlist i'm simulating, i make a change to the netlist, i do not want to re-run the entire simulation, only what's changed" problem
<awygle>
it seems quite efficient at updating from a current state to a next state and also has a notion of like, timed events, which matches HDL sim fairly well (at a surface level at least)
<awygle>
it doesn't actually solve the problem you're discussing, which is "i have a source file, i make a change to it, i have a new netlist, i need to match signals in the new netlist to signals in the old netlist and also to signals in the source file"
<awygle>
the thing in my memory which most closely corresponds to that is the Rust people's incremental compilation architecture, where they talk about maintaining a database of facts about the program and whatnot. i wonder if we could persist such a data structure across runs for incremental comp purposes. it seems like the main missing thing is some kind of history of the project, so that your signal IDs don't necessarily just *poof* every time you
<awygle>
run a new build.
<awygle>
was any of that coherent?
* awygle
realises there was a lot of "this thing is vaguely shaped like this other thing, maybe that's Something?" in there
Asuu has joined #nmigen
Asu has quit [Ping timeout: 256 seconds]
<whitequark>
yeah
<whitequark>
that "history" is exactly what i'm talking about
<whitequark>
rust has it a bit easier because it has actual encapsulation
<awygle>
yes
<awygle>
on the other hand we don't have to solve this for "all of python" (no encapsulation), just for "nmigen HDL" (encapsulation by modules)
<awygle>
though i suspect the former creeps into the latter
jeanthom has quit [Ping timeout: 252 seconds]
<whitequark>
there's no actual encapsulation in nmigen either
<whitequark>
you can just use any signals you want
<whitequark>
signals are not actually associated to modules in any inherent way
<whitequark>
an undriven signal is emitted by the backend in every module where it's used
chipmuenk has quit [Quit: chipmuenk]
<hell__>
i guess that's why incrementally rebuilding things is hard?
<whitequark>
one of the reasons why
<awygle>
hmm that... is true
<awygle>
what is the reason for that?
<whitequark>
migen compat
<awygle>
oof
<whitequark>
well, this is the hard reason why it stays
<awygle>
how uh.... how important is migen compat >_>
<awygle>
(i know the answer to this)
<whitequark>
if we drop it we can jut as well ditch nmigen
<awygle>
<_<
<whitequark>
it means florent and his lite* packages stay on migen
<whitequark>
which will mean the split persists forever
<awygle>
sigh. yeah.
<awygle>
can you elaborate a bit more on the reason why migen compat => signals aren't associated with modules?
<whitequark>
well, how would you associate signals with modules?
<whitequark>
ok so you're gonna rewrite all migen code to insert that?
<whitequark>
the current plan for migen compat is to even not rewrite the imports
<whitequark>
just spoof the migen package itself with zero change to user code
<whitequark>
that *might* be tractable
<hell__>
ah, you want nmigen to be a drop-in replacement for migen?
<whitequark>
that was the #1 design goal
<whitequark>
it had to be a drop-in replacement, and then it could also be other things
<awygle>
i mean there must be some shenanigans already happening with nmigen.compat since those classes derive <name i can't recall> instead of Elaboratable
<whitequark>
those are benign
<whitequark>
it's just an extra layer of indirection to keep the same names; that class doesn't do any magic
<whitequark>
(and in fact inherits from Elaboratable itself)
<awygle>
my no-facts vision involves expanding that class to use the current "nameless" signal approach for migen compat modules while still allowing the "named" approach for nmigen-only modules
<whitequark>
sure
<whitequark>
we can even turn this thing on exclusively for nmigen-only hierarchies
<whitequark>
are you suggesting we rewrite all of our nmigen code to include this annotation burden as well?
<whitequark>
don't forget that currently the interface signals are created in the constructor but the module isn't
<awygle>
we still need to figure out how to handle typed interface signals better
<whitequark>
but there's another aspect
<whitequark>
let's say we do
<whitequark>
now we're on par with verilog. can you do that in verilog?
<whitequark>
the incremental builds thing that is
<hell__>
would it be too complex to make all nmigen compat modules be in a shared "compat" namespace for backwards compatibility, and then make each pure nmigen module have its own namespace?
emilj has quit [Quit: WeeChat 2.3]
<awygle>
i don't know. i wouldn't be hugely surprised if vivado did?
<whitequark>
hell__: i'm just assuming for now that things go maximally in favor for awygle's idea
<whitequark>
awygle: per-module or per-net?
<whitequark>
i'm not aware of anyone ever shipping any sort of per-net incremental rebuild
<awygle>
ok, i buy that
<whitequark>
per-module is fairly obvious, see daveshah's suggestion of hashing
<whitequark>
but per-net has inherent challenges, like say you swap the names of two signals, is it the same netlist or not?
<awygle>
i think it is reasonable to say "both of these signals have changed, resimulate/resynthesize everything downstream of them". at least to begin with
<whitequark>
i.e. do you restore the simulation state structurally (by placing the values to signals in the same *graph position*) or nominally (in the same hierarchy position)
<whitequark>
ok
<whitequark>
when do you *not* resimulate in this proposal?
<whitequark>
i had two signals and did a xor b. now i'm doing b xor a. is this a change to the signal names?
<awygle>
that seems like a reasonable starting place
<whitequark>
but... that's the exact same circuit
<whitequark>
i don't get what the benefit of the proposal is, then
<whitequark>
if there is any case where caching pratial simulations would be useful, swapping the arguments of a xor seems to be certainly one of those
<awygle>
i was picturing things that are "down" the hierarchy from the change being resimulated but not things that are "up" or "sideways". but it's a graph (not even a DAG), so maybe that's not actually relevant
<whitequark>
yeah
Asuu has quit [Quit: Konversation terminated!]
_whitenotifier-9 has quit [Ping timeout: 260 seconds]
FFY00 has quit [Read error: Connection reset by peer]