<zyp[m]>
there's two parts to that; updating an add_sync_process testbench to an add_testbench testbench per RFC 27 should be pretty straight forward
<zyp[m]>
but to get something that's not still deprecated, you'll also have to update to the async API introduced in RFC 36, replacing every yield statement with the corresponding await statement
balrog has quit [Quit: Bye]
balrog has joined #amaranth-lang
Degi has quit [Ping timeout: 244 seconds]
Degi has joined #amaranth-lang
<conventia[m]>
Continuing to use yield results in a warning, but it doesn't support empty yields and some functions only have empty yields, like one with a loop that counts out half a period.
<conventia[m]>
I'm guessing there isn't a migration guide?
<conventia[m]>
Oh, do you simply replace yield with yield Tick()?
<conventia[m]>
That says what, not how, but it does list both things. 😛
<conventia[m]>
But apparently `yield` -> `yield Tick()` does work if you import `Tick` from `amaranth.sim`.
<cr1901>
simulator semantics changed when "yield" became "yield Tick()"; when it was just plain yield, any "yield m.my_sig.eq(val)" didn't take effect until the next bare yield (clock tick)
<conventia[m]>
Strange, some assertions fail now. I wonder why.
<cr1901>
But when "yield" became "yield Tick()", any "yield m.my_sig.eq(val)" takes effect the instant that the simulator sees the yield
<conventia[m]>
Does that mean I have to remove some yields?
<cr1901>
More likely, move them around, or place a "yield Tick()" before setting your signals
<conventia[m]>
Ah, I see. I didn't see that either. Perhaps my terminal/serial settings were off.
<cr1901>
If you're on Windows, make sure your FPGA dev board isn't seen as a serial mouse (I wish I was joking, and keep forgetting to add code to stop that)
<conventia[m]>
I'm pretty sure I was testing on the icebreaker on Linux.
<conventia[m]>
with picocom or minicom, forget which.
<cr1901>
Well if you go and test it again and it still doesn't work, please open an issue w/ a bitstream/build dir/invocation so I can check.
<anuejn>
does anyone by any chance have an ECPIX-5 board that they would sell / borrow me for a project? Sadly they seem kinda unavailable but for my use it would be the perject fit :)
<whitequark[cis]1>
DM me
korken89[m] has joined #amaranth-lang
<korken89[m]>
Hi all! I'm playing with a Colorlight A5-75B board with the aim to get some RGMII running en the end - but before that I'm porting old code I have from `nmigen`, specifically a PLL helper I found sometime long ago. The issue I'm... (full message at
<whitequark[cis]1>
you probably want to replace platform.request("something") with platform.request("something").i or platform.request("something").o
<whitequark[cis]1>
* you probably want to replace platform.request("clk25") with platform.request("clk25").i or platform.request("clk25").o
<korken89[m]>
You are my savior 🙏
<whitequark[cis]1>
you're welcome
jjsuperpower_ has joined #amaranth-lang
SpaceCoaster has quit [Ping timeout: 252 seconds]
SpaceCoaster has joined #amaranth-lang
SpaceCoaster has quit [Read error: Connection reset by peer]
SpaceCoaster has joined #amaranth-lang
SpaceCoaster has quit [Read error: Connection reset by peer]
<korken89[m]>
I'm a bit confused by the AsyncFIFO{Buffered} and how many block RAMs (in an ECP5) it will consume. Looking at the datasheet it seems that one EBR, can at best have a depth of 1024 with a data width of 18 (which aligns with the specced 18kb size) - however I'm able to set depth=2048 (with width=18) in a single, and before the utilization of EBR goes to 2 I need to set the depth=4096. So it seems like it fits 2x the number
<korken89[m]>
of bits that it should. Does anyone know what I've misunderstood? The EBRs are specced to 56pcs of 18kb in my LFE5U-25, which matches the reported number of DP16KD.
<whitequark[cis]1>
how much bits are you actually using?
<whitequark[cis]1>
s/much/many/
<whitequark[cis]1>
yosys performs some BRAM optimizations
<korken89[m]>
I'm filling it with a counter, just to "throw data in it". Maybe I've done something wrong there, I'll double check!
<whitequark[cis]1>
read the yosys log
<whitequark[cis]1>
yosys is what actually performs the techmapping, so it will have the explanation one way or another
<korken89[m]>
Hmm I wonder if it's doing something smart as I'm only using the top bit of the FIFO output to "blink a LED", based on the top bit of the counter.
<korken89[m]>
Mystery solved, it was too smart - by doing a bit of operations on the output bits the usage of EBR is in line with expected :D
<whitequark[cis]1>
yes
<korken89[m]>
A great opportunity to figure out how to see this in the logs!
<whitequark[cis]1>
the logs are kind of required reading for any real design
<korken89[m]>
Yeah, I need to get used to reading/understanding them again.