<_florent_>
cr1901: for the TEC0117, the sipped SDRAM should be a MT48LC8M16A2
<_florent_>
(that's what I got from Gowin)
acathla has quit [Ping timeout: 268 seconds]
indy has quit [Ping timeout: 252 seconds]
indy has joined #litex
indy has quit [Ping timeout: 268 seconds]
Brinx has quit [Remote host closed the connection]
Brinx has joined #litex
Brinx has quit [Remote host closed the connection]
Brinx has joined #litex
Brinx has quit [Remote host closed the connection]
Brinx has joined #litex
Brinx has quit [Remote host closed the connection]
Brinx has joined #litex
Brinx has quit [Remote host closed the connection]
Brinx_ has joined #litex
shenchen has joined #litex
Brinx_ has quit [Remote host closed the connection]
Brinx has joined #litex
Brinx has quit [Ping timeout: 260 seconds]
Brinx has joined #litex
<tnt>
I'm a bit perplexed by some DMA performance results.
<tnt>
I have a block generating fake data, one word of the data path width every N cycles (with N being programmable).
<tnt>
That goes into a small fifo ( 2048 entries ) and then directly to the DMA sink.
<tnt>
Measured internal loopback performance is 33 Gbps/s. I set my block to generate 17.06 Gbps.
<tnt>
If I do a fwrite() of the buffer I receive to a file in RAMfs, I do measure 17.06G perf as expected (for as long as the mem isn't filled at least).
<tnt>
If I remove the fwrite (no other changes), ... bandwidht goes to 0.16 Gbps.
<tnt>
wtf ...
indy has joined #litex
Brinx has quit [Remote host closed the connection]
<cr1901>
pepijndevos[m]: I might have to poke gowin... what email address did you use?
<cr1901>
I suspect the DRAM module is different for the GW1NR-4
<pepijndevos[m]>
danny@gowinsemi.com I think but... I'm not the one who got the timing info so maybe that should count as a negative advice
<cr1901>
cc: _florent_ I suspect the DRAM module is different for the GW1NR-4 b/c it has a 32-bit mode as well as a 16-bit mode, and "plugging in" the MT48LC8M16 module only gets me a "half working" DRAM controller
<cr1901>
(i.e. some of the memory stores/read succeed, some don't)
<tnt>
You got a free RNG :)
<cr1901>
Which would be great if I was designing an RNG, but I'm not :(
FabM has quit [Quit: Leaving]
shenchen has quit [Remote host closed the connection]
shenchen has joined #litex
Brinx has joined #litex
Brinx has quit [Remote host closed the connection]
Brinx has joined #litex
Johnsel has joined #litex
<tnt>
fifo.sink is where I push data to right ?
<_florent_>
tnt: yes (regarding fifo.sink)
<_florent_>
cr1901: so 16-bit is working and 32-bit is not?
<_florent_>
cr1901: you can also eventually try to use the PHYPadsReducer to only compile with some of the byte groups
<nickoe>
I will try again, not sure if I missed a reply.
<cr1901>
_florent_: Ty for the tip, cache is disabled already :D
<nickoe>
Is it possible to define pins wihout them being suffixed wiht the number as in: ("io_in", 0, Pins(8)), becomes "output reg [7:0] io_out0"
<nickoe>
It gives me an exception when I do ("io_in", None, Pins(8)),
<_florent_>
nickoe: If you only have one "io_out" in your design, not sure the numbered suffix will be added (I'm not on a dev machine so could check tomorrow)
<nickoe>
yes, I have only one
<nickoe>
even if I browse the simulated output
<nickoe>
in gtkwave.
<nickoe>
But for ("sys_rst", 0, Pins(1)), it does not get added.
<nickoe>
I am not sure why.
<nickoe>
There is this that appears to handle it for the request