Wednesday, 2022-04-06

*** tpb <[email protected]> has joined #litex00:00
*** Degi <[email protected]> has quit IRC (Ping timeout: 248 seconds)01:03
*** Degi_ <[email protected]> has joined #litex01:03
*** Degi_ is now known as Degi01:03
*** sebo <[email protected]> has joined #litex04: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
tntWhat is the clock domain those signals are in ? It doesn't actually seem to be 'pcie' either ...05:42
*** FabM <[email protected]> has joined #litex06:44
*** nelgau_ <[email protected]> has joined #litex06: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 domain07:23
_florent_tnt: The sink of PHYRXDatapath is in pcie clk domain, source in sys clk domain07:24
tnt_florent_: ok, yeah, that's what I thought. Weird. I guess it's some weird ness with the pcie block.07:32
tntDoes litescope re-register the input signals ?07:32
tntAh well there is a "register=False" so I'm guessing switching that to true would do the trick :D07: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 exactly08:09
cr1901 Hello! I created this really small example08:09
cr1901 Do the port module directions look correct to you?08:10
cr1901The directions make sense to me; an "output" source indicates that the module is being a source for something else downstream08:11
cr1901And an "input" sink indicates that the module is a sink for something upstream08:11
cr1901_florent_: Is my understanding correct?^08:12
_florent_yes this looks fine08:14
cr1901Hmmm, my UART instantiation appears to be missing some ports08:19
_florent_tx and rx IOs seem commented08:20
cr1901yes, that's deliberate08:21
_florent_just said this in case these were the missing ports :)08:21
* cr1901 nods :D08:21
cr1901_florent_: I want "the full Verilog instantiation of the UART module from litex.soc.cores.uart"08:21
cr1901But uart.source/sink doesn't seem enough, because that's only two endpoints, both connected to the PHY08:22
cr1901if both endpoints are connected to the PHY, where do I send/received data to the UART? :)08:22
cr1901Am 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 export08:24
_florent_is it: UART core with CSR bus interface + stream endpoints?08:25
_florent_UART core with CSR bus interface + tx/rx pads?08:25
cr1901No, just all ports from the linked class08:25
cr1901No PHY, no CSR bus interface08:25
cr1901just the UART class08:25
*** vup <[email protected]> has quit IRC (Remote host closed the connection)08:26
cr1901And I'm trying to figure out the port list... self.source/sink are obviously part of it08:26
*** vup <[email protected]> has joined #litex08:27
*** gruetzkopf <[email protected]/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
cr1901Oh. I just want to study how streams work08:29
*** gruetzkopf <[email protected]/tunneler/gruetzkopf> has joined #litex08:29
cr1901Using a minimal real example08:29
cr1901that e.g. connects sinks to sinks :)
cr1901B/c I still don't understand and I'm trying to power thru08:29
cr1901_florent_: Sorry for the XY problem08:29
*** mupuf <[email protected]> has joined #litex08:30
*** kbeckmann <[email protected]> has joined #litex08:30
tntcr1901: The "UART" module is really just the register interface.08:32
cr1901Yea, that's fine for my purposes. I just want to study that part08:32
tntcr1901: if you want something that creates ... rs232 rx/tx what you want is actually the "PHY".08:32
* cr1901 nods08:32
cr1901I 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 streams08:33
cr1901if that makes sense08: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
tntErr ... 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:
tntwithout it ... it'll be missing a bunch of stuff.08:33
cr1901Okay, so how do I automatically get just the CSR interface in the exported code08:34
cr1901_florent_: Tyvm08: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/Internally08:35
cr1901I 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
cr1901or DIR_S_TO_M08:36
_florent_and as just said tnt, when using AutoCSR, you have to use LiteX's Builder.08:36
cr1901ditto for connecting sources to sources08:36
cr1901ahhh, I thought maybe finalize() would save me :(08:36
_florent_For this, you can have a look at this:
cr1901Ahhh neat08:38
_florent_or more complex ones:
_florent_cr1901: hmm, in fact the LiteSDCard generator is probably very close to what you want to do with the UART:
*** 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
cr1901Yea this is what I wanted, just so I can study the generated verilog08:41
_florent_replace the SDCard IOs here with UART ones:
_florent_then remove this:
_florent_and replace it with the UART core08:42
cr1901Okay, I have plenty of examples now :D08:43
cr1901Uhhh, I want to go back to my stream question before it gets lots08:43
cr1901In what situations is it appropriate to connect source-to-source, and sink-to-sink?08:44
cr1901 Because I see it here, and I'm looking at it, and it's not clicking08:44
cr1901A stream Endpoint doesn't "encode" whether it's a source or a sink by itself08:45
cr1901Based on how you connect an Endpoint, a stream becomes a source or sink08:46
cr1901But why is connecting a sink to a sink _not_ a driver conflict?08:46
cr1901Or a source to a source*08:46
_florent_cr1901: Quick adaptation of the LiteSDCard generator for UART:08:50
tpbTitle: Snippet | IRCCloud (at
cr1901Cool thanks08:51
cr1901Oooh, this works well08:52
_florent_cr1901: you are generally only doing source-to-source/sink-to-sink connection when propagating things from/to internal submodules08:52
_florent_imagine you have a module, with a sink and source endpoint08:53
_florent_in this module, the endpoints are connected to another internal submodule08:53
_florent_you'll then do a sink-to-sink connection to propagate the stream to the internal submodule08:54
_florent_and also do a source-to-source connection for the output08:54
cr1901Ahhhh. 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
cr1901If/when you do a streams tutorial, I think maybe there should be a blurb very similar to what you just explained to me08:56
cr1901to prevent the next person from being thrown off08:57
cr1901What you're saying makes sense08:57
cr1901I just didn't "see" it until you explained it08: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 -
*** lexano <[email protected]> has joined #litex09:14
*** Emantor <[email protected]> has joined #litex09:16
*** joseng <[email protected]> has joined #litex09:19
tnt_florent_: definitely still a bit confused looking at the completions TLPs.  For instance, here's the first few
tpbTitle: 4A000040 00000200 01000000 67 DWs4A000040 00000100 01000000 67 DWs - (at
tntThe second DW which should be 'byte count' AFAIU doesn't seem to reflect that at all.09:56
tntthen 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 look10:01
tntnm. 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
tntSo 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
tntAh sorty forgot about that.10:18
tntBut 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
tntBut 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 directly10:24
tntmmm, 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
tntIs there a doc somewhere for the litedram native port ?12:36
tntAFAICT 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 mode14:48
*** FabM <[email protected]/team/FabM> has quit IRC (Quit: Leaving)14:50
*** Xesxen_ is now known as Xesxen15: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 #litex18:57
*** nats` <nats`[email protected]> has joined #litex21:48

Generated by 2.17.2 by Marius Gedminas - find it at!