00:00
tpb has quit [Remote host closed the connection]
00:00
tpb has joined #litex
00:02
pftbest has quit [Remote host closed the connection]
00:06
Degi_ has joined #litex
00:07
Degi has quit [Ping timeout: 252 seconds]
00:07
Degi_ is now known as Degi
00:34
feldim2425 has quit [Ping timeout: 260 seconds]
00:34
feldim2425_ has joined #litex
00:34
feldim2425_ is now known as feldim2425
01:23
Emantor has joined #litex
04:32
TMM has joined #litex
04:36
Bertl is now known as Bertl_zZ
07:00
pftbest has joined #litex
07:23
kgugala_ has joined #litex
07:27
kgugala has quit [Ping timeout: 246 seconds]
07:32
pftbest has quit [Remote host closed the connection]
08:09
kgugala has joined #litex
08:12
kgugala_ has quit [Ping timeout: 246 seconds]
08:15
pftbest has joined #litex
08:46
<
nickoe >
ohh,... mmm, if I use cdc.source.ready to incremente the addr it work! ... I am not sure why that is... mmm
09:00
<
zyp >
because ready indicates when the receiver is ready for a new address
09:00
<
zyp >
so incrementing the address only when it's ready for a new address makes sense
09:01
<
nickoe >
ah, right. I am still not very intuitive to the signal names and directions :S
09:01
<
nickoe >
yes! I understand that, but I clearly mess it up sometimes :D
09:05
<
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
09:05
<
nickoe >
if that makes any sense at all
09:06
<
zyp >
each element in the pipeline only needs to consider the flow control signals of the elements it's directly adjacent to
09:07
<
zyp >
the bottleneck in your pipeline should be the DAC, since it's running at a fixed rate
09:07
<
zyp >
the DAC will be fed by the DMA as fast as the DAC is ready to receive new data
09:08
<
zyp >
and then the DMA will be fed with new addrs as fast as it is ready to receive more addrs
09:09
<
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
09:09
<
zyp >
and due to the flow control signals it should just work out
09:10
<
zyp >
maybe, I haven't studied the full picture of your application :)
09:11
<
nickoe >
dma -> cdc -> dac
09:13
* nickoe
really needs to clean it up a bit now
09:13
<
zyp >
you should probably not do anything about cdc.source there, cdc.source is in the other clock domain
09:13
<
zyp >
if I'm reading it right
09:17
<
nickoe >
and now when I remove it it ALSO works :S odd
09:18
<
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.
09:26
<
nickoe >
zyp: Can I detect in a Module if this is a simulation?
09:27
<
nickoe >
ah, never mind, I don't need to
09:27
<
nickoe >
I just have the signalsin the simulation _io
10:11
kgugala_ has joined #litex
10:14
kgugala has quit [Ping timeout: 252 seconds]
10:35
<
nickoe >
mmm, right now the analyzer does not dump a lot over jtag
10:36
<
nickoe >
It just does: [uploading]... [> ] 0% [writing to dump.vcd]...
10:40
<
nickoe >
calling litescope_cli without args do seem to dump stuff
11:47
pftbest has quit [Ping timeout: 252 seconds]
11:50
<
nickoe >
I wonder why the dma.sink.ready has that strage pattern with one high cycle, one low, then a couple high.
11:52
<
nickoe >
That is on hardware. The sim looks good.
11:57
pftbest has joined #litex
13:27
Bertl_zZ is now known as Bertl
13:34
Bertl is now known as Bertl_oO
14:04
<
nickoe >
So on the target it appears that the dma.sink.ready signal is flopping a bit onre
14:04
<
nickoe >
a bit more
14:04
TMM has joined #litex
14:04
<
nickoe >
restulting in the address being updated
15:47
lfforth has joined #litex
15:50
lfforth has quit [Client Quit]
16:42
chgavilana has joined #litex
16:44
<
chgavilana >
hi, over linux, gpioset work for all here? for me just gpio-hammer work for gpio on linux-on-litex-vexriscv using GPIOOut
16:56
pftbest has quit [Remote host closed the connection]
16:58
pftbest has joined #litex
17:02
pftbest has quit [Ping timeout: 240 seconds]
17:23
pftbest has joined #litex
17:26
pftbest has quit [Remote host closed the connection]
17:27
pftbest has joined #litex
17:29
pftbest has quit [Remote host closed the connection]
17:30
pftbest has joined #litex
17:51
pftbest has quit [Remote host closed the connection]
17:52
pftbest has joined #litex
17:52
pftbest has quit [Remote host closed the connection]
19:33
pftbest has joined #litex
19:36
pftbest has quit [Read error: No route to host]
19:36
pftbest has joined #litex
19:55
pftbest has quit [Remote host closed the connection]
19:56
pftbest has joined #litex
20:56
pftbest has quit [Remote host closed the connection]
20:57
pftbest has joined #litex
21:18
<
nickoe >
chgavilana: What are you talking about?
21:32
pftbest has quit [Remote host closed the connection]
21:32
pftbest has joined #litex
21:40
<
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+
21:44
<
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+?
21:45
<
nickoe >
I am not sure what the replacement for sysfs is.
23:09
lf has quit [Ping timeout: 245 seconds]
23:10
lf has joined #litex
23:21
peepsalot has quit [Remote host closed the connection]
23:21
peepsalot has joined #litex