| *** tpb has joined #litex | 00:00 | |
| *** Degi_ has joined #litex | 00:14 | |
| *** Degi has quit IRC | 00:17 | |
| *** Degi_ is now known as Degi | 00:17 | |
| *** pauluzs has quit IRC | 00:51 | |
| *** mikeK_de1soc has quit IRC | 01:23 | |
| *** Bertl_oO is now known as Bertl_zZ | 04:07 | |
| *** TMM has quit IRC | 05:32 | |
| *** TMM has joined #litex | 05:32 | |
| *** FFY00_ has quit IRC | 05:48 | |
| Melkhior | nickoe It feels weird that you're writing to source.ready | 06:15 |
|---|---|---|
| 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 | 06:15 |
| Melkhior | presumably the address should remain valid until sink.ready is true again, when you can input the new address | 06:17 |
| zyp | no, you set source.ready when you're ready to receive and wait for source.valid | 06:17 |
| Melkhior | oh ok thx | 06:24 |
| Melkhior | too many signals for my 'soft' brain :-) | 06:26 |
| *** geertu has quit IRC | 06:36 | |
| *** geertu has joined #litex | 06:37 | |
| *** keesj has joined #litex | 07:26 | |
| *** pftbest_ has joined #litex | 07:37 | |
| *** pftbest has quit IRC | 07:40 | |
| *** Degi has quit IRC | 08:10 | |
| *** Degi has joined #litex | 08:12 | |
| acathla | wishbone-tool -u /dev/ttyUSB0 --csr-csv=csr.csv -s gdb | 10:06 |
| acathla | ERROR [wishbone_tool] invalid configuration: Terminal specified, but no xover uart addresses present in csv file | 10:06 |
| acathla | But I didn't ask for a crossover terminal, so why that answer? | 10:07 |
| acathla | https://github.com/litex-hub/wishbone-utils/blob/master/wishbone-tool/crates/core/config.rs#L340 seems okay | 10:10 |
| acathla | I use wishbone-tool v0.6.10 from fomu-toolchain 1.5.6 (last release I think) | 10:11 |
| zyp | you're running into https://github.com/litex-hub/wishbone-utils/issues/26 | 10:28 |
| zyp | fixed in 0.6.11 | 10:28 |
| *** kgugala has joined #litex | 11:28 | |
| *** kgugala has quit IRC | 11:28 | |
| *** kgugala has joined #litex | 11:28 | |
| *** kgugala_ has quit IRC | 11:29 | |
| *** bitinvert has joined #litex | 11:31 | |
| acathla | zyp, thank you. | 11:42 |
| acathla | "xobs : Good catch. I think this is a big enough issue to warrant a new minor release." | 11:42 |
| acathla | Yes it is :) | 11:42 |
| zyp | yeah, that release was 0.6.11 | 12:04 |
| *** FFY00_ has joined #litex | 12:04 | |
| zyp | wishbone-tool is up to 0.7.8 now, so an upgrade is due anyway :) | 12:04 |
| 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 :) | 12:44 |
| somlo | specifically, `thing2.sink.ready` and `thing1.source.valid`, if thing1 feeds data to thing2... | 12:45 |
| zyp | it's important to distinguish between being a sink or source and interacting with a sink or source too :) | 12:46 |
| Melkhior | @somlo thanks, was trying to understand/help @nickoe ; I haven't quite graduated from "basic migen" to "use streams in migen" yet, clearly | 12:46 |
| zyp | but I mean, this is just about flow control | 12:47 |
| zyp | the valid signal indicates that the transmitter is ready to send | 12:47 |
| zyp | the ready signal indicates that the receiver is ready to receive | 12:47 |
| Melkhior | And trying to figure out why my keyboard ignores some 'send command' request from my host, yet react to other almost immediately... | 12:47 |
| 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... | 12:48 |
| somlo | s/who/to figure out who/ | 12:48 |
| zyp | a source port is an output from a module, used for data flowing out of the module | 12:49 |
| zyp | and sinks are data flowing into the module | 12:49 |
| 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 | 12:49 |
| Melkhior | @zyp @somlo make sense | 12:56 |
| Melkhior | thx | 12:57 |
| 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: | 13:01 |
| Melkhior | self.comb += self.dma_read.sink.address.eq(self.addrgen_read.out) | 13:01 |
| Melkhior | self.comb += self.addr_gen.ready.eq(self.dma_read.sink.ready & self.addrgen_read.valid) | 13:01 |
| Melkhior | self.comb += self.dma_read.sink.valid.eq(self.addrgen_read.valid) | 13:01 |
| Melkhior | self.comb += self.dma_write.sink.address.eq(self.addrgen_write.out) | 13:01 |
| Melkhior | self.comb += self.addr_gen_ready.eq(self.dma_write.sink.ready & self.addrgen_write.valid & self.dma_read.source.valid) | 13:01 |
| Melkhior | self.comb += self.dma_write.sink.valid.eq(self.addrgen_write.valid & self.dma_read.source.valid) | 13:01 |
| Melkhior | self.comb += self.dma_write.sink.data.eq(self.dma_read.source.data) | 13:01 |
| *** Bertl_zZ is now known as Bertl | 13:01 | |
| 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 | 13:03 |
| Melkhior | and the source of the DMA_read is connected to the data sink of the DMA_write | 13:03 |
| 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) | 13:04 |
| Melkhior | mmm next to last is using self.addrgen_write.valid that should be self.addrgen_write.ready | 13:05 |
| Melkhior | no it should be valid | 13:06 |
| Melkhior | 7 lines and I can confuse myself :-) | 13:06 |
| *** mikeK_de1soc has joined #litex | 13:10 | |
| *** pftbest_ has quit IRC | 13:11 | |
| *** pftbest has joined #litex | 13:12 | |
| 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 | 13:17 |
| zyp | you'd do addrgen_read.source.connect(dma_read.sink), and so on | 13:17 |
| 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... :) | 13:18 |
| zyp | then you're not just hooking them up :) | 13:19 |
| zyp | but still, even if you're using connect() you can tap and override signals in a FSM | 13:19 |
| 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... :) | 13:21 |
| *** jhu has quit IRC | 14:57 | |
| *** mikeK_de1soc has quit IRC | 15:11 | |
| *** rj has joined #litex | 16:41 | |
| *** rj has quit IRC | 17:01 | |
| *** rj has joined #litex | 17:06 | |
| *** Melkhior has quit IRC | 17:18 | |
| *** rj has quit IRC | 17:58 | |
| *** rj has joined #litex | 18:06 | |
| nickoe | Can on set priorites for reads from the bus to the ram? | 18:06 |
| *** rj has quit IRC | 18:10 | |
| *** rj has joined #litex | 18:10 | |
| *** rj has quit IRC | 18:10 | |
| *** rj has joined #litex | 18:11 | |
| *** rj has quit IRC | 18:13 | |
| *** rj has joined #litex | 18:13 | |
| *** TMM has quit IRC | 18:56 | |
| *** TMM has joined #litex | 18:56 | |
| nickoe | Do you usually keep a sim of a SoC seperate for the implemenation script? | 19:34 |
| *** Degi has quit IRC | 19:53 | |
| *** keesj has quit IRC | 19:53 | |
| *** Degi has joined #litex | 19:55 | |
| *** keesj has joined #litex | 19:55 | |
| nickoe | Mmm, how was it that I started litex_server to work with the sim? | 20:23 |
| nickoe | does not appear to work litex_server --udp --udp-ip=192.168.1.50 | 20:24 |
| *** nats` has quit IRC | 22:28 | |
| 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 | 22:32 |
| nickoe | Using, lxterm --jtag-name jtag_uart --kernel demo.bin --serial-boot /dev/ttyUSB1 | 22:33 |
| nickoe | It just seems to hang forever | 22:34 |
| *** jon_ has joined #litex | 22:46 | |
| 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 | 22:55 |
| tpb | Title: dpaste: GRWYET3T9 (at dpaste.com) | 22:55 |
| *** rj has quit IRC | 22:56 | |
| *** rj has joined #litex | 22:56 | |
| 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? | 22:57 |
| *** rj has quit IRC | 22:59 | |
| nickoe | jon_: what is somolo's ecp5? | 23:02 |
| jon_ | https://www.contrib.andrew.cmu.edu/~somlo/BTCP/ | 23:03 |
| tpb | Title: A Trustworthy, Free (Libre), Linux Capable, Self-Hosting 64bit RISC-V Computer (at www.contrib.andrew.cmu.edu) | 23:04 |
| nickoe | mm, there is a `default_nettypenone in the top mof my included verilog file.. | 23:04 |
| *** lf has quit IRC | 23:15 | |
| *** lf has joined #litex | 23:15 | |
| nickoe | ok, removing that made the vivado synth happy | 23:16 |
| nickoe | ... | 23:16 |
| *** pftbest has quit IRC | 23:16 | |
| *** pftbest_ has joined #litex | 23:16 | |
| *** pftbest_ has quit IRC | 23:38 | |
| *** pftbest has joined #litex | 23:42 | |
| jon_ | For example is there a difference between the dev kits and a regular ECP5? | 23:49 |
| sorear | no the dev kits use a regular production ecp5 | 23:53 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!