_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://libera.irclog.whitequark.org/litex
tpb has quit [Remote host closed the connection]
tpb has joined #litex
Degi has quit [Ping timeout: 248 seconds]
Degi_ has joined #litex
Degi_ is now known as Degi
sebo has joined #litex
sebo has quit [Ping timeout: 268 seconds]
<tnt> _florent_: I think the weirdness was because I had the analyzer in the wrong clock domain and because of timing errors.
<tnt> What is the clock domain those signals are in ? It doesn't actually seem to be 'pcie' either ...
FabM has joined #litex
FabM has quit [Changing host]
FabM has joined #litex
nelgau_ has joined #litex
nelgau has quit [Ping timeout: 256 seconds]
<_florent_> tnt: The sink of PHYTXDatapath is in sys clk domain, source in pcie clk domain
<_florent_> tnt: The sink of PHYRXDatapath is in pcie clk domain, source in sys clk domain
<tnt> _florent_: ok, yeah, that's what I thought. Weird. I guess it's some weird ness with the pcie block.
<tnt> Does litescope re-register the input signals ?
<tnt> Ah well there is a "register=False" so I'm guessing switching that to true would do the trick :D
<_florent_> tnt: that's indeed its purpose :)
<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?
<_florent_> cr1901: Hi, yes exactly
<cr1901> http://gopher.wdj-consulting.com:70/paste/7c791054-901b-48fd-a289-c56fbf9a1ca2.txt Do the port module directions look correct to you?
<cr1901> The directions make sense to me; an "output" source indicates that the module is being a source for something else downstream
<cr1901> And an "input" sink indicates that the module is a sink for something upstream
<cr1901> _florent_: Is my understanding correct?^
<_florent_> yes this looks fine
<cr1901> Hmmm, my UART instantiation appears to be missing some ports
<_florent_> tx and rx IOs seem commented
<cr1901> yes, that's deliberate
<_florent_> just said this in case these were the missing ports :)
* cr1901 nods :D
<cr1901> _florent_: I want "the full Verilog instantiation of the UART module from litex.soc.cores.uart"
<cr1901> But uart.source/sink doesn't seem enough, because that's only two endpoints, both connected to the PHY
<cr1901> if both endpoints are connected to the PHY, where do I send/received data to the UART? :)
<cr1901> Am I supposed to add tx_fifo.sink, rx_fifo.source to my port list?
<_florent_> Sorry I'm not sure to understand what you want to export
<_florent_> is it: UART core with CSR bus interface + stream endpoints?
<_florent_> UART core with CSR bus interface + tx/rx pads?
<cr1901> No, just all ports from the linked class
<cr1901> No PHY, no CSR bus interface
<cr1901> just the UART class
vup has quit [Remote host closed the connection]
<cr1901> And I'm trying to figure out the port list... self.source/sink are obviously part of it
vup has joined #litex
gruetzkopf has quit [Quit: No Ping reply in 180 seconds.]
kbeckmann has quit [Ping timeout: 240 seconds]
<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?
mupuf has quit [Quit: No Ping reply in 180 seconds.]
<_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?
<cr1901> Oh. I just want to study how streams work
gruetzkopf has joined #litex
<cr1901> Using a minimal real example
<cr1901> B/c I still don't understand and I'm trying to power thru
<cr1901> _florent_: Sorry for the XY problem
mupuf has joined #litex
kbeckmann has joined #litex
<tnt> cr1901: The "UART" module is really just the register interface.
<cr1901> Yea, that's fine for my purposes. I just want to study that part
<tnt> cr1901: if you want something that creates ... rs232 rx/tx what you want is actually the "PHY".
* cr1901 nods
<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
<cr1901> if that makes sense
<cr1901> (it might sound like a waste of time, but I want to start w/ the smallest unit and work my way up)
<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.
<_florent_> cr1901: Here is a simple example of streams exported to verilog: https://gist.github.com/enjoy-digital/5fbbb28af32822517aaf6beec9c2b3c9
<tnt> without it ... it'll be missing a bunch of stuff.
<cr1901> Okay, so how do I automatically get just the CSR interface in the exported code
<cr1901> _florent_: Tyvm
<_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)
<_florent_> But this should show you how to create a simple generator, export IOs and connect streams to IOs/Internally
<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?
<cr1901> or DIR_S_TO_M
<_florent_> and as just said tnt, when using AutoCSR, you have to use LiteX's Builder.
<cr1901> ditto for connecting sources to sources
<cr1901> ahhh, I thought maybe finalize() would save me :(
<_florent_> For this, you can have a look at this: https://github.com/enjoy-digital/litex/blob/master/litex/tools/litex_gen.py
<cr1901> Ahhh neat
<_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
joseng has quit [Ping timeout: 250 seconds]
<_florent_> cr1901: it packages the LiteSDCard core and only expose a Wishbone interface for control + IRQ and the SDCard pins.
<_florent_> you could:
<cr1901> Yea this is what I wanted, just so I can study the generated verilog
<_florent_> replace the SDCard IOs here with UART ones: https://github.com/enjoy-digital/litesdcard/blob/master/litesdcard/gen.py#L44-L50
<_florent_> and replace it with the UART core
<cr1901> Okay, I have plenty of examples now :D
<cr1901> Uhhh, I want to go back to my stream question before it gets lots
<cr1901> lost*
<cr1901> In what situations is it appropriate to connect source-to-source, and sink-to-sink?
<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
<cr1901> A stream Endpoint doesn't "encode" whether it's a source or a sink by itself
<cr1901> Based on how you connect an Endpoint, a stream becomes a source or sink
<cr1901> But why is connecting a sink to a sink _not_ a driver conflict?
<cr1901> Or a source to a source*
<_florent_> cr1901: Quick adaptation of the LiteSDCard generator for UART:
<tpb> Title: Snippet | IRCCloud (at www.irccloud.com)
<cr1901> Cool thanks
<cr1901> Oooh, this works well
<_florent_> cr1901: you are generally only doing source-to-source/sink-to-sink connection when propagating things from/to internal submodules
<_florent_> imagine you have a module, with a sink and source endpoint
<_florent_> in this module, the endpoints are connected to another internal submodule
<_florent_> you'll then do a sink-to-sink connection to propagate the stream to the internal submodule
<_florent_> and also do a source-to-source connection for the output
<cr1901> Ahhhh. So it's a side effect of "choosing a consistent direction for source and sinks"
geertu has quit [Quit: leaving]
<_florent_> yes
<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
<cr1901> to prevent the next person from being thrown off
<cr1901> What you're saying makes sense
<cr1901> I just didn't "see" it until you explained it
<cr1901> (also, the UART gen by itself is very useful.)
lexano has quit [Ping timeout: 246 seconds]
<_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.
Emantor_ has quit [Quit: ZNC - http://znc.in]
lexano has joined #litex
Emantor has joined #litex
joseng has joined #litex
<tnt> _florent_: definitely still a bit confused looking at the completions TLPs. For instance, here's the first few https://pastebin.com/muZmM1yx
<tpb> Title: 4A000040 00000200 01000000 67 DWs4A000040 00000100 01000000 67 DWs - Pastebin.com (at pastebin.com)
<tnt> The second DW which should be 'byte count' AFAIU doesn't seem to reflect that at all.
<tnt> then we get multiple completion for the request wiht tag=0 with the same "lower address" field.
<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).
<_florent_> Indeed for the last one.
<_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
<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.
<_florent_> tnt: ok good, thanks for the check.
<tnt> So yeah all looks good now. Tx for the help :)
<_florent_> np. BTW, did you received my messages regarding the XTRX rev4/rev5 SPI DAC?
<tnt> Ah sorty forgot about that.
<tnt> But I don't have rev5 schematics :/
<_florent_> ah ok, I thought you had it, so not sure you'll have the information then :) Thanks anyway.
<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.
<_florent_> The DAC for the VCXO is apparently different and strangely does not seem to be responding to an i2c_scan on the rev5.
<_florent_> I'll try to get a rev5 to be able to probe things directly
<tnt> mmm, I mean, the software is OSS right so the code should be in there for that dac ?
<_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.
<tnt> Is there a doc somewhere for the litedram native port ?
<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.
<_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
FabM has quit [Quit: Leaving]
Xesxen_ is now known as Xesxen
ilia__s has quit [Ping timeout: 260 seconds]
nelgau_ has quit [Ping timeout: 272 seconds]
nelgau has joined #litex
nats` has joined #litex