<whitequark>
felix_: there was something weird about it
<whitequark>
oh yeah maybe it had a thunderbolt controller stuck on the pcie bus provided by a thunderbolt controller?
Degi has quit [Ping timeout: 256 seconds]
Degi has joined ##openfpga
emeb has quit [Quit: Leaving.]
jaseg has quit [Ping timeout: 244 seconds]
jaseg has joined ##openfpga
Bike has quit [Quit: leaving]
jaseg has quit [Ping timeout: 246 seconds]
jaseg has joined ##openfpga
bsilvereagle has quit [Changing host]
bsilvereagle has joined ##openfpga
genii has quit [Quit: See you soon.]
gregdavill has joined ##openfpga
<azonenberg>
Anybody here worked with the pcie hard IP on xilinx parts? curious what level it runs at vs the soft wrapper
<azonenberg>
do you get PIPE out of that and the TLP stuff is done in soft fabric? or do you get TLPs?
<azonenberg>
and has anyone tried to RE whatever interface the hard IP has so you can use it from open gateware?
<whitequark>
take a look at litepcie
<whitequark>
it does that
<azonenberg>
it uses the hard IP?
<azonenberg>
my understanding was everyone just used the GTP/GTX
<azonenberg>
and did all of the pcie protocol in fabric
<azonenberg>
(I'm specifically interested in the hard ip)
emeb_mac has quit [Quit: Leaving.]
<whitequark>
it uses the hard IP
<whitequark>
before i wrote one, there was no open-source PCIe PHY that i am aware of
<azonenberg>
Yeah but does it use it through the xilinx IP wrapper?
<azonenberg>
i see .xci files in there
<azonenberg>
as opposed to the raw primitive
<whitequark>
hm
<whitequark>
i'm not sure
<whitequark>
been a while since i looked
<azonenberg>
There's not a PCIE_2_1 primitive created there
<azonenberg>
in the same way, almost everyone i see using the GTX uses the transceiver wizard
<azonenberg>
rather than raw GTXE2_CHANNEL / GTXE2_COMMON primitives
<azonenberg>
because all of the config settings for them are undocumented
<whitequark>
right
<azonenberg>
I was able to extract the settings needed for 1000base-SX on artix7 so i can at least do that without any xilinx IP blocks
<azonenberg>
But what i'm specifically interested in is exactly how much of the pcie protocol is handled in PCIE_2_1 (or equivalent on other families)
<azonenberg>
and how much is in fabric
<whitequark>
ah
<azonenberg>
And if you just use the xilinx IP you have no visibility into that
<azonenberg>
Whiiich also reminds me, i still need to spend some time REing the vivado ILA and debug hub protocol
<azonenberg>
So i can talk to the ILA primitive from libscopehal
<azonenberg>
i really want to be able to do complex protocol analysis on ILA captures
<azonenberg>
and yes i can use an open ILA, but i want to support the vendor core too so i can work with bitstreams using it
<whitequark>
sure
<azonenberg>
also more importantly, i want to be able to unify ILAs and external scopes
<azonenberg>
i have some preliminary work along this line already but need to do more
<azonenberg>
basically i want to be able to have a single glscopeclient instance showing me on-die RTL debug signals *and* off chip nets
<azonenberg>
*nothing* can do that right now
<whitequark>
right
<whitequark>
synchronized sampling gets tricky
<azonenberg>
That's the thing
<azonenberg>
scopehal doesn't require that
<whitequark>
yes, but you do
<azonenberg>
it allows you to arbitrarily mix sampling rates
<whitequark>
(how else would you make sense of it)
<azonenberg>
You need to *know* the sampling rates, so you can align them on a timeline sensibly
<whitequark>
not synchronized in the sense that they use the same timebase
<azonenberg>
but they can be different
<whitequark>
yes, aligned would be a better word
<whitequark>
aligned sampling
<azonenberg>
i.e. they do not need to be simultaneous
<azonenberg>
as long as the offsets from a single trigger point are known
<azonenberg>
i routinely mix captures from my 10 and 20 Gsps scopes in one glscopeclient session
<azonenberg>
and the LA pod on the 10 Gsps scope samples at 1.25 Gsps
<whitequark>
how do you handle clock drift
<azonenberg>
Right now, with scopes only? by connecting a common refclk to everything
<azonenberg>
this is one of the reasons i want to have a lab-wide refclk generation system based on a GPSDO + PLL
<azonenberg>
so i can supply standard reference frequencies to all of my scopes, the DUT, etc
<whitequark>
hrm
<azonenberg>
my planned system is a 1U appliance with an internal 10 MHz OCXO (for when you only care about relative frequencies, not absolute synchronization to atomic time) as well as back panel ports for GPS PPS + 10 MHz
<azonenberg>
driving a 2.5 GHz PLL VCO which then divides out to each output port
<whitequark>
right, that works
<azonenberg>
with programmable delays on each output, and a deskew reference input, so you can calibrate out cable propagation delay and have simultaneous rising edges +/- 25ps at the end of each cable
<whitequark>
though the utility is limited for people who are not you
<azonenberg>
All of my own scopehal hardware will have refclk + PPS inputs
hitomi2504 has joined ##openfpga
<azonenberg>
So you will be able to get trigger timestamping to +/- a few nanoseconds
<azonenberg>
and you can sync arbitrarily many instruments
<azonenberg>
That said, for a lot of debugging you don't need ultra tight clock sync so having say 25ppm of timebase drift between two waveforms if you only have a few hundred kpoints is not a big deal
<azonenberg>
and if you have an I/O sampled by both the external and internal instruments, it should be possible to calibrate out the clock drift by aligning edges
<azonenberg>
i.e. feed GPS time into the DSO then cal out the offset between the nominal FPGA clock and the actual FPGA clock based on measurements of the same signal in both clock domains
<azonenberg>
I already do something similar as a one-time calibration for trigger skew between instruments: you touch a probe from the primary and secondary instrument to a common point then i find the cross-correlation and adjust the trigger offset on the secondary to cal out the trigger delay
<azonenberg>
this nulls out the propagation delay of the cable between trig out on the primary and ext trig on the secondary
<azonenberg>
and both waveforms will start at the same time +/- a sample or so
<whitequark>
huh
<whitequark>
makes sense
<azonenberg>
you can then move the probes to the actual signal and as long as you don't bend the cable too much or have huge temperature swings etc the cal remains valid
<azonenberg>
it should be possible to do similar for frequency offset between an FPGA and external test equipment, but if the DUT has a SMA clock input the easiest option is just to run the DSO and ILA off of different multiples of the same base reference clock
<azonenberg>
incidentally, it bothers me that my lecroy DSOs rely on NTP to set the timestamp in the waveform header
<azonenberg>
and don't have a 1588 or PPS option for higher precision
<azonenberg>
with my hardware the plan is to use NTP to get an approximate timestamp (+/- 500ms or better is all that's required, so you don't need a great network or stratum 1 server)
<azonenberg>
then PPS off a GPSDO to fine tune the second transition
<azonenberg>
then lock an internal timebase PLL to the GPS 10 MHz and use cycles of that PLL clock to measure micro/nanoseconds since the second
<azonenberg>
This should allow every trigger event to have a timestamp accurate to a few tens of ns
<azonenberg>
or, if you don't need that, you can not hook up the PPS and use NTP time and just accept the drift/offset from that
<azonenberg>
(my clock distribution device will also support PPS pulse distribution with programmable delay to null out cable propagation delay as well, although probably with less resolution than the refclk)
<whitequark>
hm, are you using PPS to get absolute timestamps?
<azonenberg>
that was the intent yes
<whitequark>
that doesn't work
<azonenberg>
possibly with a fabric based soft pll to correct for jitter but i think that's overkill. A few hundred ns or even a us or two should be good enough
<azonenberg>
why?
<whitequark>
PPS has no phase relationship to the start of second
<azonenberg>
wut
<azonenberg>
it's not every second on the second?
<whitequark>
nope
<azonenberg>
what use is it then
<whitequark>
frequency standard, not phase standard
<whitequark>
there is also a "top of second" output on some units, with at best 50-100 ns of jitter
<azonenberg>
My understanding is the 10 MHz output is a frequency standard
<azonenberg>
and PPS is the time standard
<whitequark>
i had the same assumption as you
<whitequark>
it's not actually true in practice
<whitequark>
you can't use off-the-shelf GPS units to do TDOA, which was the purpose I wanted them for
<whitequark>
like at all
<azonenberg>
oh
<azonenberg>
50-100ns error is totally fine for my purposes
<azonenberg>
I just wanted better than ntp basically
<whitequark>
yes, so you should be fine with a top-of-second output on units that have them
<whitequark>
but not PPS
<whitequark>
so you have a much smaller problem than i do
<azonenberg>
also AFAIK higher end ones will output the true delta from edge to the real second in the NMEA
<azonenberg>
So i could potentially apply that correction in my refclk system
<whitequark>
yes, that is true
<azonenberg>
and then have my time standard output a true on-the-second PPS no matter what
<azonenberg>
I'd need some kind of PLL in there for the PPS anyway, because i'd want to be able to null out cable delay
<azonenberg>
which means sending the pulse before the true second
<azonenberg>
and then adjusting phase with a delay line so it arrives at the far end of the cable at the second boundary
<azonenberg>
My thought was to do it in fpga fabric on like a 250 MHz clock with an OSERDES
<azonenberg>
that would give me 1ns resolution which should be more than adequate
<azonenberg>
i.e. fabric based loop that increments count by 4 every cycle and then interpolates the actual edge position via the OSERDES
<azonenberg>
if the loop itself is clocked by a PLL fed by the GPS 10 MHz, it should have no problem with a second of holdover
<azonenberg>
incidentally, you should have been able to use that for better synchronization in your application too
<azonenberg>
the time of the PPS pulse itself doesn't matter for most purposes as long as you know the offset
<azonenberg>
you can always synthesize a delayed pulse if you need it
<azonenberg>
My understanding is that the true reason for the PPS delay is that typically it's generated by a slowish MCU core and is discretized to the clock frequency of that logic
<azonenberg>
and internally it basically does a DDS to corrrect for phase error between MCU clock and GPS L1
<azonenberg>
outputting the fractional error in the NMEA
OmniMancer has joined ##openfpga
Asu has joined ##openfpga
Asuu has joined ##openfpga
Asu has quit [Ping timeout: 258 seconds]
Asuu has quit [Read error: Connection reset by peer]
Asu has joined ##openfpga
_whitelogger has joined ##openfpga
m_w has quit [Ping timeout: 240 seconds]
m_w has joined ##openfpga
m_w has quit [Ping timeout: 260 seconds]
clever has joined ##openfpga
Asu has quit [Read error: Connection reset by peer]
Asu has joined ##openfpga
kiboneu has joined ##openfpga
kiboneu_ has quit [Ping timeout: 258 seconds]
gregdavill has quit [Ping timeout: 260 seconds]
duck25 is now known as duck2
daveshah has joined ##openfpga
daveshah has quit [Remote host closed the connection]
daveshah has joined ##openfpga
cr1901_modern has quit [Quit: Leaving.]
X-Scale` has joined ##openfpga
cr1901_modern has joined ##openfpga
X-Scale has quit [Ping timeout: 246 seconds]
X-Scale` is now known as X-Scale
Bike has joined ##openfpga
genii has joined ##openfpga
cr1901_modern has quit [Ping timeout: 272 seconds]
Miyu has joined ##openfpga
hackkitten has quit [Ping timeout: 246 seconds]
Miyu is now known as hackkitten
cr1901_modern has joined ##openfpga
emeb has joined ##openfpga
hitomi2504 has quit [Quit: Nettalk6 - www.ntalk.de]
m4ssi has joined ##openfpga
_whitelogger has joined ##openfpga
<felix_>
whitequark: not sure if the two thunderbolt controllers are connected over thunderbolt or pcie. my guess would be thunderbolt; if they were only connected via pcie, the second thunderbolt controller wouldn't have signals on its display port outputs
<felix_>
oh and the whole device contains 7 spi nor flash chips and probably 2 microcontrollers with integrated flash
<whitequark>
wtf
OmniMancer has quit [Quit: Leaving.]
<gruetzkopf>
iirc the dell tb16 has two TB controllers chained
<gruetzkopf>
one in the connector, one in the dock
<gruetzkopf>
so the connector has usb-c on one end and pcie + TBT + DP on the other
<gruetzkopf>
(don't have such a dock, only the cable)
<awygle>
based on these knowings would you recommend such a dock, or no?
<whitequark>
who of us?
<awygle>
you, felix_, gruetzkopf, any or all of the above
<gruetzkopf>
i don't have any (working) TB3 hosts
<awygle>
i have an XPS15, it has thunderbolt, i could use a dock, but they're expensive and the reviews aren't very good, so i'm hesitant.
<felix_>
for me it just worked with my xps13 running windows until the asmedia xhci controller sort-of died; now it only works for charging and display output and occasionally caused bluescreens due to access violations
<whitequark>
huh
<whitequark>
i kinda wanted one
<whitequark>
but now maybe not so much
<felix_>
seemed to be the broken xhci controller DMAing things where it shouldn't
<whitequark>
... why the hell does it even need an xhci contrller
<felix_>
ethernet, audio and the type a usb ports are hanging on that one
<whitequark>
agh
<whitequark>
how complicated is that hting exactly
<felix_>
yes ;P
<felix_>
it also has 2 displayport MST hub chips (didn't know that synaptics makes MST hubs; only knew them for making touchpad controllers), a usb3 hub and probably some other thing i didn't identify hen i had a quick look at it yesterday
<whitequark>
why
<felix_>
if someone of you wants to have the half-broken one, i'd ship it if shipping from germany isn't terribly expensive or complicated. it needs a new thermal pad for the thunderbolt chip in the cable; that one disintegrated during disassemly
<whitequark>
too cursed
<felix_>
the two mst hubs are probably to support full bandwidth on each port if the other ones are unused but to also support all ports (not sure if all or only up to 3 ports are supported simultaniously) being used
daveshah has quit [Remote host closed the connection]
daveshah has joined ##openfpga
ktemkin has joined ##openfpga
daveshah_ has joined ##openfpga
daveshah has quit [Remote host closed the connection]