<tpw_rules>
i want to bring up the design for informing the new resource system
<galibert[m]>
There’s a bunch of clocks you can reach, but I’m going to bed. Maybe try to remind me sometime compatible with the Paris time zone if you can
nyanotech has quit [Remote host closed the connection]
nyanotech has joined #amaranth-lang
notgull has quit [Ping timeout: 255 seconds]
notgull has joined #amaranth-lang
Degi_ has joined #amaranth-lang
Degi has quit [Ping timeout: 268 seconds]
Degi_ is now known as Degi
jn has quit [Ping timeout: 256 seconds]
jn has joined #amaranth-lang
jn has joined #amaranth-lang
notgull has quit [Ping timeout: 255 seconds]
notgull has joined #amaranth-lang
<whitequark[cis]>
<tpw_rules> "has amaranth settled on initiato..." <- the interface docs do not set terminology for users of interfaces; it just gives a general idea of what is Out and what is I
<whitequark[cis]>
* the interface docs do not set terminology for users of interfaces; it just gives a general idea of what is Out and what is In
<galibert[m]>
There sure are, but those are all the questions around platform in the first place aren't they?
<whitequark[cis]>
my reasoning is as follows: (1) the functionality proposed in the RFC is already available through de-facto stable interface of Fragment.get(elaboratable, platform) and (2) adding this prevents us from adding an universal SimulationPlatform with a well-defined API that components could rely on during simulation
<whitequark[cis]>
(you can call Fragment.get(Fragment.get(x, platform), platform=None), the second Fragment.get call does nothing)
<Wanda[cis]>
adding platform to sim is an "obvious" step, but ... it lacks the "what then" part, and risks locking us into something suboptimal
<cr1901>
Okay, but I have touched Fragments literally maybe 2 times if that in all the Amaranth code I've written. Compared to omigen (putting aside its design flaws), I don't understand what Fragments in amaranth actually are/what they do.
<cr1901>
A platform arg to Simulator is something I'm more likely to see/touch
<Wanda[cis]>
... I thought we were planning to kill fragments
<tpw_rules>
you say it would lock in because then each design might have a different platform?
<zyp[m]>
whitequark[cis]: I would argue that it could still be beneficial to have the ability to override a default simulation platform
<mcc111[m]>
What would SimulationPlatform offer that differentiates it from any of the other platforms?
<zyp[m]>
currently during simulation, the platform argument to elaborate() is None
<cr1901>
mcc111[m]: I assume I/O peripherals wouldn't use vendor primitives that can't be simulated; in general a platform is going to bring in I/O buffers and primitives that the Amaranth simulator has no idea how to handle.
<whitequark[cis]>
zyp[m]: I'm not sure if I agree
<Wanda[cis]>
hm
<Wanda[cis]>
so I could agree with it
<whitequark[cis]>
I think the simulation platform should offer a method of dependency injection that lets you register interfaces that your PHYs expose to the outside world
<tpw_rules>
it does not seem unreasonable to say that a future SimulationPlatform would want to integrate with other platforms instead of be replaced
<whitequark[cis]>
and also a bunch of implementations for standard things like DDR buffers (which really do not need to have several implementations)
<Wanda[cis]>
eg. depending on how we choose to stuff things like zynq PS interface into platform, we may want to have a variant of simulationplatform that knows how to mock whtever methods are used for that
<jfng[m]>
are we talking about full system simulation use-cases, or testbench use-cases, or both ?
<Wanda[cis]>
but then we won't need that if we design a nice generic interface for that kind of stuff
<Wanda[cis]>
so I'd say this thing gets effectively blocked on better platform definition
<zyp[m]>
jfng[m]: anything that makes use of the `platform` argument
<Chips4MakersakaS>
Would we then only introduce platform arg to Simulator when there is a SImulationPlatform and only allow SimulationPlatform as type ?
<Chips4MakersakaS>
... for that argg
<Wanda[cis]>
in summary: #48 has an incomplete value proposition, and it's main value is that it's a stopgap to stuff in a platform now
<whitequark[cis]>
the way I think about it, SimulationPlatform would be instantiated and used by the simulator itself
<whitequark[cis]>
s//`/, s//`/, s/used/provided/
<Wanda[cis]>
which as Catherine suggested, is already doable via Fragment.get
<Wanda[cis]>
it's a hack, but no more than a stopgap RFC would be
<Chips4MakersakaS>
How do you add your LEDs or serial outputs then to the platform that will be requested during elaboration ?
<galibert[m]>
And DSP blocks
<tpw_rules>
that's a meaningless question right now
<whitequark[cis]>
DSP blocks are unrelated
<whitequark[cis]>
Chips4MakersakaS: for example an UART PHY from amaranth_stdio will register an UART RX/TX pair during elaboration and then, once the simulation is up, the testbench would be able to request it on its side
<tpw_rules>
(personally i separate the on-FPGA stuff into its own module that doesn't get used during simulation)
<whitequark[cis]>
effectively inverting the current platform.request method
<whitequark[cis]>
however, as the meeting time is limited, I think we should not be discussing exactly how this mechanism should work in detail, because in any case it will require its own RFC
<Chips4MakersakaS>
whitequark[cis]: What if you want two UART interfaces ?
<whitequark[cis]>
(I have some thoughts on this, but they're in a private google doc)
<whitequark[cis]>
Chips4MakersakaS: you request them by name or number
<tpw_rules>
i would propose to close based on the workaround of Fragment.get(elaboratable, platform)
<whitequark[cis]>
there doesn't seem to be any technical reason to merge #48, yes
<whitequark[cis]>
zyp[m]: I plan to split the current resource system from the platforms provided in `amaranth.vendor`, evict them into `amaranth_boards`, and then eventually remove them, so simulation platform isn't going to be using those
<whitequark[cis]>
does anyone have an objection to closing, in favor of a future more in-depth proposal on platforms (simulation or not)?
<jfng[m]>
close, in light of this discussion (would have voted merge otherwise)
<zyp[m]>
I'm happy enough with the workaround, that I weren't aware of
<Wanda[cis]>
no objection, close
<cr1901>
No objection to closing.
<whitequark[cis]>
when I'm documenting the simulator, I'll probably put the workaround in the docs
<Chips4MakersakaS>
agree with close to avoid unwanted API poisoning
<galibert[m]>
Close then
<whitequark[cis]>
highlighted as "use this for now, we'll eventually do something better" (Wanda, we can always provide just Fragment.get with that exact functionality)
<Wanda[cis]>
there's the minor question here of how much we actually want to keep Fragment.get
<Wanda[cis]>
I
<Wanda[cis]>
... I didn't even ask that question yet
<whitequark[cis]>
lol
<zyp[m]>
:)
<Wanda[cis]>
but yeah
<Wanda[cis]>
I agree
<whitequark[cis]>
catgirl can be little an acausal, as a treat
<Wanda[cis]>
first of all, I'm not happy with current set/get design, or rather the division of responsibility here
<whitequark[cis]>
should delay(None) even be legal? this is useless in testbenches and deprecated in processes
<cr1901>
I'm going to abstain. Haven't kept up with changing my simulator code to comment effectively.
<tpw_rules>
same here
<Wanda[cis]>
motivation: the hooks that ValueCastable implementors should provide are IMO "convert bits to user-defined type" and "convert user-defined type to bits", and common set/get implementation should use those
<zyp[m]>
whitequark[cis]: I agree
<Wanda[cis]>
and the user-defined type to bits is actually just ValueCastable.const
<Wanda[cis]>
further motivation: we need these hooks, and not just set/get, to implement simulation interface for amaranth.lib.memory which is very much not a signal
<whitequark[cis]>
Wanda: oh, this is an interesting angle
<galibert[m]>
Isn't that orthogonal to async vs. generators?
<whitequark[cis]>
without get/set, this RFC will not actually let you read or write any state
<whitequark[cis]>
so no, it's not actually orthogonal
<galibert[m]>
Interesting
<Wanda[cis]>
I'd propose defining another ValueCastable hook for the missing bits-to-whatever conversion (maybe as part of a separate RFC; I do have some thoughts on that already for unrelated reasons), then defining set and get as common functions on the base ValueCastable class itself, so the implementors don't have to provide them
<zyp[m]>
I'm inclined to agree with that
<galibert[m]>
why is async using a set() instead of .eq as generators did, there's a technical reason?
<Wanda[cis]>
and then I'd propose to add Memory.read and Memory.write interfaces that likewise use those
<whitequark[cis]>
I have one comment on this (I thought it's an objection at first, but on second thought I don't think it really is)
<whitequark[cis]>
consider that someone might want to do something like waiting with a mask
<zyp[m]>
galibert[m]: `.eq()` would have to return an awaitable expression
<whitequark[cis]>
the reason it's not an objection is because we already have a perfectly good DSL for expressing arbitrary conditions on Amaranth data structures
<whitequark[cis]>
it's called Amaranth
<whitequark[cis]>
Wanda: so, in your proposal, what would be the syntax for reading or writing a value?
<whitequark[cis]>
await sim.get(x)?
<Wanda[cis]>
to clarify: I'm not proposing to change the syntax wrt the RFC, just who implements it
<Wanda[cis]>
though
<whitequark[cis]>
I think these are inalienable though
<Wanda[cis]>
I guess moving these methods to sim could be even better
<Wanda[cis]>
yeah
<whitequark[cis]>
because otherwise we would have to require every ValueCastable to implement get and set anyway, with some fixed body
<whitequark[cis]>
or provide a default impl, which I really don't like the idea of
<Wanda[cis]>
whitequark[cis]: that's what inheritance is for!
<Wanda[cis]>
mhm
<whitequark[cis]>
inheritance is for overriding behavior
<Wanda[cis]>
fair
<whitequark[cis]>
if the behavior is never overridden it shouldn't be a method in first place
<whitequark[cis]>
(unless it's private)
<Wanda[cis]>
ok, so, I do consider this question somewhat orthogonal, but after thinking about that for a minute I do like sim.get(signal) and sim.set(signal, value)
<whitequark[cis]>
I like them in principle
<whitequark[cis]>
they feel wordy
<whitequark[cis]>
yield signal → await sim.get(signal)
<Wanda[cis]>
we do want to pass sim into it somehow, and that's what main source of wordiness, no?
<Wanda[cis]>
like, if we don't, then value.get() and value.set(val) becomes the obvious choice again
<whitequark[cis]>
yes, it's the combination of wanting to use await and wanting to not have random stuff in global scope
<whitequark[cis]>
in cocotb, you just do signal.get()
<whitequark[cis]>
but that's just not reentrant, and I'm not even sure if they're thread-local
<whitequark[cis]>
Wanda[cis]: not really, not for value-castables
<whitequark[cis]>
for reasons I just brought up
<Chips4MakersakaS>
I'm not sure about API that needs to handle memory specially.
<whitequark[cis]>
that is: I want to have def get() on value-castables if and only if it gets a customized implementation
<zyp[m]>
cocotb is only simulation and wouldn't worry about reserving names only used for simulation
<Wanda[cis]>
pysim could live without await since it implements them synchronously, but I imagine you could want it for cxxrtl (so you can batch a bunch of read/write requests)?
<whitequark[cis]>
Wanda: hm.
<whitequark[cis]>
no, CXXRTL is integrated using ctypes, it just reads memory
<whitequark[cis]>
so... sim.get(value) but await sim.tick()?
<whitequark[cis]>
I actually really like that
<whitequark[cis]>
only using await for, well, waiting
<Wanda[cis]>
mhm
<galibert[m]>
way more readable
<Wanda[cis]>
I agree
<whitequark[cis]>
also less cursed precedence
<whitequark[cis]>
prefix await is kind of a mistake
<Wanda[cis]>
if CXXRTL doesn't need await for its functionality, I'd say let's do that
<whitequark[cis]>
it does not, no
<galibert[m]>
Is it... javascript's fault?
<whitequark[cis]>
I think Python's await is before JavaScript's?
<galibert[m]>
Not sure
<whitequark[cis]>
JS got it in 2017
<galibert[m]>
anyway, unimportant
<whitequark[cis]>
Python did it in 2015
<whitequark[cis]>
it's probably C#'s fault
<galibert[m]>
Oh yeah, it's all C#'s fault, that's ok with me
<Wanda[cis]>
I think it may be Python's fault, since await descends directly from yield from
<whitequark[cis]>
it also may be originally haskell's fault
<Wanda[cis]>
or actually
<Wanda[cis]>
hold on
<Wanda[cis]>
we want processes that simulate comb logic, right?
<zyp[m]>
that's supported through await sim.changed()
<whitequark[cis]>
Wanda: yes, although I'm broadly speaking fine with them being their own special thing
<Wanda[cis]>
then when a testbench, which does implicit Settle, performs a set and a get, we may need to call another process in the meantime
<whitequark[cis]>
like just a normal function (neither async nor generator) for example
<Wanda[cis]>
this sounds like an argument for await
<zyp[m]>
and yeah, the problem is not the comb process, but a normal testbench that sets one signal and then reads a derived one
<whitequark[cis]>
oh, you're right
<whitequark[cis]>
set has to be awaitable since it could potentially trigger clocked stuff, and get has to be awaitable since mandatory settling after every set can get expensive
<Wanda[cis]>
<del>we could hack around it by reentering the simulator within `ge`<del>*gets sprayed with water bottle* bad Wanda
<Wanda[cis]>
* <del>we could hack around it by reentering the simulator within `ge`</del>_gets sprayed with water bottle_ bad Wanda</del></del>
<whitequark[cis]>
I, hm.
<whitequark[cis]>
I think that almost works?
<whitequark[cis]>
I want it to be possible to e.g. await an http request from a testbench
<whitequark[cis]>
reentrancy gets tricky with that
<Wanda[cis]>
right
<Wanda[cis]>
glasgow
<Wanda[cis]>
heh
<Wanda[cis]>
I agree
<whitequark[cis]>
yes. basically, you would give the simulator some other thing into which it will shove every awaitable it doesn't understand
<Wanda[cis]>
(and this was going to be what my second major comment was about)
<Wanda[cis]>
so what
<Wanda[cis]>
before we get to that part, are we settling on sim.get(sig) and sim.set(sig, val)?
<Wanda[cis]>
er
<Wanda[cis]>
await sim.get(sig) and await sim.set(sig, val)
<Wanda[cis]>
to be clear
<whitequark[cis]>
I'm good with these
<zyp[m]>
I think that's reasonable
<Wanda[cis]>
I have writing an RFC related to the missing bits-to-user ValueCastable on my TODO list FWIW
<Wanda[cis]>
I maaaay try to get it done for next monday, though I can't promise that atm
<whitequark[cis]>
sounds good
<whitequark[cis]>
some other quick comments
<whitequark[cis]>
- should we really keep the `active`/`passive` terminology?
<whitequark[cis]>
- is "delay" the best way to describe passing of simulated time?
<zyp[m]>
if not, what do we replace it with?
<Wanda[cis]>
"delay" is traditional, I believe
<zyp[m]>
I think we need to keep the functionality
<Wanda[cis]>
ie. this is both VHDL and Verilog terminology
<galibert[m]>
Is passive/active documented anywhere? That rfc is the first place I've seen the term
<whitequark[cis]>
zyp[m]: yes, the functionality is useful
<whitequark[cis]>
only talking about the names
<whitequark[cis]>
- should we think upfront about adding some sort of binding construct to `sim.tick()`?
<whitequark[cis]>
since the top-level "sync" may not be the "sync" of a submodule
Stary has quit [Remote host closed the connection]
balrog has quit [Ping timeout: 264 seconds]
Wanda[cis] has quit [*.net *.split]
jfng[m] has quit [*.net *.split]
FFY00 has quit [*.net *.split]
feldim2425 has quit [*.net *.split]
zyp[m] has quit [*.net *.split]
SpaceCoaster has quit [*.net *.split]
galibert[m] has quit [*.net *.split]
roflin has quit [*.net *.split]
smkz has quit [*.net *.split]
ebb has quit [*.net *.split]
josuah has quit [*.net *.split]
vup has quit [*.net *.split]
pbsds has quit [*.net *.split]
Bluefoxicy has quit [*.net *.split]
_whitenotifier-7 has quit [*.net *.split]
marcan has quit [*.net *.split]
cr1901 has quit [*.net *.split]
merry has quit [*.net *.split]
trabucayre has quit [*.net *.split]
notgull has quit [*.net *.split]
sorear has quit [*.net *.split]
ovf has quit [*.net *.split]
eigenform has quit [*.net *.split]
indy has quit [*.net *.split]
tucanae47 has quit [*.net *.split]
sugarbeet has quit [*.net *.split]
esden has quit [*.net *.split]
LoveMHz has quit [*.net *.split]
TD-Linux has quit [*.net *.split]
nimh has quit [*.net *.split]
mwk has quit [*.net *.split]
Xesxen has quit [*.net *.split]
lethalbit has quit [*.net *.split]
chaoticryptidz has quit [*.net *.split]
qookie has quit [*.net *.split]
richardeoin has quit [*.net *.split]
FireFly has quit [*.net *.split]
nyanotech has quit [*.net *.split]
mindw0rk has quit [*.net *.split]
frgo has quit [*.net *.split]
pie_ has quit [*.net *.split]
tcal has quit [*.net *.split]
gatecat has quit [*.net *.split]
anuejn has quit [*.net *.split]
leptonix has quit [*.net *.split]
agg has quit [*.net *.split]
Chips4MakersakaS has quit [*.net *.split]
jn has quit [*.net *.split]
_catircservices has quit [*.net *.split]
bob_twinkles has quit [*.net *.split]
Abhishek_ has quit [*.net *.split]
cyrozap has quit [*.net *.split]
XgF has quit [*.net *.split]
_whitenotifier-5 has quit [*.net *.split]
swym4 has quit [*.net *.split]
sauce has quit [*.net *.split]
tannewt has quit [*.net *.split]
lf has quit [*.net *.split]
Lord_Nightmare has quit [*.net *.split]
whitequark[cis] has quit [*.net *.split]
electronic_eel has quit [*.net *.split]
mcc111[m] has quit [*.net *.split]
Darius has quit [*.net *.split]
V has quit [*.net *.split]
Degi has quit [*.net *.split]
Psentee has quit [*.net *.split]
lambda has quit [*.net *.split]
oter has quit [*.net *.split]
toshywoshy has quit [*.net *.split]
key2 has quit [*.net *.split]
ktemkin has quit [*.net *.split]
Ekho has quit [*.net *.split]
yuriks has quit [*.net *.split]
dyniec has quit [*.net *.split]
_alice has quit [*.net *.split]
crzwdjk has quit [*.net *.split]
asjackson has quit [*.net *.split]
skipwich has quit [*.net *.split]
alanvgreen has quit [*.net *.split]
mithro has quit [*.net *.split]
mobius has quit [*.net *.split]
Raito_Bezarius has quit [*.net *.split]
miek has quit [*.net *.split]
Wolfvak has quit [*.net *.split]
ormiret has quit [*.net *.split]
benreynwar has quit [*.net *.split]
tpw_rules has quit [*.net *.split]
gruetzkopf has quit [*.net *.split]
ChanServ has quit [*.net *.split]
eldiem has quit [Read error: Connection reset by peer]
DX-MON has quit [Ping timeout: 264 seconds]
peepsalot is now known as 074AANBT8
GenTooMan has quit [Ping timeout: 264 seconds]
074AANBT8 has quit [Ping timeout: 264 seconds]
LoveMHz has joined #amaranth-lang
marcan has joined #amaranth-lang
eldiem has joined #amaranth-lang
DX-MON has joined #amaranth-lang
Stary_ has joined #amaranth-lang
balrog_ has joined #amaranth-lang
mcc111[m] has joined #amaranth-lang
peepsalot has joined #amaranth-lang
jfng[m] has joined #amaranth-lang
Wanda[cis] has joined #amaranth-lang
Chips4MakersakaS has joined #amaranth-lang
notgull has joined #amaranth-lang
jn has joined #amaranth-lang
nyanotech has joined #amaranth-lang
skipwich has joined #amaranth-lang
lf has joined #amaranth-lang
pbsds has joined #amaranth-lang
FFY00 has joined #amaranth-lang
Degi has joined #amaranth-lang
mindw0rk has joined #amaranth-lang
feldim2425 has joined #amaranth-lang
frgo has joined #amaranth-lang
mithro has joined #amaranth-lang
mobius has joined #amaranth-lang
SpaceCoaster has joined #amaranth-lang
alanvgreen has joined #amaranth-lang
oter has joined #amaranth-lang
Lord_Nightmare has joined #amaranth-lang
galibert[m] has joined #amaranth-lang
cr1901 has joined #amaranth-lang
roflin has joined #amaranth-lang
zyp[m] has joined #amaranth-lang
whitequark[cis] has joined #amaranth-lang
Raito_Bezarius has joined #amaranth-lang
_catircservices has joined #amaranth-lang
smkz has joined #amaranth-lang
Darius has joined #amaranth-lang
pie_ has joined #amaranth-lang
tcal has joined #amaranth-lang
TD-Linux has joined #amaranth-lang
bob_twinkles has joined #amaranth-lang
gatecat has joined #amaranth-lang
Bluefoxicy has joined #amaranth-lang
nimh has joined #amaranth-lang
mwk has joined #amaranth-lang
cyrozap has joined #amaranth-lang
Xesxen has joined #amaranth-lang
Abhishek_ has joined #amaranth-lang
XgF has joined #amaranth-lang
lethalbit has joined #amaranth-lang
Psentee has joined #amaranth-lang
toshywoshy has joined #amaranth-lang
ebb has joined #amaranth-lang
josuah has joined #amaranth-lang
electronic_eel has joined #amaranth-lang
vup has joined #amaranth-lang
lambda has joined #amaranth-lang
key2 has joined #amaranth-lang
yuriks has joined #amaranth-lang
ktemkin has joined #amaranth-lang
Ekho has joined #amaranth-lang
anuejn has joined #amaranth-lang
leptonix has joined #amaranth-lang
ChanServ has joined #amaranth-lang
sugarbeet has joined #amaranth-lang
ormiret has joined #amaranth-lang
tpw_rules has joined #amaranth-lang
gruetzkopf has joined #amaranth-lang
crzwdjk has joined #amaranth-lang
asjackson has joined #amaranth-lang
_alice has joined #amaranth-lang
dyniec has joined #amaranth-lang
Wolfvak has joined #amaranth-lang
miek has joined #amaranth-lang
agg has joined #amaranth-lang
qookie has joined #amaranth-lang
benreynwar has joined #amaranth-lang
V has joined #amaranth-lang
tannewt has joined #amaranth-lang
richardeoin has joined #amaranth-lang
sauce has joined #amaranth-lang
_whitenotifier-5 has joined #amaranth-lang
swym4 has joined #amaranth-lang
FireFly has joined #amaranth-lang
sorear has joined #amaranth-lang
esden has joined #amaranth-lang
trabucayre has joined #amaranth-lang
merry has joined #amaranth-lang
_whitenotifier-7 has joined #amaranth-lang
tucanae47 has joined #amaranth-lang
ovf has joined #amaranth-lang
eigenform has joined #amaranth-lang
indy has joined #amaranth-lang
chaoticryptidz has joined #amaranth-lang
GenTooMan has joined #amaranth-lang
<Wanda[cis]>
if we're doing crimes like that, I'd rather it was "warn on method of an elaboratable", not "warn on any function but the main process"
<whitequark[cis]>
also fine with me
<Wanda[cis]>
alright, so: for the record, I don't like this, but if there's a pressing need to get this stuff shipped, I'm fine with this
<whitequark[cis]>
there is (there's a grant conditional on it)
<Wanda[cis]>
where by "this" I mean sim.tick(name) uses top's domains and warns if used from an Elaboratable method, sim.tick(name, context=elaboratable) uses Fragment provenance chains to look up the context and grabs domains from here
<galibert[m]>
(grants mean food, and cats like food ;-) )
<Wanda[cis]>
which I think is what the final proposal would be like?
<zyp[m]>
how does this work if I'm e.g. adding stream interfaces to a component (automatically instanced from the component's signature)? where does the stream interface gets its context from?
<whitequark[cis]>
more generally, I also feel that clock domain rework is going to be a cross-cutting series of changes that will leave almost nothing untouched, and so avoiding it so hard just for the simulator is kind of pointless
<whitequark[cis]>
no matter what we ship now, CD rework will probably touch it
<Wanda[cis]>
heh, true
<whitequark[cis]>
so while I agree that the API I am proposing is flawed, I don't really see a way to ship one that's not going to be flawed
<zyp[m]>
what if said component is e.g. an asyncfifo, with two stream interfaces that nominally operates in different domains?
<whitequark[cis]>
I think clock domains in interfaces kind of have to ship first for any of this to be meaningful at all?
<whitequark[cis]>
FIFOs will have direct read/write methods as a stopgap
<zyp[m]>
yeah, that's what I said earlier
<whitequark[cis]>
Wanda: I guess memories will have too; so `sim.memory_read` or whatever would operate on `MemoryFragment` or its identity or whatever
<Wanda[cis]>
well yeah
<whitequark[cis]>
zyp: yeah but then I don't see how your question can have an answer? I'm confused
<zyp[m]>
whitequark[cis]: that was the answer
<whitequark[cis]>
ah!
<Wanda[cis]>
mmm, actually the fragment provenance stuff probably could obsolete MemoryIdentity now that I think of it?
<Wanda[cis]>
(assuming it actually works for MemoryInstance, but then it's an easy fix if it does not)
<whitequark[cis]>
mm, I'm not sure exactly how much I want to expose it in the public APIs
<whitequark[cis]>
for warnings it's OK since we commit so many crimes for those and they aren't guaranteed
<Wanda[cis]>
the proposed context= argument works entirely based on that
<whitequark[cis]>
oh, right.
<whitequark[cis]>
well, I guess that's my answer then ^^;
<whitequark[cis]>
(I have to expose it in the public API after all)
<zyp[m]>
how would it look in use? await sim.tick("write", context=self)?
<Wanda[cis]>
mhm
<Wanda[cis]>
(assuming you're in an elaboratable)
<zyp[m]>
so from a user perspective, context takes the elaboratable whose perspective the clock domain should be resolved from, and the rest are internal implementation details
<Wanda[cis]>
yes
<zyp[m]>
this sounds reasonable to me
<whitequark[cis]>
Wanda: actually, can you restate your proposal for `BikeshedDomain` (for the minutes)?
<whitequark[cis]>
I'm not sure I fully understood the motivation. if context still defaults to None we still have a footgun, no?
<Wanda[cis]>
we create an object, BikeshedDomain, which is a late-bound reference to a clock domain
<Wanda[cis]>
you create it as BikeshedDomain(elaboratable, domain_name)
<whitequark[cis]>
and forbid anything but that to tick?
<Wanda[cis]>
yes
<whitequark[cis]>
that seems... excessively verbose
<Wanda[cis]>
that or perhaps an actual ClockDomain
<whitequark[cis]>
but yeah I'll write it down
<Wanda[cis]>
well you can just create it once in elaboratable constructor and put it on a field
<whitequark[cis]>
the existing Tick() thing allows passing an actual ClockDomain()'
<whitequark[cis]>
* the existing Tick() thing allows passing an actual ClockDomain()
<Wanda[cis]>
and then you get something less verbose in actual helper methods
<whitequark[cis]>
we should probably preserve that
<Wanda[cis]>
well, yeah
<whitequark[cis]>
but that doesn't at all help FIFOInterface
<Wanda[cis]>
but also when you actually have a ClockDomain in hand, that's the easy case
<Wanda[cis]>
BikeshedDomain is effectively a late reference object for when you don't have one
<Wanda[cis]>
(if we get clock domains in interfaces, whatever materialized form they have, it'd likely be either BikeshedDomain or something similar to it except using interface as the reference point, somehow)
<whitequark[cis]>
this concludes the meeting
<whitequark[cis]>
(we can continue discussing the topic)
<Wanda[cis]>
actually I think that might work if we could make sub-interfaces of Component into additional valid contexts
<Wanda[cis]>
of course this adds another dependency on lib.wiring into ... idk, sim?
<Wanda[cis]>
but in principle, we could make it so that when a Component is found in a Fragment provenance chain, its signature is enumerated and all subinterfaces are registered as valid contexts for domain resolution
<Wanda[cis]>
... okay actually I don't like this idea at all
<Wanda[cis]>
we can make read/write work on FIFOInterface easily enough, just stuff the correct value for context on some field
<whitequark[cis]>
<Wanda[cis]> "but in principle, we could..." <- that's kind of cursed
<Wanda[cis]>
yes, disregard
<zyp[m]>
> (@whitequark) The sim argument should be passed at all times when an async function is provided to add_process/add_testbench, since the upgrade path is easy and usefulness otherwise is very limited.
<zyp[m]>
I agree, IIRC it was your suggestion to do otherwise :)
<zyp[m]>
* > (@whitequark) The sim argument should be passed at all times when an async function is provided to add\_process/add\_testbench, since the upgrade path is easy and usefulness otherwise is very limited.
<zyp[m]>
I agree, IIRC it was your suggestion to do otherwise :)
<whitequark[cis]>
I think we were trying to do some sort of transitionary arrangement
<zyp[m]>
yeah, which doesn't make a lot of sense now that there's not really any compatibility between old and new API
<whitequark[cis]>
I don't recall honestly, I remember it being a topic of discussion
<zyp[m]>
either way, I agree and will rewrite the RFC
<whitequark[cis]>
ohhh right
<whitequark[cis]>
yeah it was before the API was completely overhauled
<galibert[m]>
btw, with cxxrtl and current state of amaranth, is it possible to simulate (at a decent speed) some system at 12MHz which writes to a couple of dual-ported internal rams and on the other side you have hdmi video at ~135MHz and audio at.. 1.5MHz or so?
<whitequark[cis]>
135 MHz?
<whitequark[cis]>
no
<whitequark[cis]>
I don't even know what you're doing with it, the answer is just no, you can't
<galibert[m]>
that's the pixel clock of full hd
<tpw_rules>
why do you need to simulate the pixels that far
<whitequark[cis]>
I don't even think you can decode an existing static HDMI stream that quickly on a CPU
<whitequark[cis]>
(like, stored as a series of wire stats)
<whitequark[cis]>
s/stats/states/
<galibert[m]>
I don't need to, I was wondering if it was possible
<tpw_rules>
i mean tbh i read "decent speed" as in "a minute per frame"
<zyp[m]>
AIUI the current state of cxxrtl+amaranth still relies on python for driving the clocks (unless that changed recently), so it's not yet faster than pysim
<galibert[m]>
that's before serialization
<galibert[m]>
the 135MHz I mean
<galibert[m]>
I don't want to simulate the serdes, it's an external circuit anyway
<galibert[m]>
so it's just a bunch of pixel colors on a big enough framebuffer, the cpu wouldn't have any problems on that part of the chain
<tpw_rules>
why not just read the ram
<zyp[m]>
if you want to simulate a running system, it kinda sounds like you should mock the RAM and stick the data into a SDL surface or something
<zyp[m]>
assuming you want visual output
<whitequark[cis]>
yep
<whitequark[cis]>
even just normal VGA with C++ CXXRTL (not Python) is a challenge when you have some actual gateware to run
<whitequark[cis]>
absolutely no reason to waste CPU time doing individual reads
<galibert[m]>
Well, I guess I’ll have to test by blocks then
<galibert[m]>
The 135MHz domain does blending with the UI framebuffer, so there is stuff to test there, but I probably don’t need to check more that one or two frames
<zyp[m]>
hmm, do we have rules/conventions on what literals ValueCastable.eq() is expected to accept vs what ValueCastable.const() accepts?
<zyp[m]>
I think in my fixedpoint implementation, .eq() just defers to .const() when passed a literal
<whitequark[cis]>
hm
<Wanda[cis]>
I'd say "if it's not Value or ValueCastable, defer to .const()"
<whitequark[cis]>
buuut we need to document Statement first to even write down the constraint for that method...
<zyp[m]>
I'm now thinking in the context of sim.set(signal, value) and whether it should special case for ValueCastable and use .const() internally, or whether it can rely on .eq() doing the right thing
<Wanda[cis]>
sim.set should not defer to eq()
<Wanda[cis]>
since we want to get rid of the old interface
<Wanda[cis]>
(not immediately, but still)
<whitequark[cis]>
... can we implement it in terms of the new one? like a wrapper around a generator function which converts Assign to await sim.set()
<Wanda[cis]>
we can
<Wanda[cis]>
but this won't help with sim.set()
<Wanda[cis]>
since Assign always has RHS normalized to a Value already
<whitequark[cis]>
oh yeah I'm thinking of something else
<Wanda[cis]>
and as for the wrapper, hmmm
<whitequark[cis]>
I think it should special case ValueCastable yeah
<Wanda[cis]>
I thiiink a straightforward wrapper would work?
<zyp[m]>
okay, I updated the RFC to address the feedback, will update again once Wanda has written the inverse `.const` RFC
<galibert[m]>
Please document that active/passive stuff at some point :-)
<zyp[m]>
that's out of scope for the RFC, but yeah
<Wanda[cis]>
zyp: RFC mentions `get` and `set` working on signals; this is a functionality regression from current interface, which allows getting arbitrary values and setting arbitrary assignable values
<Wanda[cis]>
I think we should continue to support that
<Wanda[cis]>
at the very least, it's useful to be able to use struct fields, which desugar to Slice values underneath
<zyp[m]>
I agree, I was considering writing get(expression) and set(expression, value)
<zyp[m]>
is there a better term?
<Wanda[cis]>
well, it's a Value
<Wanda[cis]>
or a ValueLike really
<zyp[m]>
indeed, and set(value, value) would not read well
<Wanda[cis]>
yeah that's a bit of a problem
<Wanda[cis]>
assignable for the left side
<Wanda[cis]>
there's also a question of whether the right side should be specifically a const, or if arbitrary Value should be allowed like the current interface
<Wanda[cis]>
but I think that's kind of an accident due to reusing .eq
<Wanda[cis]>
and there's no actual functionality loss since you can just get
<zyp[m]>
well, that's not gonna work if we're not using .eq for value castables
<zyp[m]>
unless we go through get under the hood
<zyp[m]>
e.g. fixed.Value.eq needs to shift the value if you're assigning between signals of different precision
<zyp[m]>
so yeah, I'd argue it's reasonable for set() to require a literal
<Wanda[cis]>
oh right, literal
<Wanda[cis]>
that is a good word
<zyp[m]>
I've been thinking about adding a fixed.Literal to RFC 41, since we need a way to represent fixed point values in simulation
<Wanda[cis]>
how would it differ from fixed.Const?
<zyp[m]>
the current fixed.Const was an attempt at that, but I think it might be good to separate it further from the regular Const since the use case is not entirely the same