<BoM>
Not sure if I am at the right place, and just tell me if I do not follow any conventionnal usage !
<BoM>
I am working (learn/hobby) with Amaranth (on a ULX3S 85)
<BoM>
It seems that is is not possible to create Memory (8bit) deeper than 16384 (so 16KB). (and I think there is not even warning/error messages)
<BoM>
(may be because lattice 18kb blocks can do 16384x1bit)
<BoM>
May be I am wrong, an if not, probably this is not an amaranth problem (?)
<BoM>
Lattice limit ? Yosis/Nextpnr limit ?
<BoM>
Could closed tools go further ?
<BoM>
Is it a good pratice to try to assemble in your fpga some of these 16K to go further ?
<BoM>
thnks
<Degi>
Is there an error message?
<Degi>
When I try to make a large one, at least Amaranth works (but currently the rest is taking very long)
<BoM>
No message but when I look in top.tim :
<BoM>
Info: DP16KD: 8/ 208 3%
<BoM>
this confirms it did not when further
<Degi>
Isn't that right though? 16384 x 8 should place 8 of these blocks
<BoM>
I have that the fpga build process takes longer, so perhaps it tries
<BoM>
yes : 16384 x 8 is the limit
<BoM>
if I do 32768 * 8 I get the same result Info: DP16KD: 8/ 208 3%
<Degi>
When I try 20x65535 I get DP16KD: 80/ 208 38%
<Degi>
What are the other stats?
<Degi>
Is 16384 the width or the depth?
<Degi>
When I try width = 8, depth = 32767 I get "DP16KD: 16/ 208 7%" which makes sense, a bit weird that you still get 8
<Degi>
(depth = 32768 should produce the same result I think)
<BoM>
mem = Memory(width=8, depth=32768, attrs={})
<BoM>
Info: DP16KD: 8/ 208 3%
<Degi>
Ah, my code has a +1 so it was actually 32768. I can even do a Memory with 262144 and 8 bit width which utilizes 128 DP16KD. Are you maybe running a different / an old python file than the code is in? Can you maybe post your code?
<BoM>
(to ugly and mixed with stuff,;-) and perhaps it is the reason)
<Degi>
How wide are your read and write address signals?
<Degi>
If I have a Memory(width = width, depth = 262144) but the read and write addresses are 4 bits, then it only places 8 DP16KD since it doesn't need more (it would need 128 if all address bits were used)
<BoM>
Oh maybe you've found (?)
<BoM>
It is on a test "code" and no signal
<BoM>
only testing with this
<BoM>
m.d.sync += mem_write_port.addr.eq(10)
<Degi>
Yes, try a larger number, I think the toolchain tries to optimize everything (though I wonder a bit why it still placse 8 DP16KD, I thought less would be enough since they could somehow be reconfigured to be wider if I remember right)
<BoM>
Thanks Degi, you were right, if I use bigger address it than uses more blocks
<BoM>
so the toolchain optimize really (good job) ;-)
<Degi>
Tbh I didn't know about this either, but I suspected that since in general the toolchain really tries to optimize things and doesn't allow some things because of that (like making an inverter chain, I think it would work with manual placement, but last time I tried that it gave a circular logic error)
<BoM>
maybe your : 8 DP16KD can be explained by the tools trying to use blocs with 16384x1 configuration rather than 2048x8 , maybe more perfromance that way in that case ...
<BoM>
well thank you
<BoM>
It is quite a big adventure to learn all this fpga science on your own "alone" ... when you come from 100% software background
<Degi>
Hmm yes, my design runs at a few hundred MHz so it probably tries to optimize for speed
BoM has quit [Quit: Client closed]
BoM has joined #amaranth-lang
BoM has quit [Client Quit]
cr1901_ has quit [Remote host closed the connection]
<whitequark>
the FOSS toolchain isn't considering clock constraints during synthesis
<Degi>
Hmm okay, so its only to error when it doesn't meet it
<d1b2>
<dave berkeley> I want to be able to integrate Amaranth modules into Litex. Are there any docs for this? Is Litex ever likely to use Amaranth instead of migen?
<d1b2>
<TiltMeSenpai> I think the accepted way to do this is to render Amaranth into Verilog, then integrate the Verilog modules into Litex
<d1b2>
<TiltMeSenpai> there's instructions on that... somewhere?
<d1b2>
<dave berkeley> Okay, thanks. I think I know how to do that. I'm currently build a system with mixed VHDL and Amaranth.
pie_ has quit [Quit: pie_]
pie_ has joined #amaranth-lang
pie_ has quit [Quit: pie_]
pie_ has joined #amaranth-lang
<lsneff>
What would be the right way to set up something where a single signal can be synchronously driven by a parent module as well as by its submodules without flattening the whole thing?
<lsneff>
It's essentially a set of IRQ flags that need to be RW for both the outside system as well as internal systems.