| *** tpb <[email protected]> has joined #litex | 00:00 | |
| *** Degi <[email protected]> has quit IRC (Ping timeout: 248 seconds) | 01:03 | |
| *** Degi_ <[email protected]> has joined #litex | 01:03 | |
| *** Degi_ is now known as Degi | 01:03 | |
| *** sebo <[email protected]> has joined #litex | 04:01 | |
| *** sebo <[email protected]> has quit IRC (Ping timeout: 268 seconds) | 04:08 | |
| tnt | _florent_: I think the weirdness was because I had the analyzer in the wrong clock domain and because of timing errors. | 05:42 |
|---|---|---|
| tnt | What is the clock domain those signals are in ? It doesn't actually seem to be 'pcie' either ... | 05:42 |
| *** FabM <[email protected]> has joined #litex | 06:44 | |
| *** nelgau_ <[email protected]> has joined #litex | 06:50 | |
| *** nelgau <[email protected]> has quit IRC (Ping timeout: 256 seconds) | 06:52 | |
| _florent_ | tnt: The sink of PHYTXDatapath is in sys clk domain, source in pcie clk domain | 07:23 |
| _florent_ | tnt: The sink of PHYRXDatapath is in pcie clk domain, source in sys clk domain | 07:24 |
| tnt | _florent_: ok, yeah, that's what I thought. Weird. I guess it's some weird ness with the pcie block. | 07:32 |
| tnt | Does litescope re-register the input signals ? | 07:32 |
| tnt | Ah well there is a "register=False" so I'm guessing switching that to true would do the trick :D | 07:41 |
| _florent_ | tnt: that's indeed its purpose :) | 07:52 |
| cr1901 | _florent_: I'm playing around w/ sources and sinks again. Just to reiterate, sources and sinks are from the POV of outside the current module? | 08:08 |
| _florent_ | cr1901: Hi, yes exactly | 08:09 |
| cr1901 | http://gopher.wdj-consulting.com:70/paste/c0a54b7a-a526-4d3d-bbba-98975125f5d5.txt Hello! I created this really small example | 08:09 |
| cr1901 | http://gopher.wdj-consulting.com:70/paste/7c791054-901b-48fd-a289-c56fbf9a1ca2.txt Do the port module directions look correct to you? | 08:10 |
| cr1901 | The directions make sense to me; an "output" source indicates that the module is being a source for something else downstream | 08:11 |
| cr1901 | And an "input" sink indicates that the module is a sink for something upstream | 08:11 |
| cr1901 | _florent_: Is my understanding correct?^ | 08:12 |
| _florent_ | yes this looks fine | 08:14 |
| cr1901 | Hmmm, my UART instantiation appears to be missing some ports | 08:19 |
| _florent_ | tx and rx IOs seem commented | 08:20 |
| cr1901 | yes, that's deliberate | 08:21 |
| _florent_ | just said this in case these were the missing ports :) | 08:21 |
| * cr1901 nods :D | 08:21 | |
| cr1901 | _florent_: I want "the full Verilog instantiation of the UART module from litex.soc.cores.uart" | 08:21 |
| cr1901 | But uart.source/sink doesn't seem enough, because that's only two endpoints, both connected to the PHY | 08:22 |
| cr1901 | if both endpoints are connected to the PHY, where do I send/received data to the UART? :) | 08:22 |
| cr1901 | Am I supposed to add tx_fifo.sink, rx_fifo.source to my port list? | 08:23 |
| _florent_ | Sorry I'm not sure to understand what you want to export | 08:24 |
| _florent_ | is it: UART core with CSR bus interface + stream endpoints? | 08:25 |
| cr1901 | https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/uart.py#L215 | 08:25 |
| _florent_ | UART core with CSR bus interface + tx/rx pads? | 08:25 |
| cr1901 | No, just all ports from the linked class | 08:25 |
| cr1901 | No PHY, no CSR bus interface | 08:25 |
| cr1901 | just the UART class | 08:25 |
| *** vup <[email protected]> has quit IRC (Remote host closed the connection) | 08:26 | |
| cr1901 | And I'm trying to figure out the port list... self.source/sink are obviously part of it | 08:26 |
| *** vup <[email protected]> has joined #litex | 08:27 | |
| *** gruetzkopf <gruetzkopf!~quassel@wireguard/tunneler/gruetzkopf> has quit IRC (Quit: No Ping reply in 180 seconds.) | 08:27 | |
| *** kbeckmann <[email protected]> has quit IRC (Ping timeout: 240 seconds) | 08:27 | |
| cr1901 | _florent_: Put another way, "If I were to export Verilog for _just_ the UART class in litex.soc.cores.uart, what is the complete list of ios inside the module I should export? | 08:28 |
| *** mupuf <[email protected]> has quit IRC (Quit: No Ping reply in 180 seconds.) | 08:28 | |
| _florent_ | The UART class is a core with CSR Bus on the control side and stream endpoints, so I'm not sure how you want to export it without a CSR bus interface? | 08:28 |
| cr1901 | Oh. I just want to study how streams work | 08:29 |
| *** gruetzkopf <gruetzkopf!~quassel@wireguard/tunneler/gruetzkopf> has joined #litex | 08:29 | |
| cr1901 | Using a minimal real example | 08:29 |
| cr1901 | that e.g. connects sinks to sinks :) https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/uart.py#L267 | 08:29 |
| cr1901 | B/c I still don't understand and I'm trying to power thru | 08:29 |
| cr1901 | _florent_: Sorry for the XY problem | 08:29 |
| *** mupuf <[email protected]> has joined #litex | 08:30 | |
| *** kbeckmann <[email protected]> has joined #litex | 08:30 | |
| tnt | cr1901: The "UART" module is really just the register interface. | 08:32 |
| cr1901 | Yea, that's fine for my purposes. I just want to study that part | 08:32 |
| tnt | cr1901: if you want something that creates ... rs232 rx/tx what you want is actually the "PHY". | 08:32 |
| * cr1901 nods | 08:32 | |
| cr1901 | I don't actually want the PHY right now. I just want to study the register interface and confirm that I understand how to play with streams | 08:33 |
| cr1901 | if that makes sense | 08:33 |
| cr1901 | (it might sound like a waste of time, but I want to start w/ the smallest unit and work my way up) | 08:33 |
| tnt | Err ... the issue is probably that being an "AutoCSR" thing, a bunch of stuff is grafted to it automagically when integrated in a SoC. | 08:33 |
| _florent_ | cr1901: Here is a simple example of streams exported to verilog: https://gist.github.com/enjoy-digital/5fbbb28af32822517aaf6beec9c2b3c9 | 08:33 |
| tnt | without it ... it'll be missing a bunch of stuff. | 08:33 |
| cr1901 | Okay, so how do I automatically get just the CSR interface in the exported code | 08:34 |
| cr1901 | _florent_: Tyvm | 08:34 |
| _florent_ | it can create configurable AXI-ST converters from LiteX's converter (and also package it for Vivado but this part will not be interesting for you) | 08:35 |
| _florent_ | But this should show you how to create a simple generator, export IOs and connect streams to IOs/Internally | 08:35 |
| cr1901 | I sometimes see you connect sinks to sinks (including in the UART code). Why does that work and not conflict with DIR_M_TO_S? | 08:36 |
| cr1901 | or DIR_S_TO_M | 08:36 |
| _florent_ | and as just said tnt, when using AutoCSR, you have to use LiteX's Builder. | 08:36 |
| cr1901 | ditto for connecting sources to sources | 08:36 |
| cr1901 | ahhh, I thought maybe finalize() would save me :( | 08:36 |
| _florent_ | For this, you can have a look at this: https://github.com/enjoy-digital/litex/blob/master/litex/tools/litex_gen.py | 08:37 |
| cr1901 | Ahhh neat | 08:38 |
| _florent_ | or more complex ones: https://github.com/enjoy-digital/litedram/blob/master/litedram/gen.py | 08:38 |
| _florent_ | or: https://github.com/enjoy-digital/litepcie/blob/master/litepcie/gen.py | 08:38 |
| _florent_ | cr1901: hmm, in fact the LiteSDCard generator is probably very close to what you want to do with the UART: https://github.com/enjoy-digital/litesdcard/blob/master/litesdcard/gen.py | 08:39 |
| *** joseng <[email protected]> has quit IRC (Ping timeout: 250 seconds) | 08:40 | |
| _florent_ | cr1901: it packages the LiteSDCard core and only expose a Wishbone interface for control + IRQ and the SDCard pins. | 08:40 |
| _florent_ | you could: | 08:41 |
| cr1901 | Yea this is what I wanted, just so I can study the generated verilog | 08:41 |
| _florent_ | replace the SDCard IOs here with UART ones: https://github.com/enjoy-digital/litesdcard/blob/master/litesdcard/gen.py#L44-L50 | 08:41 |
| _florent_ | then remove this: https://github.com/enjoy-digital/litesdcard/blob/master/litesdcard/gen.py#L63-L91 | 08:42 |
| _florent_ | and replace it with the UART core | 08:42 |
| cr1901 | Okay, I have plenty of examples now :D | 08:43 |
| cr1901 | Uhhh, I want to go back to my stream question before it gets lots | 08:43 |
| cr1901 | lost* | 08:43 |
| cr1901 | In what situations is it appropriate to connect source-to-source, and sink-to-sink? | 08:44 |
| cr1901 | https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/uart.py#L267 Because I see it here, and I'm looking at it, and it's not clicking | 08:44 |
| cr1901 | A stream Endpoint doesn't "encode" whether it's a source or a sink by itself | 08:45 |
| cr1901 | Based on how you connect an Endpoint, a stream becomes a source or sink | 08:46 |
| cr1901 | But why is connecting a sink to a sink _not_ a driver conflict? | 08:46 |
| cr1901 | Or a source to a source* | 08:46 |
| _florent_ | cr1901: Quick adaptation of the LiteSDCard generator for UART: | 08:50 |
| _florent_ | https://www.irccloud.com/pastebin/CvNIsWTH/ | 08:50 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 08:50 |
| cr1901 | Cool thanks | 08:51 |
| cr1901 | Oooh, this works well | 08:52 |
| _florent_ | cr1901: you are generally only doing source-to-source/sink-to-sink connection when propagating things from/to internal submodules | 08:52 |
| _florent_ | imagine you have a module, with a sink and source endpoint | 08:53 |
| _florent_ | in this module, the endpoints are connected to another internal submodule | 08:53 |
| _florent_ | you'll then do a sink-to-sink connection to propagate the stream to the internal submodule | 08:54 |
| _florent_ | and also do a source-to-source connection for the output | 08:54 |
| cr1901 | Ahhhh. So it's a side effect of "choosing a consistent direction for source and sinks" | 08:54 |
| *** geertu <[email protected]> has quit IRC (Quit: leaving) | 08:54 | |
| _florent_ | yes | 08:55 |
| cr1901 | If/when you do a streams tutorial, I think maybe there should be a blurb very similar to what you just explained to me | 08:56 |
| cr1901 | to prevent the next person from being thrown off | 08:57 |
| cr1901 | What you're saying makes sense | 08:57 |
| cr1901 | I just didn't "see" it until you explained it | 08:57 |
| cr1901 | (also, the UART gen by itself is very useful.) | 08:57 |
| *** lexano <[email protected]> has quit IRC (Ping timeout: 246 seconds) | 09:01 | |
| _florent_ | cr1901: sure, feedback like yours is useful to know which things seems obvious but are in fact not. I'll make sure to integrate this. | 09:11 |
| *** Emantor_ <[email protected]> has quit IRC (Quit: ZNC - http://znc.in) | 09:14 | |
| *** lexano <[email protected]> has joined #litex | 09:14 | |
| *** Emantor <[email protected]> has joined #litex | 09:16 | |
| *** joseng <[email protected]> has joined #litex | 09:19 | |
| tnt | _florent_: definitely still a bit confused looking at the completions TLPs. For instance, here's the first few https://pastebin.com/muZmM1yx | 09:55 |
| tpb | Title: 4A000040 00000200 01000000 67 DWs4A000040 00000100 01000000 67 DWs - Pastebin.com (at pastebin.com) | 09:55 |
| tnt | The second DW which should be 'byte count' AFAIU doesn't seem to reflect that at all. | 09:56 |
| tnt | then we get multiple completion for the request wiht tag=0 with the same "lower address" field. | 09:56 |
| tnt | (oh wait, that last one is not an issue, completions from a request that got split are nto re-ordered, so we just get sequentially). | 09:58 |
| _florent_ | Indeed for the last one. | 10:00 |
| _florent_ | If you are able to do a capture of the completion that is confusing you, before and after adaptation, I could have a closer look | 10:01 |
| tnt | nm. I was misunderstanding the "Byte Count" field. Quick google said it was the numbe rof valid bytes returned, but that's not true. That's the numbe rof byte remaining to satisfy the request. | 10:15 |
| _florent_ | tnt: ok good, thanks for the check. | 10:15 |
| tnt | So yeah all looks good now. Tx for the help :) | 10:16 |
| _florent_ | np. BTW, did you received my messages regarding the XTRX rev4/rev5 SPI DAC? | 10:18 |
| tnt | Ah sorty forgot about that. | 10:18 |
| tnt | But I don't have rev5 schematics :/ | 10:18 |
| _florent_ | ah ok, I thought you had it, so not sure you'll have the information then :) Thanks anyway. | 10:20 |
| tnt | But I thought v4 and v5 were electrically compatible (It's the same XDC in the official repo) and it was just DFM changes. | 10:22 |
| _florent_ | The DAC for the VCXO is apparently different and strangely does not seem to be responding to an i2c_scan on the rev5. | 10:23 |
| _florent_ | I'll try to get a rev5 to be able to probe things directly | 10:24 |
| tnt | mmm, I mean, the software is OSS right so the code should be in there for that dac ? | 10:26 |
| _florent_ | yes, the code is here for the different DACs but the code is a bit difficult to follow. There something we are probably missing, I'll have a closer look. | 10:35 |
| tnt | Is there a doc somewhere for the litedram native port ? | 12:36 |
| tnt | AFAICT it's just 3 streams and you feed independent addresses every cycle and the controller internally determinates if it's in the same column and merge as a burst. | 12:43 |
| _florent_ | tnt: yes exactly. The controller will be able to automatically regroup the bursts. It's also possible to use the AXI-frontend on top if you want to avoid the Native mode | 14:48 |
| *** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (Quit: Leaving) | 14:50 | |
| *** Xesxen_ is now known as Xesxen | 15:18 | |
| *** ilia__s <[email protected]> has quit IRC (Ping timeout: 260 seconds) | 16:21 | |
| *** nelgau_ <[email protected]> has quit IRC (Ping timeout: 272 seconds) | 18:46 | |
| *** nelgau <[email protected]> has joined #litex | 18:57 | |
| *** nats` <nats`[email protected]> has joined #litex | 21:48 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!