<mcc111[m]>
<whitequark[cis]> "virtually soc-related things are..." <- then the pocket might be more interesting in that it has a mildly demanding capability set (video, sound, must interact with verilog via registers)
<mcc111[m]>
<tpw_rules> "mcc111: do you have specific..." <- i wanna make a drop-in-or-close replacement for the openfpga-litex core, which is buggy and hard to extend because litex is brittle
<tpw_rules>
i don't know that soc is ready to be that, or aiming to be that
<tpw_rules>
really the only thing in is the CSR system and a couple minor peripherals. you could write an adapter from the analogue bus, but the rest you would have to come up with yourself
<tpw_rules>
the CSR system is very good and powerful indeed though
<tpw_rules>
(there's also some wishbone stuff but i don't know anything about that)
<tpw_rules>
in my design i am using it with some custom audio peripherals and the initiator is the arm cpu in a cyclone v soc
<tpw_rules>
it should not be too hard to mix it with a wishbone compatible cpu though
<tpw_rules>
mcc111[m]: what litex peripherals does the openfpga-litex core use?
<mcc111[m]>
<tpw_rules> "really the only thing in is..." <- i can write adapters as long as i have a solid foundation
<mcc111[m]>
tpw_rules: i don't know enough about the core to answer that.
<tpw_rules>
oh. it credited you
<tpw_rules>
looks like the dram and video controllers
<tpw_rules>
there's no DMA yet in amaranth-soc either
<tpw_rules>
mcc111[m]: perhaps those features could be prototyped; i'm not sure what the maintainers have for ideas there
<mcc111[m]>
dma is important for video. the model openfpga-litex is using i don't think it's needed however.
<tpw_rules>
does it use a framebuffer?
<tpw_rules>
or something more old-skool?
<tpw_rules>
there is a bus arbiter and writing a little state machine with a big fifo to do video should not be hard. i would be a bit more worried about the dram controller but that could be borrowed and sequestered
<tpw_rules>
(or just use BRAM...)
<mcc111[m]>
It currently uses a framebuffer.
<mcc111[m]>
openfpga-litex maps different kinds of ram into different ranges of memory space, so there's like a chunk of memory that's slightly faster i think. probably it would be ok if "video memory" were restricted on this variant.
<mcc111[m]>
But I'd like it if I could fit like, I dunno, at least 8x the size of the screen in the available-for-video memory.
<tpw_rules>
the pocket has the psram and stuff too, maybe we don't even need the dram
<_whitenotifier-6>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 7614941 - Deploying to main from @ amaranth-lang/amaranth@16f187e7fa128fe013ea347c408772206583cb63 🚀
adamgreig[m] has quit [Quit: Idle timeout reached: 172800s]
<_whitenotifier-6>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 193ec1a - Deploying to main from @ amaranth-lang/amaranth@122be7849ccc6258ea9d6cdf47c96f1ff1c63608 🚀
<_whitenotifier-6>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] f853e2e - Deploying to main from @ amaranth-lang/amaranth@8bf4f77616cba3efda53ce9a15217e64fff70fac 🚀
<_whitenotifier-6>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 6fd4ef4 - Deploying to main from @ amaranth-lang/amaranth@3fbed68365fb4f0ab5b14e305167467845adbd95 🚀
<_whitenotifier-6>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 229a809 - Deploying to main from @ amaranth-lang/amaranth@877a1062a67811b12000fe1f46e0c93e9b4dbc7b 🚀
<cr1901>
In my text box was "Why does Amaranth not use tox?" Trying to write a pytest plugin for Amaranth sim, where pytest ecosystem prefers tox, and I think I understand (doesn't interact very well with pdm).
<whitequark[cis]>
it doesn't use tox because i don't see a point in using tox
<cr1901>
(oh, and GHA matrix can do the same thing, more or less)
<whitequark[cis]>
pdm can now install multiple python versions too
<cr1901>
I don't plan on submitting a plugin upstream, but I still feel like I should use best practices for their ecosystem. So now I have "pdm creates a venv under .venv, which includes tox, and tox-pdm, and then pdm invokes tox, which creates a venv under .tox, installs pdm in that tox env, invokes pdm to read pyproject.toml at the root, and _then_ installs deps in the tox venv"
<cr1901>
That was a word salad... wtaf?!
<cr1901>
pdm can now install multiple python versions too <-- oh?
<cr1901>
I'll have to check that out
<whitequark[cis]>
yeah I don't think I want any of that unless it's extremely well motivated
<_whitenotifier-5>
[amaranth] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-1333-877a1062a67811b12000fe1f46e0c93e9b4dbc7b - https://github.com/amaranth-lang/amaranth
<cr1901>
I'd like to note that tox can't install python interpreters, so maybe pdm is a superset of what tox can do (just inertia means projects haven't migrated/use it)
<_whitenotifier-5>
[amaranth-lang/amaranth] whitequark 8c1c9f2 - docs: begin building the documentation style guide.
<_whitenotifier-6>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] bd6ad46 - Deploying to main from @ amaranth-lang/amaranth@8c1c9f2d260ef3e4e8c279db708ae5d6152a49b2 🚀
FFY00_ has quit [Read error: Connection reset by peer]