<tpw_rules>
if i assert r_en on an AsyncFIFO, then i get r_data populated the next cycle. but what about the subsequent cycles if r_en is only asserted for one? in simulation the value doesn't seem to stay which is strange to me
skipwich has quit [Quit: DISCONNECT]
skipwich has joined #amaranth-lang
<iposthuman[m]>
Yeah! I was able to create an Amaranth board definition and then synthesize *blinky* onto Machdyne's Keks iCE40 SBC 😌 . I know it isn't much but it took me 2 weeks to learn Python + 2 weeks to learn Amaranth (beginner level) and another week to create the board def file. Now I need to figure out how to use pmods. I am not sure what kind of object request() is returning ```pmod_a = platform.request( 'pmod', 0 )```. 🤔
<adamgreig[m]>
notably you need to first platform.add_resource() to add a resource that uses that connector, then you can platform.request() your new resource, and then you can drive it
<adamgreig[m]>
if you're writing your own platform file anyway, you could also just put a resource on those same pins
<adamgreig[m]>
like in resources=[] add Resource("pmod_led", 0, Pins("C14", dir="o")), then you can platform.request("pmod_led")
<iposthuman[m]>
Ok. I don't know all what is possible with platform files. It was mostly a copy of icesugar board
<adamgreig[m]>
but it's "neater" to make it a connector in the platform and then attach resources to it in the normal code, depending on what you've actually plugged in to it
<iposthuman[m]>
Ok. i'll try that
<iposthuman[m]>
That makes sense and is more flexible.
<adamgreig[m]>
in principle a resource is for something that's permanently attached, like maybe an spi device, or some on-board LEDs or switches, or a clock, that sort of thing
<iposthuman[m]>
So pmods are pretty much going to almost demand the add_resource() approach. Understood.