<Melkhior>
nickoe It feels weird that you're writing to source.ready
<Melkhior>
my understanding is that when sink.ready is true you can put an address in the sink (sink.valid, sink.addr), then you wait for source.ready to be able to read source.data
<Melkhior>
presumably the address should remain valid until sink.ready is true again, when you can input the new address
<zyp>
no, you set source.ready when you're ready to receive and wait for source.valid
<Melkhior>
oh ok thx
<Melkhior>
too many signals for my 'soft' brain :-)
geertu has quit [Remote host closed the connection]
kgugala has quit [Read error: Connection reset by peer]
kgugala has joined #litex
kgugala_ has quit [Ping timeout: 252 seconds]
bitinvert has joined #litex
bitinvert has quit [Client Quit]
<acathla>
zyp, thank you.
<acathla>
"xobs : Good catch. I think this is a big enough issue to warrant a new minor release."
<acathla>
Yes it is :)
<zyp>
yeah, that release was 0.6.11
FFY00_ has joined #litex
<zyp>
wishbone-tool is up to 0.7.8 now, so an upgrade is due anyway :)
<somlo>
zyp, Melkhior: to me, assuming source and sink are `connect`-ed, then the least amount of cognitive load would be to write `sink.ready` and `source.valid` -- but not sure that's "canonical" or "best practice" or whatever :)
<somlo>
specifically, `thing2.sink.ready` and `thing1.source.valid`, if thing1 feeds data to thing2...
<zyp>
it's important to distinguish between being a sink or source and interacting with a sink or source too :)
<Melkhior>
@somlo thanks, was trying to understand/help @nickoe ; I haven't quite graduated from "basic migen" to "use streams in migen" yet, clearly
<zyp>
but I mean, this is just about flow control
<zyp>
the valid signal indicates that the transmitter is ready to send
<zyp>
the ready signal indicates that the receiver is ready to receive
<Melkhior>
And trying to figure out why my keyboard ignores some 'send command' request from my host, yet react to other almost immediately...
<somlo>
right, but the idea is to make it easy for the reader (usually myself a few months later) who the reader and writer involved are...
<somlo>
s/who/to figure out who/
<zyp>
a source port is an output from a module, used for data flowing out of the module
<zyp>
and sinks are data flowing into the module
<zyp>
whether you'll write or read the signals will depend whether you're on the outside of the module looking in, or on the inside looking out
<Melkhior>
@zyp @somlo make sense
<Melkhior>
thx
<Melkhior>
so... if i wanted to have 2 DMA streams back-to-back, the reader feeding into the writer w/ 2 addr generators (i.e. hw block copy), I would so something like:
<Melkhior>
so that the source of the addrgen_read is connected to the addr. sink of the DMA_read, the source of the addrgen_write is connected to the addr. sink of the DMA_write
<Melkhior>
and the source of the DMA_read is connected to the data sink of the DMA_write
<Melkhior>
(pure curiosity, the linux console doesn't support hardware blitter for scrolling anymore and that's was the original reason for putting 2 DMAs back to back connected to 2 litedram port)
<Melkhior>
mmm next to last is using self.addrgen_write.valid that should be self.addrgen_write.ready
<Melkhior>
no it should be valid
<Melkhior>
7 lines and I can confuse myself :-)
mikeK_de1soc has joined #litex
pftbest_ has quit [Remote host closed the connection]
pftbest has joined #litex
<zyp>
part of the point of streams is that you shouldn't have to deal with the individual signals when you're just hooking them up
<zyp>
you'd do addrgen_read.source.connect(dma_read.sink), and so on
<somlo>
zyp: except that a lot of FSM magic needs to know when a source.valid & sink.ready happen, to know when it's time to jump to a new state... :)
<zyp>
then you're not just hooking them up :)
<zyp>
but still, even if you're using connect() you can tap and override signals in a FSM
<somlo>
I'm not a migen or streams ninja by any stretch of the imagination, I've just been trying to study some of the litesdcard sources recently, and there's a lot of that in there... :)
jhu has quit [Quit: Connection closed]
mikeK_de1soc has quit [Quit: Connection closed]
rj has joined #litex
rj has quit [Ping timeout: 240 seconds]
rj has joined #litex
Melkhior has quit [Quit: Connection closed]
rj has quit [Quit: rj]
rj has joined #litex
<nickoe>
Can on set priorites for reads from the bus to the ram?
<nickoe>
Do you usually keep a sim of a SoC seperate for the implemenation script?
Degi has quit [*.net *.split]
keesj has quit [*.net *.split]
Degi has joined #litex
keesj has joined #litex
<nickoe>
Mmm, how was it that I started litex_server to work with the sim?
<nickoe>
does not appear to work litex_server --udp --udp-ip=192.168.1.50
nats` has quit [Read error: Connection reset by peer]
<nickoe>
on a real target, why can't I load the demo.bin with lxterm via jtag? I have self.add_jtagbone() in the target, I can get theident with litex_cli --ident etc. I can get traces with litescope via that litex_server, started via jtag
<nickoe>
mmm, vivado is not really happy of me adding a simple verilog file that ... starts to complain about some verilog files from VexRiscv... https://dpaste.com/GRWYET3T9
<tpb>
Title: dpaste: GRWYET3T9 (at dpaste.com)
rj has quit [Quit: rj]
rj has joined #litex
<jon_>
Hi there, I'm new here. I'm trying to purchase an FPGA to start doing dev similar to Somlo's ECP5 but both ECPIX-5 and ecp5-5g-versa boards are sold out from most suppliers. Are their other ECP5 options for recreating Somlos work? Perhaps the Lambda Connector 45k is enough?