<whitequark[cis]>
can you post your complete (non-minimized) code?
<conventia[m]>
It seems like yosys doesn't infer memories for the registers or the memory when defined using amaranth `Array`, so when I ran out of space with step 15, I figured I'd try to use `Memory` explicitly. Unfortunately, that's the step that adds support for load instructions so it's likely that the timing is off.
<whitequark[cis]>
Amaranth is designed to avoid the error prone "inference" step for memories
<whitequark[cis]>
if you want a memory, use the lib.Memory class
<whitequark[cis]>
* the lib.memory.Memory class
<conventia[m]>
I thought I did use that. I was just pointing out that the original code didn't and it wasn't inferred. (I prefer this design decision.)
<whitequark[cis]>
oh, I misunderstood then
<whitequark[cis]>
and yeah, reading your code I see you using the Memory class
<conventia[m]>
I mean, I prefer that Amaranth uses explicit objects rather than inference. 🙂
<whitequark[cis]>
okay, now that i'm at my desk, let's take a look
<whitequark[cis]>
I'm a bit confused, you say you have a problem on icebreaker, but the platform (in blink.py) is arty a7?
<conventia[m]>
I'm running it using `board/icebreaker.py` which I added in the last commit.
<whitequark[cis]>
okay, i see
<whitequark[cis]>
i've checked your code and it seems that you're just using the default sync clock domain as defined by the platform code, which is good: iCE40 FPGAs have a silicon bug which affects BRAMs and the platform code contains a workaround for it
<conventia[m]>
It didn't support icebreaker before, but with Amaranth, that's trivial.
<whitequark[cis]>
from a cursory look at the code you wrote, i don't see anything that stands out to me as obviously wrong
<conventia[m]>
My plan was to add Memory to each step individually and see which one starts failing and then debug that. It's probably still useful to do that.
<ydnatag[m]>
One question regarding hw limitations and erratas, I'm having some troubles with ecp5 reset. I've read that ecp5 cant implement sync reset but yosis can synthesize async reset for the register. Is that right? I haven't tested that yet but i'ce seen that the default reset for missing domains for ecp5 is done by the globar reset and generating the domain as reset less
<ydnatag[m]>
With the current reset, i'm having issues with some validated cores i designed, they dont use any hw specific resource, i think it is only because of the reset values of the registers (for example, the tx of a uart core keeps in 0 until i send a byte, then it behaves as expected)
<whitequark[cis]>
"I've read that ecp5 cant implement sync reset but yosis can synthesize async reset for the register. Is that right?" i don't think this is right
<whitequark[cis]>
you can implement sync reset if the only thing you have is a plain DFF by adding a mux in front of the D input
<whitequark[cis]>
so it doesn't really matter whether the hardware supports it or not (I don't remember the ECP5 FF capabilities offhand, but it also doesn't matter)
<whitequark[cis]>
there isn't any very strong reason to use the SGSR primitive over an explicit reset on ECP5, this is just what the people working on ECP5 have told me at the time
<whitequark[cis]>
without seeing the core I can't comment further, but also you could always add your own "sync" domain reset in whichever way you think would be most appropriate for your design
<ydnatag[m]>
<whitequark[cis]> "there isn't any very strong..." <- I tried to create a top level not using "create_missing_domain", but it does not work as expected (i can't remember the behaviour in hw). And with the domain created by the platform i had the issue that init values were ignored. I will try again on Monday and confirm (or not, maybe i'm completly wrong xD) what I'm saying
<whitequark[cis]>
were you using nextpnr-ecp5 or diamond?
<ydnatag[m]>
Nextpnr
<ydnatag[m]>
Yowasp yosys and nextpnr :)
<whitequark[cis]>
that's pretty odd, yeah
<whitequark[cis]>
if you can make a small reproducer demonstrating that init values are ignored (really this would be down to lighting a single LED with an undriven flop...) then that would go a long way towards fixing this
<ydnatag[m]>
Sure! Will do!
<ydnatag[m]>
One thing with the current created domain is that, it has a reset, but i cant acces to the reset signal because it is created as reset less, so i cant propagate the reset signal to other domains. I think that it is not an issue because i think sgsr is the global reset but it breaks many othee cores i have that access to the parent reset and adds more logic to the local reset, something like:
<duskwuff[m]>
Doesn't that (i.e. sync reset with a fabric signal) cause routing / fanout issues in large designs? Or is this not a serious issue on ECP5?
<whitequark[cis]>
it's the same as for clocks: global routing is used for high fanout signals
Degi has quit [Ping timeout: 244 seconds]
Degi has joined #amaranth-lang
anubis has quit [Ping timeout: 248 seconds]
<galibert[m]>
Do you people know of a way to compute 2**x with x in [0, 1[ ? 12 bits for x, 1.12 for the result
<zyp[m]>
if your x is effectively y/4096 where y is an integer, you could theoretically precalculate k=21/4096 with sufficient resolution and then just do ky
<zyp[m]>
* if your x is effectively y/4096 where y is an integer, you could theoretically precalculate k=2**1/4096 with sufficient resolution and then just do k**y
<zyp[m]>
since a**(b/c) == (a**(1/b)**c
<zyp[m]>
s//`/, s/b/c/, s/c/b`/
<zyp[m]>
* since a**(b/c) == (a**(1/c))**b
<ydnatag[m]>
Maybe I'm wrong, but I think it can be resolved using cordic.
<tpw_rules>
yes that's what cordic is for but it might be unnecessary for this particular case. depends how big k is i suppose
<galibert[m]>
I think you'd lose precision way too fast
<galibert[m]>
x is 0.10 (not 12, sorry) so yeah y/1024
<galibert[m]>
anyway, I found a different solution I think :-)