<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_>
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
<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 :(
<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