<azonenberg>
the top half of the enclosure isn't designed yet but it will be sandwiched fully. With the insides and lips of the enclosures sprayed with conductive paint to provide shielding around the entire perimeter
<azonenberg>
The LSHM connector at the end will mate with a corresponding connector on the flex PCB. Production version will be flex-rigid but this is easier to do with oshpark's process constraints
<azonenberg>
The barrel jacks will be replaced by the USB-PD power input eventually of course
<azonenberg>
and the U.FLs are just power rail test points
<azonenberg>
so basically that whole area outside the can will eventually go away
<azonenberg>
Now I just have to design the tip PCB. And wait for my first prototype of the hinge mechanism to arrive so i can tweak stiffness
<xzcvczx>
it arrived, the f***ing local agent self signed before delivering it though so i had to go chasing him to work out what was happening
<azonenberg>
xzcvczx: lol lovely. Got it set up yet?
<xzcvczx>
haha i have just got it in the door
<azonenberg>
ah, ok
<azonenberg>
Keep us posted. It should be fairly similar to the 3xxx and 6xxx so shouldn't take you too long to get the basics working
<xzcvczx>
i shall do
elms has joined #scopehal
elms has quit [Changing host]
<xzcvczx>
for picobridge based on my 5min look, it only supports one unit at the same time, looks for 6k if not found goes for 3k, do you think its time to look at adding multi-device support or maybe a way to specify which one you are expecting on the command line? or just go from 6k->5k->3k and accept first one?
_whitelogger has joined #scopehal
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 264 seconds]
Degi_ is now known as Degi
_whitelogger has joined #scopehal
_whitelogger has joined #scopehal
<azonenberg>
xzcvczx: Multi device support is planned but testing it will require someone who's got more than one picoscope. ideally more than one of the same model
<azonenberg>
short term it's going to pick the first available device
<azonenberg>
we'll worry about multi device once we get single working reliably
<azonenberg>
the intent is eventually to specify a serial number or similar on command line if you have >1 available
<azonenberg>
so you can run one bridge instance for each scope
_whitelogger has joined #scopehal
<xzcvczx>
figured that might be the case
<xzcvczx>
i have always hated working out the best way to sort out multiple devices, the worse i saw was usb devices but instead of using unique vids/pids they just reused them and then changed the serial number to ABCDEF123456 for one model compared to the other
<xzcvczx>
the usb serial number
<azonenberg>
lol wow
<azonenberg>
In any case that will only affect the "open device" code
<azonenberg>
everything downstream once we have a handle is the same
<xzcvczx>
yeah sure
<xzcvczx>
the device i was talking about had its own serial number that you could grab when connected it was just annoying having to connect in order to work out if you wanted to connect
Stephie has quit [Ping timeout: 272 seconds]
_whitelogger has joined #scopehal
Stephie has joined #scopehal
_whitelogger has joined #scopehal
<azonenberg>
I think i'm gonna order some M1 screws for this. Everything else is metric so i should use it for the hardware too
<azonenberg>
more importantly, a #4 screw is just huge compared to this board
_whitelogger has joined #scopehal
kbeckmann_ is now known as kbeckmann
<GyrosGeier>
azonenberg, same state as last time: I basically have a package, it needs a bit more testing
<GyrosGeier>
the fun part will be getting ffts stable
<xzcvczx>
i need to look more at ffts and see if all the simd optimisations are optional and its just clang stuffing it up
_whitelogger has joined #scopehal
<GyrosGeier>
they are
<xzcvczx>
dammit clang/gcc please just agree on something
<GyrosGeier>
the difficulty from a packaging perspective is making sure the people who have the hardware get the optimizations, and the others don't crash
<xzcvczx>
i wonder if there are any x86 processors built in the last decade that dont have ss32
<xzcvczx>
sse2 rather
<GyrosGeier>
all amd64 have it
<GyrosGeier>
the new divide is avx and its various subforms
<xzcvczx>
which i dont think "pentium" labelled stuff have even now
<GyrosGeier>
including the one that technically works on 512 bit vectors but if you use a 512 bit multiply instruction, the CPU gets clocked down to half speed
<GyrosGeier>
so if there is to be avx variants, we need to offer that as well because VM hosters get really unhappy if you use these instructions
<xzcvczx>
i do wonder how intel ever thought it would be acceptable
bvernoux has joined #scopehal
<xzcvczx>
azonenberg: do you push all wip branches to github? or is there some stuff you have done which is not on github?
joyce72 has joined #scopehal
joyce72 has quit [Ping timeout: 244 seconds]
bvernoux has quit [Quit: Leaving]
bvernoux has joined #scopehal
bvernoux has quit [Client Quit]
bvernoux has joined #scopehal
<bvernoux>
woo the electronic industry is totally crazy
<bvernoux>
we are not far to have MCU with price of diamond ;)
<bvernoux>
and here it is on LCSC which is often 2 or 3 times cheaper than DigiKey/Mouser on lot of parts ;)
<GenTooMan>
thank the idiots of the auto industry also a "little" fire in a production facility in Japan
<GenTooMan>
don't worry no normal person will ever benefit from the prices being high like that either.
<azonenberg>
GyrosGeier: there's no need to worry about vm support for glscopeclient because it requires opengl 4 which is basically unheard of in hypervisors
<azonenberg>
without pcie passthrough it wont work
<azonenberg>
xzcvczx: i normally develop on master and try to ensure master is always usable
<azonenberg>
GyrosGeier: as far as avx512 goes, it's not half speed. and the FMA is the main thing that downclocks
<azonenberg>
And in my testing the avx512 fma produces a significant speedup on FIR filters
<Kliment>
azonenberg: also misleading error message on startup: "OpenCL support: not present at compile time. GPU acceleration disabled."
<Kliment>
azonenberg: obviously not all GPU acceleration is disabled (or the whole thing wouldn't work), so maybe needs renaming to "GPU compute acceleration" or something
<ericonr>
doesn't opencl mean the acceleration could even come from something other than a GPU?
<azonenberg>
ericonr: as of now i check the device type and only allow GPU
<ericonr>
ah, fair :)
<azonenberg>
since i already have AVX acceleration implemented for CPU stuff which is likely going to be faster than whatever autovectorization a software opencl implementation runs
<azonenberg>
Kliment: you have to specify something for the device path/address
<azonenberg>
any non-empty string works, i usually do "null"
<Kliment>
azonenberg: I'd recommend accepting an empty string for the null and siggen drivers, or prepopulating it in that case
<azonenberg>
Soooo it's harder than that
<azonenberg>
because the dialog just concatenates all of the stuff into a colon delimited argument string just like if you entered it on the command line
<azonenberg>
and that parser chokes if it doesnt get the input it expects
<azonenberg>
it doesnt know what the driver is yet
<azonenberg>
So the downstream code will have to be fixed
<Kliment>
cool, so put in two colons
<Kliment>
for empty string
<azonenberg>
well no, it expects :^s
<azonenberg>
:%s *
<azonenberg>
and dies if that field is missing
<Kliment>
is that in the parser or the driver?
<azonenberg>
It's an easy fix, i've just been busy with other stuff
<Kliment>
azonenberg: sounds like a nice starter bug for me :)
<azonenberg>
I believe it's in the ScopeApp class? but it's been a little while since i touched that code
<Kliment>
I'm going to make the string "null" if it's empty for the null driver
<Kliment>
for the null transport I mean
<azonenberg>
Ok
<azonenberg>
Or just make the parser accept an empty string
<azonenberg>
that would work too
<Kliment>
siggen driver crashes
<Kliment>
segfault with ERROR: IBIS file "/nfs4/share/datasheets/Xilinx/7_series/kintex-7/kintex7.ibs" could not be opened
<Kliment>
but my null insertion hack works
<azonenberg>
Kliment: the siggen driver is a very minimal hack that i havent used in ages
<azonenberg>
that parses an ibis file and replays a waveform
<azonenberg>
that's a hard coded path on my *old* NAS
<azonenberg>
doesnt even resolve since i upgraded to ceph, which gives you an idea of how old that code is :p
<azonenberg>
At some point i want to make a proper ibis signal generator
<azonenberg>
but there's a lot of work to do
<Kliment>
azonenberg: okay, should I drop it from the list?
<azonenberg>
Hmmmm
<azonenberg>
Yeah how about you hide it from the dialog for now. it'll still be reachable via command line for testing until we get it working
<Kliment>
yep
<azonenberg>
perfect example of the kind of rough edges i want to polish off before v0.1
<azonenberg>
i actually forgot all about that because i never use the dialog
<azonenberg>
i always launch on the command line
<azonenberg>
On that note we have a bunch of issues around that if you want to work on them
<azonenberg>
things like being able to launch the connection dialog from a menu
<azonenberg>
to open a new session once glscopeclient is active
<Kliment>
Okay, no easy way to filter something off the list
<Kliment>
except in the UI itself
<azonenberg>
Correct. Because if you unregister it, you can't create it via CLI
<azonenberg>
Just add a little bit of glue in the dialog
<azonenberg>
Just call OscilloscopeWindow::CloseSession() to clean up whatever is currently active then initialize like a new session
<azonenberg>
this is mostly just going to be gui glue to launch the dialog from a menu handler
<azonenberg>
You can probably move most of the current code for launching the dialog into OscilloscopeWindow from ScopeApp and then have everything happen in that function
<Kliment>
azonenberg: got a call now, will poke later
<GyrosGeier>
azonenberg, most OpenCL implementations scalarize the actual function, and then vectorize across the working set
<GyrosGeier>
so any operation on 32 bit values can be run on avx512 as long as the NDrange has a value > 16 in the "least significant" dimension (i.e. the one where values are consecutive in buffers)
<azonenberg>
My point was more that i'd expect my hand optimized code that unrolls/interleaves to compensate for instruction latency on target CPUs to be better than autovectorized coe
<azonenberg>
code*
<azonenberg>
Especially in the case of complex stuff like the eye pattern where part of it is serial and part is parallel
someone--else has joined #scopehal
<someone--else>
is there a correct/canonical way to get raster waveforms (persistence/eye diagram/etc.) from hardware into the glscopeclient directly instead of re-computing them from vector waveforms in glscopeclient?
<someone--else>
asking since I have hardware which generates those natively with no easy way to extract vector waveforms from all possible captured signals (for example, from multi-valued signals like eye diagrams)
<azonenberg>
someone--else: sampling scope?
<azonenberg>
and the tl;dr is that the architecture (mostly) allows this, however we've never actually *done* it
<azonenberg>
you'd create an oscilloscope driver where the channel is of type CHANNEL_TYPE_EYE and has an EyeWaveform associated with it
<azonenberg>
We might have to patch some bits of the GUI that assume an EyeWaveform is always generated by the EyePattern protocol decode, as so far that's always been true
<azonenberg>
Also, there is currently no support for serializing eye waveforms to disk because so far they're always procedurally generated
<someone--else>
it's a comparator-based sampling scope, yes
<someone--else>
great to know, thanks
<someone--else>
i'm just starting the driver development, so can't test this yet
<someone--else>
so I suppose updates about this will come in a few weeks
<someone--else>
are there any restrictions on eye diagram size apart from memory consumption?
<someone--else>
hardware can generate arbitrarily long waveforms, e.g. 4096x1048576 or more
<someone--else>
could be useful when sampling long prbs patterns
<azonenberg>
The eye pattern filter uses a pixel resolution exactly equal to the viewport size
<azonenberg>
and will adjust the pixels per unit time to make it work
<azonenberg>
there's currently no support for scrolling them
<azonenberg>
We could add that in the future i guess?
<azonenberg>
All of the sampling scope stuff i've done so far has used clock recovery or similar triggering so that the recovered waveform was modulo the UI
<someone--else>
I'll report when I test how this works then
<azonenberg>
I'm definitely open to refactoring and cleanup to make this kind of use case work better
<azonenberg>
I'd like to support the Pico sampling scopes eventually too
<someone--else>
modulo the UI makes sense for most applications, however sometimes a longer waveform might make sense
<azonenberg>
Yeah. I think you might end up having two different types of waveform data structure for that
<azonenberg>
the existing EyeWaveform modulo the UI
<azonenberg>
and something new for arbitrarily long persistence maps
<someone--else>
like capturing entire prbs sequence for later analysis or a long TDR trace
<azonenberg>
Yeah i totally understand what you're going for
<azonenberg>
I think it could share some code with EyeWaveform, maybe refactor some stuff into a common base class
<azonenberg>
but really i think it's going to end up being two different things
<azonenberg>
eye patterns are treated quite specially in the GUI
<azonenberg>
e.g. not allowing you to scroll or zoom
<someone--else>
makes sense
<azonenberg>
and rendeirng at 1:1 pixel resolution
<azonenberg>
whereas for a sampling scope you have fixed hardware resolution
<azonenberg>
and you'd just render that as a texture mapped polygon in the GUI
<azonenberg>
Speaking of which, OpenGL probably will not like a 1M point wide texture
<azonenberg>
so even if the internal representation is arbitrarily large we will probably want to either resample it in a compute shader, or chunk it into multiple smaller textures of reasonable size for rendering
<azonenberg>
It might also be interesting to add a "extract most probable value" or similar filter
<someone--else>
resampling in horizontal direction should be easy enough computationally and doable on CPU even
<azonenberg>
I'd rather do it on the GPU to keep it fast for interactive display
<azonenberg>
4096 x 1048576 is 4GB of waveform data
<azonenberg>
that's a lot to do on the CPU even with vectorization
<azonenberg>
But we'll worry about that when we get there
<azonenberg>
Anyway, given a sampled waveform of say a TDR trace or PRBS (not modulo the UI, so it has to be approximately a function in the strict sense - so a distribution centered at one value per X coordinate)
<azonenberg>
find the peak of that probability density function for each timestamp
<azonenberg>
and output a vector waveform
<azonenberg>
Which we can then feed into, say, a protocol decode or filter to measure the rise time, etc
<azonenberg>
It wouldnt be hard and i think it would be convenient because while persistence maps are nice for display they're hard to do analysis on
<someone--else>
or, perhaps, setting a window of interest in hardware and acquiring only the data corresponding to the current UI viewport might be a solution since data acquisition is pretty fast
<someone--else>
yep, having both waveform types simultaneously would help
<azonenberg>
And yes, setting a ROI in hardware is an option. Depends on how fast your scope is, FREESAMPLE was going to be quite slow (many minutes per acquisition)
<someone--else>
test waveform display software I written before actually did that
<azonenberg>
but in general glscopeclient decouples the timebase in hardware from the display
<azonenberg>
so you can freely pan and zoom without changing the hardware acquisition settings
<someone--else>
it's something like 100ksps
<azonenberg>
so if we have a hardware ROI it would be set under timebase properties
<azonenberg>
Yeah but is that 100K voltage values or 100K boolean samples?
<azonenberg>
FREESAMPLE was a comparator based architecture that directly measured the CDF of the waveform
<azonenberg>
so for each (x,y) value it had to record several thousand boolean values to approximate the probability of signal(x) < y
<azonenberg>
so for a, say, 720p resolution eye you're doing 1280 * 720 * 1000 samples
<someone--else>
100k voltage values, there is some averaging after that, but display can be updated after each full frame acquisition with continuous averaging
<azonenberg>
Which at 100 ksps per boolean sample is 2.56 hours of acquisition
<azonenberg>
So do you have a S&H and ADC then?
<someone--else>
nope
<azonenberg>
not a comparator?
<azonenberg>
how are you getting it that fast?
<azonenberg>
100k voltage values at 10 bit resolution is 100Msps raw sample rate
<someone--else>
500 msps booleans ~ 100 ksps voltages @ 12bit if my math is correct
<azonenberg>
ah, ok so you are getting much higher boolean sample rates
<azonenberg>
that makes more sense
<azonenberg>
What about the time to shift the sampling aperture or the dac threshold?
<azonenberg>
that might dominate sampling time depending on how fast the update rate is and how many samples you acquire per pixel
<azonenberg>
In the case of FREESAMPLE my plan was to acquire as many samples as i could, rapidly, of a single pixel
<someone--else>
well sampling is time-first dac threshold-second, so dac updates are much slower
<azonenberg>
then sweep the time delay (fairly fast)
<azonenberg>
and slweep the dac last
<azonenberg>
yeah
<azonenberg>
Will your scope have a clock recovery trigger?
<someone--else>
external perhaps
<someone--else>
but not built-in
<azonenberg>
FREESAMPLE's architecture used a splitter with half the signal going into the sampling comparator and half into the trigger/clock recovery circuit
<azonenberg>
which included a fixed level trigger and a TI TLK10232 SERDES
<azonenberg>
the plan was to use the recovered parallel clock from the TLK10232 and multiply it back up with a LMK04806
<azonenberg>
use the 25ps phase steps on that then a HMC856 3ps delay line to get finer resolution
<someone--else>
yeah, I though about that but there's no good cheap solution for universal rate clock recovery
<azonenberg>
I allowed both a DLL style delay line route from an edge trigger
<azonenberg>
and PLL trigger off the TLK10232
<azonenberg>
i think it would have worked well
<someone--else>
for diy kind of uses a $100 eBay YIG filter is the best, I think
<azonenberg>
the 232 isnt expensive
<azonenberg>
I got most of the way through the design then realized a fast scope was useless without high bandwidth probes, which i didn't have
<azonenberg>
then rabbitholed hard on probe design and now here i am :p
<someone--else>
TLK10232 looks good if it can output the recovered clock, thank for the ip
<someone--else>
tip
<azonenberg>
Check out azonenberg/freesample on github
<azonenberg>
the design is incomplete but there should be enough there to give you some good ideas
<azonenberg>
i think the schematic is done and the layout is maybe 2/3 done?
<someone--else>
I think I've seen that some time ago
<someone--else>
my hw is pretty much production-ready
<someone--else>
so any updates/additions will be for later
<azonenberg>
Makes sense
<someone--else>
well I mean it could continue indefinitely, but I've been doing if on and off for a few years now, time to release it
<azonenberg>
well, i'm definitely interested. My intent has been for glscopeclient and libscopehal to become the de facto standard for this kind of stuff, like how every sdr made these days has gnuradio out of the box as the primary API
<someone--else>
I'll send you one when the driver is ready if you want
<azonenberg>
Definitely interested
<someone--else>
bandwidth is 10g-ish
<azonenberg>
Awesome
<someone--else>
built-in tdr
<azonenberg>
Yeah thats what i was targeting for freesample. No TDR built in though
<azonenberg>
I mostly wanted it for signal integrity work
<azonenberg>
so multi-gigabit eye patterns
<someone--else>
sure
<someone--else>
I found tdr useful for testing PCBs
<someone--else>
so far the resolution on fr4 is 2-3mm
<azonenberg>
please be ethernet
<someone--else>
usb3
<azonenberg>
aww :p no remote operation
<azonenberg>
at least without a bridge server
<azonenberg>
but that's on the wishlist
<someone--else>
but should work with usb3 AOCs in usb3 mode
<azonenberg>
I want to be able to have a standard protocol for marshalling the libscopehal api over sockets
<azonenberg>
so you can take a locally attached instrument and provide network transparency
<someone--else>
would be neat
<someone--else>
in fact I planned a similar feature for my own scope software when I still wanted to write one
<azonenberg>
I already have that in libjtaghal and it's a core feature i use all the time
<azonenberg>
to e.g. access a ftdi dongle remotely
<someone--else>
i.e. internet-connected real scopes as demo units for people who want to try
<azonenberg>
Yeah that would be cool too but my main application is LAN
<azonenberg>
I have 10G and 40G ethernet all over the building
<azonenberg>
Being able to sit down at my desk in the office and stream waveform data from the lab is super convenient when coding on firmware and debugging remotely
<azonenberg>
sure you can run it over vpn/internet too
<someone--else>
convenient
<azonenberg>
but mostly it's the "be anywhere in the building and get the same performance as if you were sitting in front of the scope" part i like
<azonenberg>
all of my own scope projects under development will have 10G or 40G ethernet
<someone--else>
the sampling scope is very portable though and usb-powered, so might be easier to just take it with you
<azonenberg>
as well as a 1G RJ45 for people who don't have a mile of fiber in their house :p
<azonenberg>
Yeah most of the stuff i'm designing will be 1U rack mount form factor
<azonenberg>
it's meant for a more permanent lab deployment
<someone--else>
1000base-t version should be doable if there's any interest (not sure how many people want a sampling scope); usb3 was just the cheapest/easiest way
<someone--else>
(or maybe sfp, don't know)
<someone--else>
though I might add ip-based streaming to the scopehal driver anyway since it will be easy enough
<someone--else>
i.e. just sending usb packets to the driver and doing the parsing there
<someone--else>
sounds easier than general driver remoting protocol
<monochroma>
SFP cages are cheap, and easy to route to spare IO on an FPGA, and then you can easily support 1000Base-T / Optical SFP modules
<someone--else>
sure
<azonenberg>
someone--else: well my plan was to have the general remoting protocol work with everything
<azonenberg>
even like usb-gpib dongles etc
<azonenberg>
But instruments with native ethernet are definitely preferable if possible
<someone--else>
my fpga is too cheap to have a serdes though..
<someone--else>
sure, general remoting would be great; I was thinking about a stop-gap solution for this particular scope which is easy to implement
<GyrosGeier>
gigabit can be done with external PHY with GMII/RGMII
<GyrosGeier>
that doesn't require transceivers
<someone--else>
sure, but it's kinda complicated, so I'm saving it for a future revision/product
<someone--else>
also, this scope is so smol rj-45 doesn't fit there
Degi_ has joined #scopehal
Degi has quit [*.net *.split]
Degi_ is now known as Degi
Bird|ghosted has quit [Read error: Connection reset by peer]
Bird|ghosted has joined #scopehal
Ekho has quit [Ping timeout: 272 seconds]
vup has quit [Ping timeout: 272 seconds]
someone--else has quit [Ping timeout: 244 seconds]
someone--else has joined #scopehal
kbeckmann has quit [Ping timeout: 272 seconds]
Ekho has joined #scopehal
vup has joined #scopehal
asy has quit [Ping timeout: 272 seconds]
asy has joined #scopehal
kbeckmann has joined #scopehal
<someone--else>
@azonenberg re: TLK10232 - is there any data on its pll bandwidth? datasheet only has low/med/high/ultra high but no si units
<someone--else>
wonder if it will work with ssc protocols like pcie or usb3
<azonenberg>
someone--else: No data to my knowledge. It's mostly intended for 10g ethernet
<azonenberg>
which is not spread spectrum
<azonenberg>
It would not surprise me if it had trouble tracking a spread spectrum glock
<azonenberg>
clock
<someone--else>
spread spectrum glock lol
<someone--else>
I wonder if pll bandwidth can be somehow computed from jitter tolerance..
<GyrosGeier>
my current "fun" project is finding out if I can somehow cascade a DDR3 interface PLL off the PHY PLL on a CycloneV
bvernoux has quit [Quit: Leaving]
<GyrosGeier>
it's silly enough that I seem need a HCSL clock splitter externally to feed all six PHYs
<azonenberg>
GyrosGeier: it's all about minimizing jitter
<azonenberg>
Depending on amplitude you might be able to get away with a passive splitter
<GyrosGeier>
the refclk inputs seem to support HCSL only
<GyrosGeier>
I'm not sure how well that splits passively
<GyrosGeier>
the fPLLs can cascade only from an output divider to the next PLL -- but output dividers seem to have a lot of issues
<GyrosGeier>
and I can't cascade from the PHYs to the normal fabric except through a GCLK
<GyrosGeier>
so I'm running out of GCLKs if I try that
<GyrosGeier>
so the plan right now is to feed the 500 MHz PHY reference twice from the left side, and another 100 MHz clock from the top, bottom and right
<GyrosGeier>
top and bottom are running at 1.35V and the right at 3.3V, so I can split the clock signal with an active splitter twice (because 6.6V oscillators are going to be seldom), and one of the branches passively again
<GyrosGeier>
I already have passive splitters for the GMII RX clock, because I am very low on 3.3V clock inputs
<GyrosGeier>
anyway, that will have to wait for next weekend, work starts again tomorrow
<Degi>
Hmh, does the PCIe clock even need SSC? Like even if it barely tracked it, it should still be fine since some clock deviation is allowed with SKP insertion/deletion
<azonenberg>
I think it's more that the motherboard provides the spread spectrum deviation
<azonenberg>
the card isnt supposed to SSC unless the mobo gives it a spread spectrum clock to work with
<someone--else>
as I understand it, it's mostly for EMC
<someone--else>
pcie is cool in that there's separate 100mhz refclk, which can be used to lock a sampler to
<someone--else>
no such luck with usb3
<azonenberg>
Correct, SSC is just for EMC
<azonenberg>
And yeah unfortunatley nobody seems to sell standalone CDR PLLs
<azonenberg>
abusing the TLK10232 was the best idea i came up with so far
<someone--else>
btw I think I found another way - prescaling the data, say 16x, and then using a slower CDR chip like ADN281x
<someone--else>
any thoughts on why this won't work?
<azonenberg>
what do you mean prescaling the data?
<someone--else>
by prescaling I mean dividing using a static divider
<azonenberg>
Dividing it using a T flipflop or something?
<azonenberg>
Hmm
<someone--else>
yep
<azonenberg>
I think the big issue would be adding jitter
<azonenberg>
also even just getting FFs that run at several GHz is nontrivial
<azonenberg>
They exist, but they're hard to find and expensive
<someone--else>
nb7v33
<someone--else>
but since it's a dc-balanced data stream, even a dynamic rf prescaler should likely work
<someone--else>
like
<someone--else>
HMC434 or something
<someone--else>
don't think such a scheme would add more than a couple of ps rms of jitter
<someone--else>
which seem acceptable to me
<Degi>
Hm, why not use the SERDES of an FPGA? Is probably cheaper than all these chips
<Degi>
(At least per channel)
<azonenberg>
Degi: so the issue is, an fpga serdes can't output the recovered clock directly
<azonenberg>
and fpga clock trees are known for having a lot of jitter
<azonenberg>
with a dedicated serdes chip you skip all of that programmable routing fabric
<Degi>
Ah, the datastream clock at a few GHz? Yeah thats a bit of a problem
<azonenberg>
Well it's a divided clock
<azonenberg>
but still, jitter on there directly translates to measurement error
<azonenberg>
unless you run it through another PLL to clean it up
<Degi>
Hm, I think the ECP5 can output it if I'm not mistaken... At least a clock derived from it, might have high jitter
<azonenberg>
Yeah any fpga serdes can output a recovered clock *to fabric*
<azonenberg>
the point is to output a recovered clock directly to a pin without going through any FPGA
<azonenberg>
If your recovered clock has 100ps of jitter on it, it's useless
<Degi>
Hm, could route it through clock tree?
<Degi>
Does the fabric have that high jitter?
<azonenberg>
FPGA clock tree jitter is still massive
<azonenberg>
normal fabric is even worse
<Degi>
Huh
<Degi>
I mean 100 ps sounds like a lot...
<someone--else>
it might work if fpga is not doing anything else though..
<someone--else>
since there will likely be less noise around the fabric this way
<Degi>
Hmm, is it like deterministic jitter dependent on supply rails etc.?
<azonenberg>
I dont know all of the details. I just know that the static timing analyzers list huge uncertainty for clock jitter
<azonenberg>
The point is, a sampling scope targeting many GHz of bandwidth needs a clock that's stable to fractions of a ps
<azonenberg>
Even with a good CDR PLL you will probably still want a second PLL to clean it up
<Degi>
Hmm, does it need to be clocked off of the data stream? Why not the comparator + delay line approach?
<azonenberg>
Delay lines jitter too. especially large ones
<azonenberg>
With FREESAMPLE the design allowed for you to either have a single large delay line that gave you 70 Gsps equivalent sample rate
<azonenberg>
or a PLL (fed by either a CDR or an external reference clock through a mux) with a variable phase delay and a small delay line
<azonenberg>
that gave you something like 1 Tsps
<Degi>
Ah yes
<Degi>
Hm, the 70 Gsps was jitter limited?
<Degi>
Could you reduce jitter by averaging across multiple acquisitions?
<azonenberg>
It wasn't just jitter, it was the fact that i couldn't use a fine phase shifter
<Degi>
Couldn't you put the small and big delay line in series?
<azonenberg>
because in that model you're not locking a PLL to the data
<azonenberg>
In theory you could, but that would add more jitter. and I think the 70 Gsps was also partially jitter limited
<azonenberg>
and no, you can't reduce jitter by averaging
<azonenberg>
you're collecting a persistence map
<azonenberg>
jitter provides a horizontal smearing of the plot
<Degi>
Hm right
<azonenberg>
sure, you can fit a curve and find the maximum and call that the nominal shape
<Degi>
Ah yes, it'd just make the eye opening look worse
<azonenberg>
but usually the point of this kind of measurement is to measure jitter in the actual signal
<azonenberg>
And instrument jitter can't be separated from that
<someone--else>
well, ADN281x still wouldn't work for usb3 since it's frequency tolerance (1000ppm) is outside usb3 SSC amplitude (5000ppm)
<sorear>
half formed thought: is it possible to connect two sampling devices to the same input and extract the correlated part of the measured signal
<someone--else>
so, apparently the only remaining solution apart from actual usb3 transceiver are filters, fixed or tunable (YIG)
<someone--else>
@sorear what clocks should these samplers have?
<sorear>
they're CDRs, they don't have a clock input
<sorear>
related, probably more tractable, idea: add a variable jitter element to the sampling scope, measure with different amounts of instrumental jitter, and extrapolate eye parameters to zero instrumental jitter
<someone--else>
@sorear ah, I understand now - I think that's how jitter/phase noise analyzers work
<someone--else>
since they have to measure phase noise quite a bit below what the best available reference oscillators have