<_whitenotifier-7>
[amaranth-lang/amaranth-lang.github.io] whitequark b9294f6 - Deploying to main from @ amaranth-lang/amaranth@845010401d5b593863134754e7b9fbd97329c132 🚀
DX-MON has quit [Quit: I'm not disconnecting, you're disconnecting!]
lethalbit has quit [Quit: kill -9 -1]
lethalbit has joined #amaranth-lang
DX-MON has joined #amaranth-lang
lethalbit has quit [Quit: kill -9 -1]
DX-MON has quit [Quit: I'm not disconnecting, you're disconnecting!]
<Wanda[cis]>
Catherine: not *quite* sure this is what we want; an alternative would be to track the source location of `m.submodules +=` as well and use *that* for the cell instead
<Wanda[cis]>
(this code takes the source loc of Module() call)
<whitequark[cis]>
Wanda[cis]: that sounds right, actually
<_whitenotifier-7>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] eb2371e - Deploying to main from @ amaranth-lang/amaranth@6058ad35cf34f9f9203313e8c920749fbd6efab8 🚀
<Wanda[cis]>
<whitequark[cis]> "that sounds right, actually" <- wait, which one sounds right? `m.submodule` for `cell`, `Module()` for `module`?
<Wanda[cis]>
also won't we only have space for one source location by the time it gets flattened into $scopeinfo? (note: I don't actually know much about $scopeinfo)
<whitequark[cis]>
bbl train
<whitequark[cis]>
<Wanda[cis]> "wait, which one sounds right? `m..." <- this one
<whitequark[cis]>
<Wanda[cis]> "also won't we only have space..." <- we can separate them with |
<whitequark[cis]>
the usual way basically
<Wanda[cis]>
okay, more location tracking then
<Wanda[cis]>
more tracking done.
<Wanda[cis]>
<del>in Europe, the `Module()` must opt into tracking cookies first though</del>
<whitequark[cis]>
lol
jfng[m] has joined #amaranth-lang
<jfng[m]>
FYI: no SoC meeting at 1700 UTC today, as the agenda is empty
<galibert[m]>
Is all of -soc synchronized with 0.5?
<Wanda[cis]>
hmmmm.
<Wanda[cis]>
0.5 is ... kinda in state of flux right now
<galibert[m]>
Err I meant 0.4
<galibert[m]>
sorry
<galibert[m]>
Interfaces and everything
<Wanda[cis]>
but thanks for the reminder
<Wanda[cis]>
I'm going to make a -soc PR for RFC 43 [aka init=]
<galibert[m]>
Ah, good idea
<Wanda[cis]>
actually
<Wanda[cis]>
should the reset= on CSR stuff be renamed to init= as well
<Wanda[cis]>
I think yes
<jfng[m]>
Wanda[cis]: thanks!
<jfng[m]>
Wanda[cis]: yes
<Wanda[cis]>
with the usual deprecation dance, I suppose
<Wanda[cis]>
hm
<jfng[m]>
we don't yet have a public release
<Wanda[cis]>
except -soc doesn't really have version numbers
<jfng[m]>
maybe -stdio should depend on main as long, as it doesn't have a public release ? after which it should be pinned to a specific amaranth release
<_whitenotifier-5>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 1c70068 - Deploying to main from @ amaranth-lang/amaranth-soc@9f46553aa4289e2a11788a73fade6410a371b162 🚀
<tpw_rules>
Wanda[cis]: do you have a moment? wanted to talk a bit about the HPS stuff
<Wanda[cis]>
I do
<jfng[m]>
jfng[m]: @whitequark:matrix.org ok with this ?
<tpw_rules>
Wanda[cis]: so there needs to be a point, as far as i can tell, where the HPS "stuff" knows that nobody is going to request any more resources from it and only after that can it be elaborated.
<Wanda[cis]>
mhm
<Wanda[cis]>
because you have to emit the tieoffs at some point, right.
<tpw_rules>
i'm not sure how to mix that into the resource system right now. you had said it doesn't really make sense for the HPS block to be an Elaboratable, and long-term i agree, but i don't see how it can sensibly be done that way now
<galibert[m]>
How are pads done, given their Instance too in some way?
<galibert[m]>
They are damnit
<whitequark[cis]>
i think maybe it should be an elaboratable after all
<galibert[m]>
Fucking autocrap
<whitequark[cis]>
Wanda: its kinda like memory
<whitequark[cis]>
but a singleton
<tpw_rules>
there is specific code that does it in the platform
<whitequark[cis]>
galibert[m]: using cursed shit in platform files
<Wanda[cis]>
oh.
<Wanda[cis]>
a hps elaboratable, with a bunch of .axi_port and whatnot methods?
<galibert[m]>
Oh
<whitequark[cis]>
Wanda[cis]: yes
<Wanda[cis]>
I... guess
<tpw_rules>
but that does mix in to the other comments i'd seen on the issue tracker about how can we have Resources with logic behind them instead of just hardcoded pin stuff
<tpw_rules>
so maybe long term it could become that
<whitequark[cis]>
then it can be shoved into platform, or instsntiated directly
<whitequark[cis]>
tpw_rules: the entire resource system will get scrapped
<galibert[m]>
There’s kinky stuff like the interrupts, 32 lines you tend to want to address independently
<whitequark[cis]>
so don't tie to it too much
<galibert[m]>
In one Instance thingy
<tpw_rules>
ok. then i'm gonna prototype as an elaboratable and ignore the resource ssytem
<whitequark[cis]>
sgtm
<Wanda[cis]>
so the role of the platform would be reduced to constructing the elaboratable and keeping it on a field or something
<tpw_rules>
i think that's very tbd
<tpw_rules>
for the prototype i'm not going to involve the platform object either
<galibert[m]>
You have to add it to something’s submodules though, right?
<whitequark[cis]>
Wanda[cis]: yeah
<whitequark[cis]>
and the current pins system will become something like that too
<tpw_rules>
galibert[m]: yes, the user will
<galibert[m]>
Then it makes sense to provide stuff that is not singletons, like dsp blocks
<tpw_rules>
i don't follow
<galibert[m]>
also, how is intrinsic stuff managed, like the internal oscillator which is used as default oscillator outside of things like the eval boards?
<whitequark[cis]>
more hacks
<whitequark[cis]>
i mean, right now it's hacks.
<tpw_rules>
is an SoC meeting planned today? don't think i have anything in particular to discuss
<galibert[m]>
jfng said no because indeeed nothing on the agenda
<tpw_rules>
ok, missed that in the scrollback
<galibert[m]>
s/indeeed/indeed/
<tpw_rules>
i had a horrible idea last night of integrating scipy's integer linear programming solver to automatically generate PLL parameters
<whitequark[cis]>
i do want that in amaranth eventuall
<whitequark[cis]>
s/eventuall/eventually/
<galibert[m]>
you need a solver?
<whitequark[cis]>
but not via scipy, that's too heavy
<tpw_rules>
agreed
<whitequark[cis]>
tbqh often enough you can just enumerate all parameters
<galibert[m]>
to find the best intermediate frequency?
<tpw_rules>
i'm not so sure for cyclone v's 9 output plls and stuff i want like "exactly x Hz on out 1, but at least y Hz on out 2"
<tpw_rules>
it would also be interesting to have as a benchmark
<Wanda[cis]>
scipy sounds like major overkill
<tpw_rules>
i'm allergic to math and trust it lol, it could probably be replaced by something better
<Wanda[cis]>
usually you'd enumerate, say, all values for shared M and D parameters, then just compute per-output divisors in the obvious way, then pick the optimal combo
<Wanda[cis]>
like, this is a problem commonly solved with a hammer
<galibert[m]>
that's a lot of possible values
<Wanda[cis]>
you can't go wrong with a hammer
<tpw_rules>
yeah, i've done it that way for the ice40 PLLs
<whitequark[cis]>
cache it, lol
<tpw_rules>
but like i said i want to start adding constraints other than "closest"
<galibert[m]>
I mean, the divider fractional part in the cv fpll is 32 bits
<tpw_rules>
i am not sure if i would integrate fractional mode...
<tpw_rules>
at least not to start
<tpw_rules>
whitequark[cis]: would there be an external program to generate parameters?
<whitequark[cis]>
no, integrated
<tpw_rules>
how would they be cached?
<whitequark[cis]>
shove something into ~/.cache after it's computed?
<tpw_rules>
okay, don't love it
<whitequark[cis]>
why?
<tpw_rules>
nix brain mostly
<tpw_rules>
it's not wrong and it would work but it doesn't fill me with joy
<galibert[m]>
I don't really see what's hard with generating the parameters, what am I missing?
<whitequark[cis]>
well what else would you do?
<whitequark[cis]>
it's just a normal build step
<tpw_rules>
at least keep it with the project files
<whitequark[cis]>
the project may not even be in the filesystem (if you're importing it from a zip, which python allows)
<whitequark[cis]>
or be in read-only nix whateveritscalled
<tpw_rules>
i mean the build directory rather,
<whitequark[cis]>
not possible
<tpw_rules>
but that might not exist
<whitequark[cis]>
build directory is after you generate RTL
<whitequark[cis]>
this happens before any RTL gets written
<tpw_rules>
fair
<whitequark[cis]>
and it may even be fully in-memory, like glasgow does
<whitequark[cis]>
how does nix handle incremental builds of e.g. rust code?
<tpw_rules>
not sure off the top of my head, but it probably just doesn't™
<whitequark[cis]>
sounds like a nix problem then
<tpw_rules>
anyway there's lots of options
<whitequark[cis]>
(i only care about nix insofar as it solves my problems. if it creates a problem i stop caring about it)
<tpw_rules>
fair
<Wanda[cis]>
I don't know about nix, but caching shit sounds like a highly desirable feature
<Wanda[cis]>
and PLL calculations are something with very well-defined inputs and outputs
jjsuperpower has joined #amaranth-lang
jjsuperpower has quit [Ping timeout: 264 seconds]
<tpw_rules>
do i have to add a Resource to use a Connector?
<whitequark[cis]>
yes
<tpw_rules>
and Connector pins are indexed from 1 right
<tpw_rules>
yes afaict
<whitequark[cis]>
yeah
<whitequark[cis]>
like on schematics
zyp[m] has joined #amaranth-lang
<zyp[m]>
I'm not much a fan of defining connectors by physical pin numbers, when the stuff is redone I'd like a way to use logical numbers/names as well
<zyp[m]>
(like how on a schematic you can have a connector symbol that's arranged logically and not physically)
<tpw_rules>
whitequark[cis]: it is my displeasure to inform you that the new IR is disgusting quartus and it's not inferring DSPs right in my design now. i bisected it down to that commit. gonna examine the generated verilog next and then try to come up with a minimum example
<tpw_rules>
(6f44438e specifically)
<tpw_rules>
whitequark[cis]: looks like the new IR doesn't ever write $signed, not sure if that's legal?
<tpw_rules>
i'm filing an issue, please hold
<Wanda[cis]>
sigh.
<Wanda[cis]>
this is either going to be a yosys or quartus bug
<Wanda[cis]>
now I'm just waiting to see which
<Wanda[cis]>
(betting on quartus)
<Wanda[cis]>
but. good point. we're not actually setting signed wire attributes on anything.
<tpw_rules>
isn't * sensitive to signed? like + does the same thing independent of whether your numbers are signed or not but from my understanding * actually needs to change its behavior?
<Wanda[cis]>
it does not
<tpw_rules>
hm, okay
<Wanda[cis]>
there are other operators that are effected
<Wanda[cis]>
because NIR does not care about the difference
<Wanda[cis]>
but this may fail inference in Quartus
<Wanda[cis]>
argh.
<tpw_rules>
to be clear also everything works fine again if i wrap the *'s operands in $signed. it does also infer, but it infers some weird multi-block structure
<tpw_rules>
but i had written in my code to generate a signed multiplication and i thought there was a difference in semantics
<Wanda[cis]>
it could also be looking for $signed on additions or something
<tpw_rules>
it doesn't seem to care there
<Wanda[cis]>
there's no difference, as long as output is same length as both inputs
<Wanda[cis]>
which NIR ensures by construction
<Wanda[cis]>
this... ugh
<Wanda[cis]>
could be worked around by some heuristic in RTLIL output
<tpw_rules>
the new IR seems to generate somewhat more bizarre code anyway
<Wanda[cis]>
like?
<tpw_rules>
like i have mul_a in my module being passed to a submodule and instead of doing that it simplifies and passes a shortened signal, but then in both modules it generates a mul_a variable anyway, presumably for debugging
<Wanda[cis]>
hm
<Wanda[cis]>
right
<Wanda[cis]>
it's probably driven by a shorter cell than the signal?
<tpw_rules>
not reealy, i'm using a button to mux between 0 and -1. i think yosys must have simplified stuff
<Wanda[cis]>
oh yeah, the mux output is probably something like two bits long
<_whitenotifier-7>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 93d1166 - Deploying to main from @ amaranth-lang/amaranth@188eb8d4531e18602fd2886dde6d534abdb8bbe8 🚀
tarmoo has joined #amaranth-lang
<Wanda[cis]>
<tpw_rules> "is it possible to fix the..." <- that's more of a problem
<whitequark[cis]>
what thing?
tarmoo has quit [Quit: leaving]
<tpw_rules>
"like i have mul_a in my module being passed to a submodule and instead of doing that it simplifies and passes a shortened signal, but then in both modules it generates a mul_a variable anyway, presumably for debugging"