_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
Degi_ has joined #litex
Degi has quit [Ping timeout: 252 seconds]
Degi_ is now known as Degi
pauluzs has quit [Remote host closed the connection]
mikeK_de1soc has quit [Quit: Connection closed]
Bertl_oO is now known as Bertl_zZ
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #litex
FFY00_ has quit [Ping timeout: 250 seconds]
<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]
geertu has joined #litex
keesj has joined #litex
pftbest_ has joined #litex
pftbest has quit [Ping timeout: 250 seconds]
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #litex
<acathla> wishbone-tool -u /dev/ttyUSB0 --csr-csv=csr.csv -s gdb
<acathla> ERROR [wishbone_tool] invalid configuration: Terminal specified, but no xover uart addresses present in csv file
<acathla> But I didn't ask for a crossover terminal, so why that answer?
<acathla> I use wishbone-tool v0.6.10 from fomu-toolchain 1.5.6 (last release I think)
<zyp> fixed in 0.6.11
kgugala has joined #litex
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>         self.comb += self.dma_read.sink.address.eq(self.addrgen_read.out)
<Melkhior>         self.comb += self.addr_gen.ready.eq(self.dma_read.sink.ready & self.addrgen_read.valid)
<Melkhior>         self.comb += self.dma_read.sink.valid.eq(self.addrgen_read.valid)
<Melkhior>         self.comb += self.dma_write.sink.address.eq(self.addrgen_write.out)
<Melkhior>         self.comb += self.addr_gen_ready.eq(self.dma_write.sink.ready & self.addrgen_write.valid & self.dma_read.source.valid)
<Melkhior>         self.comb += self.dma_write.sink.valid.eq(self.addrgen_write.valid & self.dma_read.source.valid)
<Melkhior>         self.comb += self.dma_write.sink.data.eq(self.dma_read.source.data)
Bertl_zZ is now known as Bertl
<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?
rj has quit [Client Quit]
rj has joined #litex
rj has quit [Client Quit]
rj has joined #litex
rj has quit [Client Quit]
rj has joined #litex
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #litex
<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> Using, lxterm --jtag-name jtag_uart --kernel demo.bin --serial-boot /dev/ttyUSB1
<nickoe> It just seems to hang forever
jon_ has joined #litex
<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?
rj has quit [Client Quit]
<nickoe> jon_: what is somolo's ecp5?
<tpb> Title: A Trustworthy, Free (Libre), Linux Capable, Self-Hosting 64bit RISC-V Computer (at www.contrib.andrew.cmu.edu)
<nickoe> mm, there is a `default_nettypenone in the top mof my included verilog file..
lf has quit [Ping timeout: 276 seconds]
lf has joined #litex
<nickoe> ok, removing that made the vivado synth happy
<nickoe> ...
pftbest has quit [Read error: Connection reset by peer]
pftbest_ has joined #litex
pftbest_ has quit [Remote host closed the connection]
pftbest has joined #litex
<jon_> For example is there a difference between the dev kits and a regular ECP5?
<sorear> no the dev kits use a regular production ecp5