_florent_ changed the topic of #litex to: LiteX FPGA SoC builder and Cores / Github : https://github.com/enjoy-digital, https://github.com/litex-hub / Logs: https://freenode.irclog.whitequark.org/litex
tpb has quit [Remote host closed the connection]
tpb has joined #litex
pftbest has quit [Remote host closed the connection]
Degi_ has joined #litex
Degi has quit [Ping timeout: 252 seconds]
Degi_ is now known as Degi
feldim2425 has quit [Ping timeout: 260 seconds]
feldim2425_ has joined #litex
feldim2425_ is now known as feldim2425
Emantor has quit [Quit: ZNC - http://znc.in]
Emantor has joined #litex
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #litex
Bertl is now known as Bertl_zZ
pftbest has joined #litex
kgugala_ has joined #litex
kgugala has quit [Ping timeout: 246 seconds]
pftbest has quit [Remote host closed the connection]
kgugala has joined #litex
kgugala_ has quit [Ping timeout: 246 seconds]
pftbest has joined #litex
<nickoe> ohh,... mmm, if I use cdc.source.ready to incremente the addr it work! ... I am not sure why that is... mmm
<zyp> because ready indicates when the receiver is ready for a new address
<zyp> so incrementing the address only when it's ready for a new address makes sense
<nickoe> ah, right. I am still not very intuitive to the signal names and directions :S
<nickoe> yes! I understand that, but I clearly mess it up sometimes :D
<nickoe> I think my thinking was that, if the sink is ready to receive,... but that signal is the ready signal in the middle of the chain instead of the end where I want to control it from
<nickoe> if that makes any sense at all
<zyp> each element in the pipeline only needs to consider the flow control signals of the elements it's directly adjacent to
<zyp> the bottleneck in your pipeline should be the DAC, since it's running at a fixed rate
<nickoe> yes
<zyp> the DAC will be fed by the DMA as fast as the DAC is ready to receive new data
<zyp> and then the DMA will be fed with new addrs as fast as it is ready to receive more addrs
<zyp> they will then naturally end up averaging the same rate, but since the DMA works in bursts, it'll also be ready for new addrs in bursts, not at an even rate
<zyp> and due to the flow control signals it should just work out
<zyp> maybe, I haven't studied the full picture of your application :)
<nickoe> dma -> cdc -> dac
* nickoe really needs to clean it up a bit now
<zyp> you should probably not do anything about cdc.source there, cdc.source is in the other clock domain
<zyp> if I'm reading it right
<nickoe> With that code it appears to work good, as https://i.snipboard.io/GHJYlm.jpg, ...
<nickoe> and now when I remove it it ALSO works :S odd
<nickoe> But finally it looks like I wanted it to two weeks ago. zyp Thank you very much for your help! I owe you a keg of beer.
<nickoe> zyp: Can I detect in a Module if this is a simulation?
<nickoe> ah, never mind, I don't need to
<nickoe> I just have the signalsin the simulation _io
kgugala_ has joined #litex
kgugala has quit [Ping timeout: 252 seconds]
<nickoe> mmm, right now the analyzer does not dump a lot over jtag
<nickoe> It just does: [uploading]... [> ] 0% [writing to dump.vcd]...
<nickoe> calling litescope_cli without args do seem to dump stuff
pftbest has quit [Ping timeout: 252 seconds]
<nickoe> zyp: For soe reason it just appears to be happy to consume addresses a bit too much https://i.snipboard.io/T8KYa2.jpg
<nickoe> I wonder why the dma.sink.ready has that strage pattern with one high cycle, one low, then a couple high.
<nickoe> That is on hardware. The sim looks good.
pftbest has joined #litex
Bertl_zZ is now known as Bertl
Bertl is now known as Bertl_oO
<nickoe> it is a bit hard to compare the traces https://i.snipboard.io/9HRmpj.jpg
<nickoe> at littele bit more https://i.snipboard.io/geh8WT.jpg
<nickoe> So on the target it appears that the dma.sink.ready signal is flopping a bit onre
<nickoe> a bit more
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #litex
<nickoe> restulting in the address being updated
lfforth has joined #litex
lfforth has quit [Client Quit]
chgavilana has joined #litex
<chgavilana> hi, over linux, gpioset work for all here? for me just gpio-hammer work for gpio on linux-on-litex-vexriscv using GPIOOut
pftbest has quit [Remote host closed the connection]
pftbest has joined #litex
pftbest has quit [Ping timeout: 240 seconds]
pftbest has joined #litex
pftbest has quit [Remote host closed the connection]
pftbest has joined #litex
pftbest has quit [Remote host closed the connection]
pftbest has joined #litex
pftbest has quit [Remote host closed the connection]
pftbest has joined #litex
pftbest has quit [Remote host closed the connection]
pftbest has joined #litex
pftbest has quit [Read error: No route to host]
pftbest has joined #litex
pftbest has quit [Remote host closed the connection]
pftbest has joined #litex
pftbest has quit [Remote host closed the connection]
pftbest has joined #litex
<nickoe> chgavilana: What are you talking about?
pftbest has quit [Remote host closed the connection]
pftbest has joined #litex
<chgavilana> in linux_on_litex_vexriscv project, what command do you use to control the gpios ?, is that sysfs is no longer in kernel 5+
<nickoe> Dunno, I am not really using the linux stuff in litex at the moment, but can't you just enable sysfs, evne though it is 5+?
<nickoe> I am not sure what the replacement for sysfs is.
lf has quit [Ping timeout: 245 seconds]
lf has joined #litex
peepsalot has quit [Remote host closed the connection]
peepsalot has joined #litex