<cr1901>
whitequark[cis]: Tyvm for the quick merge. This PR is the last MachXO2 one for boards I have. Would you be willing to approve this when you get the chance? It is a proper subset of changes you just approved: https://github.com/amaranth-lang/amaranth-boards/pull/136
frgo has joined #amaranth-lang
<cr1901>
jn: You can tell I have severe latency for testing MachXO2 stuff lmao
<jn>
ah, it happens, don't worry :)
frgo has quit [Ping timeout: 245 seconds]
zyp[m] has quit [Quit: Idle timeout reached: 172800s]
<whitequark[cis]>
uh, why are you inheriting from StructLayout?
<whitequark[cis]>
CacheAddr = data.StructLayout({ "index": unsigned(8), "tag": unsigned(22) }) is the pattern for anonymous structs (since if they're a class they're not, well, anonymous)
<cr1901>
Well, in the future, I plan to make it parametric. So I just put the scaffolding there
<cr1901>
should it be like signatures where def my_anon_sig(params): return Signature(params)?
<whitequark[cis]>
yeah, for the same reasons
<tpw_rules>
what makes a struct anonymous or not?
<whitequark[cis]>
nothing in Amaranth cares that you made a class, and your custom layout will be interchangeable with any other layout, with no warning
<whitequark[cis]>
data.StructLayouts don't have a name; data.Struct subclasses do
<tpw_rules>
i did a bunch of inheriting from Signature in my AXI stuff
<cr1901>
I was under the impression "inheriting from Signature is not good, but inheriting from the *Layouts was fine"
<cr1901>
Looks like the advice changed in the past year
<cr1901>
Or I misunderstood from the beginning. Who knows lol
<whitequark[cis]>
people keep wanting to inherit from stuff because, i think, Record abused inheritance a lot?
<whitequark[cis]>
sorry, let me rephrase more clearly, it's pretty late and i'm tired
<whitequark[cis]>
if you inherit the way the documentation says you should, that works fine and Signature is designed to be inherited from
<tpw_rules>
ok, i think i did that
<whitequark[cis]>
but if you do inheritance solely as a way to provide parameters, instead of using a method, it's broken
<whitequark[cis]>
(which is the thing people assumed they could continue doing, post-Record)
<tpw_rules>
i see, thanks as always!
<whitequark[cis]>
anyway, in case of StructLayout, there is just no benefit to it and it may confuse readers into thinking there will be any form of type safety, or that any of the code in Amaranth would care at all
<whitequark[cis]>
that RFC actually takes care to not misuse any of the introduced concepts
<cr1901>
well, hence I bastardized it :)
<whitequark[cis]>
right
<cr1901>
Anyways, will fix after my break. I was proud of this b/c I knocked out this working cache impl, tests and all, in about 90 minutes on a day I'm not feeling so great. So all in all happy with this little diversion
<whitequark[cis]>
yeah, everything else looks good at a quick glance
<whitequark[cis]>
I was just really surprised by that one bit
<tpw_rules>
so it's basically direct mapped?
<cr1901>
Yes, direct mapped, each line is a 32-bit word
<cr1901>
very very minimal, but I want something small
<tpw_rules>
(otherwise you would need an associative memory?)
<tpw_rules>
yes, fair. i think the rpi pico has something similar, lines being so small is a bit strange
<tpw_rules>
s/rpi pico/rp2040/
<tpw_rules>
still an XIP hater
<whitequark[cis]>
why?
frgo has quit [Ping timeout: 252 seconds]
<tpw_rules>
been working on a couple projects where it's a big big performance problem
<whitequark[cis]>
ah
<tpw_rules>
complex projects with a lot of code
<cr1901>
For micropython on TinyFPGA BX with XIP, adding a small icache (1024 byte, 16 bytes per line) doubles performance from my recollection. It's a lot of speedup for relatively little resources
<cr1901>
I simulate a slow wishbone memory using Amaranth processes, with a Signal() that lets me control the simulated delay. Then I sim a prime-counting firmware both with and without the cache. Tweak parameters and see how it changes how fast the firmware runs
<cr1901>
(Well, when I add parameters*)
<tpw_rules>
yeah, there's a lot of improvements you can make and it's not bad for all applications
<tpw_rules>
but if they could "just" give me lots and lots of processor speed-ish flash
<tpw_rules>
micropython is also pretty neat
<tpw_rules>
how fast is the CPU running in that case?
<cr1901>
lemme see if I can find the relevant tweet
<cr1901>
I thought one of my tweets printed out the CPU speed. It was probably either 12 or 48 MHz
<tpw_rules>
12 seems somewhat more likely
<tpw_rules>
i guess it's probably still a lot more capable than commodore basic or something :)
<cr1901>
It works better than you'd think for only 8-10kB of RAM
<cr1901>
256 entries was chosen because that's the minimum that usefully uses ice40 block RAMs. If I halve it, I can cram the data and tags into one BRAM each, except each one takes 2 cycles to read/write
<tpw_rules>
how big is the executable?
<cr1901>
Micropython? Oh I don't remember... definitely fit comfortably onto the SPI flash. The prime-counting one? Like 24 words?
<cr1901>
All the upy stuff is in backups, I'd have to dig it out
frgo has quit [Read error: Connection reset by peer]
frgo has joined #amaranth-lang
frgo has quit [Remote host closed the connection]
frgo has joined #amaranth-lang
FFY00_ has joined #amaranth-lang
FFY00 has quit [Ping timeout: 252 seconds]
urja has quit [Read error: Connection reset by peer]
mindw0rk has quit [Read error: Connection reset by peer]
urja has joined #amaranth-lang
mindw0rk has joined #amaranth-lang
<cr1901>
jfng: When you're around... how would I add a MemoryMap to my WB cache, to gate the set of addresses to which the icache responds, and redirect all other memory accesses to bypass the WB cache (implies mutually-exclusive paths, so no decoder needed)?
<cr1901>
465 LUTs, 8 BRAMs, 11 DFFs with synth_ice40
<whitequark[cis]>
nice
<cr1901>
>replacement policy becomes goofy <-- with n ways, there's n! permutations to keep track of the least recently used way. 2! is thankfully 2, so I can just stuff a "is this way the last used" bit into the tags BRAM data layout.
<cr1901>
And yea, that's about it. This was a fun diversion while I wait for several ppl to get to me lmao