<_whitenotifier-8>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 7134e60 - Deploying to main from @ amaranth-lang/amaranth@a6d67f7477bfb820b3cec2491da219b99d9ef1a7 🚀
<_whitenotifier-8>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] e77e4e3 - Deploying to main from @ amaranth-lang/amaranth@a9212612153b83480fdfb00c3c2e7138bd38b485 🚀
<_whitenotifier-8>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] a5d0689 - Deploying to main from @ amaranth-lang/amaranth@cb5b0e38d9d5aa802ec825395ab559a37e33d150 🚀
sauce has joined #amaranth-lang
curiousmuch has joined #amaranth-lang
jjsuperpower_ has joined #amaranth-lang
jjsuperpower has quit [Read error: Connection reset by peer]
curiousmuch has quit [Quit: Client closed]
<d1b2>
<chuckmcm> So I'm adding two PMOD things to an Amaranth design. Are they modules? Are they a resource specification? Let's take an easy on, Digilent LED8 which is 8 LEDs, nothing else. I want to use this on any board I happen to have, so I think "Its a module." and when I instantiate it I can attach it to Board resources. But how about the Digilent I2S PMOD? It has sequential logic that needs to be synthesized to generate an audio stream. Does
<d1b2>
that work too?
<adamgreig[m]1>
in both cases i'd use platform.add_resources to add the new signals the pmod provides (be it led0, led1, or like lrclk, mclk, sdat, etc) to an existing pmod connector on the platform
<adamgreig[m]1>
and then my actual logic can request those new signals from the platform in the normal platform.request() way
<adamgreig[m]1>
the logic to generate an audio stream isn't linked to the pmod, it could run on a board with a directly attached codec or some other pmod or anything else
<d1b2>
<chuckmcm> That is the way I did it with Litex/Migen. I'm wondering if there is a way to be more generalized to enhance re-use. The variables are what the platform calls its signal lines vs a 'standardized' definition of the PMOD.
<d1b2>
<chuckmcm> I am wondering if there is a way to have a PMOD repository like we have a board repository, and a templatable way to say addPMOD(<pmod-module>, <board-defined-pmod-connector>)
<d1b2>
<chuckmcm> It may not be doable but I can imagine it would be neat if the code was p = SomePlatform() leds = DigilentLED8(p.port[0]) leds[0] = 1;
<galibert[m]1>
For my culture, what’s a pmod?
<d1b2>
<chuckmcm> It was a standard for plug in modules (PMOD) promoted by Digilent. If you search on Digikey for example for PMOD you can see some examples.
<galibert[m]1>
Ahhh ok
<galibert[m]1>
A specific kind of shield, in arduino’s parlance?
<d1b2>
<chuckmcm> Another system that is similar standard "Mikro" something which I can never remember with a bit more I/O pins and a huge selection of I/O boards.
<d1b2>
<chuckmcm> Less than a shield. PMODs were typically 8 bits of I/O VCC + GND.
<d1b2>
<chuckmcm> They make rapidly prototyping an idea from a "generic" FPGA board both fast and durable (easy to show the client how it becomes a dedicated board for their application)
<galibert[m]1>
Interesting
<d1b2>
<chuckmcm> Conceptually I'd love to bid an idea, and then come in the next day with a demo. I don't always get to pick the FPGA architecture the client wants to use so things like Amaranth are really useful here for re-using work done across a variety of platforms. Anyway, it may not be possible but I know to never doubt what Whitequark can do!
<galibert[m]1>
She want to redesign the platform stuff anyway for very good reasons
<d1b2>
<vegard_e> I'd also like a convenient way to describe an assembly of modules, and it shouldn't be restricted to a single level
<whitequark[cis]>
you can already do that
<whitequark[cis]>
connectors can refer to other connectors
<d1b2>
<vegard_e> are they named globally or hierarchically though? what happens if I've got a butterstick with two syzygy to pmod adapter boards?
<whitequark[cis]>
globally
<d1b2>
<vegard_e> hmm, does the current system support resources that span multiple connectors? e.g. dual width pmods?
<whitequark[cis]>
the connector system is just a level of indirection triggered by having : in a name
<d1b2>
<vegard_e> I'm familiar with litex' :-syntax
<cr1901>
Is there currently a freeze on accepting new boards/PRs for new boards?
<whitequark[cis]>
not an official one, it's just that i don't have review bandwidth for boards atm, so if your PR 100% passes i merge it, otherwise it kind of languishes
<whitequark[cis]>
this will change but not in the next few weeks