<_whitenotifier-c>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/Jf8xe
<_whitenotifier-c>
[scopehal-apps] azonenberg bf6cdaf - Hide inactive measurement/stats views when loading a save file. Fixes #94.
<_whitenotifier-c>
[scopehal-apps] azonenberg closed issue #94: Hide statistics when loading a save file that doesn't have them enabled - https://git.io/JfljP
<azonenberg>
monochroma: sooo right now most of my decodes have been link layer protocols like SPI and I2C etc
<azonenberg>
if i want to start adding application layer decodes, say a specific SPI device
<azonenberg>
How would you categorize those?
<monochroma>
layer2 protocols
<azonenberg>
Right now my filters are categorized into analysis (soon to be renamed "signal integrity"), clocking, conversion, math, measurement, memory, misc, and serial
<azonenberg>
fft and waterfall are currently under math but will probably be moved to a "frequency domain" category soon
<azonenberg>
and "layer 2" sounds wrong, because i would consider e.g. I2C to be a link layer protocol
<azonenberg>
since it handles addressing of directly attached devices
<azonenberg>
monochroma: one thought i had was to split them up by functionality
<azonenberg>
for example 24c eeprom and spi flash would be under "memory" just like ddr3 command bus
<monochroma>
yeah, this becomes a bit messy when you think about each protocol's specifics. i think ultimately what a user is going to do is setup a "bus" analyzer for I2C/SPI/Ethernet/HDMI/DDR/whatever off the wire, giving you the raw data that was on the wire. so maybe a distinction of "Electrical Protocols" and "Data Protocols"
<monochroma>
so I2C, the different SPI modes, the different Ethernet phy standards would live under like... "Electrical Protocols" and then have a "Data Protocols" category that then has sub categories for functionaly
<azonenberg>
So lecroy solves this problem, for the most part, by not doing any upper layer decodes at all
<azonenberg>
and cramming literally everything else under "serial data" :p
<monochroma>
gross :D
<monochroma>
i mean, makes sense there
<azonenberg>
I want to have more hierarchies to avoid excessively cluttered menus
<monochroma>
yeah
<azonenberg>
i may eventually have, for example, a category for "video"
<azonenberg>
for vga, tmds, hdmi, displayport, etc
<azonenberg>
lecroy is trying to be touchscreen friendly. I'm not
<azonenberg>
so multilevel menus arent a problem
<azonenberg>
i dont want it excessively complex, but when you have huge numbers of filters you have to have some level of hierarchy
<monochroma>
yeah
<azonenberg>
I think sorting by functionality makes sense
<azonenberg>
there will be a few categories for "primitive" things like CDR PLLs, FFTs, basic math
<azonenberg>
one for serial *buses*
<azonenberg>
e.g. i2c, spi, jtag
<azonenberg>
then higher level categories like memory and RF
<azonenberg>
actually what about having a category for "buses" that includes "parallel data bus" as well as serial stuff?
<azonenberg>
lain, Error_404, degi: anybody else have thoughts on this?
<lain>
yeah I think makes sense to have buses like that
<lain>
and things by functionality
<monochroma>
yeah, so you could have like: "Decoders Electrical" and "Decoders Data" as the two roots of the decoder heiarchy (with an Electrical decoder expected to be the base for a chain to a Data decoder), and then under Electrical you have categories for purpose, so under say, a video category you would have like TMDS(DVI/HDMI), SDI(SMPTE), etc
<azonenberg>
monochroma: see my thought was to have top level categories "buses", "video", "networking", "PC", etc
<azonenberg>
where PC = usb, pcie, etc
<monochroma>
what would you do to seperate the electrical and data decoders?
<azonenberg>
"buses" would be a top level category for things like i2c, spi, jtag
<azonenberg>
but e.g. tmds and dvi would be both under "video"
<azonenberg>
let me list everything i have right now and throw up a google doc or something so we can think about ideas
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<azonenberg>
ok i updated it with what i have so far
<azonenberg>
Now i'm gonna start reorganizing stuff to how i think makes sense
<monochroma>
so where do you see something like 8b10b living since it gets used by a lot of different things
<azonenberg>
That's a good question. Maybe keep it under "serial" or rename to "line codes" and put manchester etc there too?
<monochroma>
that's kinda why i was thinking of splitting it up between electrical layer and data layer since there is a pretty clean split there
<azonenberg>
yeah but then you still need further categories
<azonenberg>
and some things like TMDS for example just make sense to be with their respective protocols
<lain>
at some point you need a way to search
<monochroma>
yeah, when we get to dozens of decoders, the menu system is not going to scale well
<azonenberg>
that was why i was thinking of a multilevel hierarchy potentially
<azonenberg>
e.g. measurements could clearly have horz/vert submenus
<lain>
even with a hierarchy I think search becomes faster for most things
<lain>
I mean, I think you need both
<azonenberg>
yeah we can add some kind of decode search separately
<azonenberg>
i'm thinking about the hierarchical view right now
<lain>
you could have a hotkey to bring up a searchable list of things applicable to whatever you were mousing over for example
<azonenberg>
So thats another thing i need to figure out
<azonenberg>
right now, i gray/ungray filters in the context menu based on if the channel you right clicked on fits input 0 of the filter
<azonenberg>
but eventually i want to check if it fits *any* input
<azonenberg>
potentially with "type casting" filters like thresholding inferred
<_whitenotifier-c>
[scopehal] azonenberg opened issue #112: Add Manchester line code filter - https://git.io/Jf8pB
<_whitenotifier-c>
[scopehal] azonenberg labeled issue #112: Add Manchester line code filter - https://git.io/Jf8pB
<monochroma>
hmmm, so personally the way you have it layd out in the google doc feels messy to me, feels like a bunch of loosely related things dumped in the root, and does not feel very intuitive
<azonenberg>
i just dont see how having buses and other stuff as top level categories would help
<monochroma>
yeah, unfortunately this comes down to personal brain wiring for how we mentally search and categorize things
<azonenberg>
also when you have things like ethernet phy that span multiple layers
<azonenberg>
since i'm not going to put MLT3 as a separate decoder as basically nothing else uses it
<azonenberg>
although 10baseT may end up having the manchester refactored out soon
<bvernoux>
it is a FPGA mining hardware board (Artix7 XC7A200T) with 8Gb RAM ;)
<bvernoux>
can be found on Ebay new for less than 80USD ;)
<bvernoux>
If you check just the Artix7 XC7A200T on DigiKey the price for that FPGA is 193USD ;)
<bvernoux>
name on Ebay is SQRL Acorn FPGA Crypto Miner CLE-215+
<azonenberg>
interesting. has anybody RE'd the pinout etc? what connectivity does it have?
<azonenberg>
are these retired ethereum miners or something? i thought everyone was using gpus for that
<azonenberg>
would make sense why they're being dumped cheap on ebay
<bvernoux>
yes
<bvernoux>
check the link
<bvernoux>
Enjoy Digital has reversed it ;)
<bvernoux>
Productive morning repurposing an affordable ~70€ FPGA mining hardware board (Artix7 XC7A200T) in a LiteX SoC with PCIe Gen2 X4 (MMAP + 2 x DMA TX+RX), 4 Cores VexRiscv SMP CPU and 512MB DDR3, interesting projects coming :) https://github.com/litex-hub/lite
<bvernoux>
512MB is just because it was configured like that as the crypto key have 8Gbits so 1GBytes RAM ;)
<bvernoux>
so clearly a big deal
<azonenberg>
yeah if all you want is fpga and ram and dont need any kind of io
<azonenberg>
except pcie i guess
<bvernoux>
yes ...
<bvernoux>
it is why it is a bit special
<bvernoux>
a beast to be connected on a PC over PCIE ...
<azonenberg>
i cant remember the last time i did an fpga board without ethernet :p
<bvernoux>
or need to design a main board ...
<bvernoux>
yes base board is basic
<bvernoux>
also IO are very limited
<bvernoux>
until you desolder the XC7A200T and transplant it on a real board ;)
<bvernoux>
but that lot of work ...
<bvernoux>
some guy has found it for 25 Euros ;)
<bvernoux>
woo Keysight Introduces 8 Channel Mixed Signal Oscilloscopes for 2 to 6 GHz Signals
<bvernoux>
They do not say it is affordable ;)
<bvernoux>
I suspect something like 80KUSD basic version ;)
<azonenberg>
this is their competitor to the lecroy hdo8108a?
<azonenberg>
except higher bandwidth
<bvernoux>
yes maybe
<azonenberg>
lecroy's 8 channel scopes seem to max out at 2 GHz for the waverunner 8000hd series
<bvernoux>
yes there the go up to 6GHz
<azonenberg>
then they drop back to 4 channels for the 8 GHz WavePro HD and 30 GHz WaveMaster/SDA/DDA series
<azonenberg>
and then the 100 GHz LabMaster series is a scalable system that can go up to 80 channels but obviously multiple units filling most of a rack at that size
<bvernoux>
Yes they shall sell less than 10 units per year ;)
<bvernoux>
for the 100GHz version ;)
<bvernoux>
what is crazy is the price for a good Scope 8bits with 2GHz BW is always crazy expensive
<bvernoux>
Only Rigol lower the price
<bvernoux>
Rigol/Siglent ...
<bvernoux>
It is like nothing has changed in 20years
<bvernoux>
Scope have even better performance but 2GHz BW is same price as 10 or 20 years ago ;)
<azonenberg>
lol the waverunner 8000hd series starts at $28300 - for the 350 MHz version
<azonenberg>
i can only imagine what the 2 GHz version costs
<azonenberg>
meanwhile the wavepro hd is only 4 channels but starts at $31900 for 2.5 GHz
<azonenberg>
(but that's 12 bits)
<bvernoux>
yes it is crazy
<bvernoux>
even for 12 bits 350MHz BW in 2020
<bvernoux>
that shall cost 2830USD ;)
<bvernoux>
I understand there is amazing R&D cost ...
Pretzel4Ever has joined #scopehal
<azonenberg>
degi, electronic_eel: so Pretzel4Ever is working on a project that might be relevant to some of what we've been doing
<azonenberg>
He needs to sniff an LPDDR1 memory device in system. My tentative thought is that the best option is to make a passive interposer with 10:1 transmission line probes built into it, then ribbon cables going out to an active buffer board
<azonenberg>
which would be essentially the CONWAY front end, possibly simplified a bit since it doesn't need wide input range or quite as much ESD protection as a general purpose LA frontend
<azonenberg>
and then just parallel LVDS lanes from that board to a host FPGA system
<azonenberg>
LPDDR1 is slow enough it should be possible to use IDDRs or ISERDESE2's to digitize, no need for GTP/GTX
<azonenberg>
They already wasted a bunch of money on fancy Keysight accessories that, judging by the look of them, will do more harm than good
<azonenberg>
they dont seem to have any active buffering or even proper damping resistors, i think they expect you to use $$$$ active analog probes for every signal
<azonenberg>
Which is obviously not happening
<azonenberg>
and the unterminated stub length looks quite long too
<azonenberg>
lain: any thoughts on this?
<azonenberg>
Pretzel4Ever: oh, you know who else you might want to reach out to who was interested in memory sniffing? i dont know how much work he actually did on the subject
<azonenberg>
but sergei skorobogatov over at cambridge university
<azonenberg>
after visiting your group i actually flew by cambridge to visit with him and had some productive discussions and ram sniffing came up during the conversation
<electronic_eel>
do you have any links to the stuff Pretzel4Ever has done/plans to do?
<azonenberg>
electronic_eel: all they have so far is a DUT instrumented with a keysight interposer that looks like it could be improved upon
<azonenberg>
He's trying to figure out how to pull that data onto an FPGA for realtime bus analytics
<azonenberg>
i.e. not capturing and then doign offline display on a $$$$ LA
<electronic_eel>
azonenberg: you wrote "10:1 transmission line probes" ... "which would be essentially the CONWAY front end" - hmm, not sure if that will work well, because on CONWAY you also want to be able to sample I2C and other higher impedance stuff
<azonenberg>
he wants to be able to do very low latency analysis and possibly even vary stimuli to the DUT based on dram bus traffic
<azonenberg>
electronic_eel: i'm thinking the same comparator and analysis side
<azonenberg>
but with a 50 ohm input
<Pretzel4Ever>
Ah, is not that the guy who did that Chinese chip backdoor detection via Pipeline emission analysis?
<azonenberg>
just change the termination a bit
<azonenberg>
Pretzel4Ever: sounds right
<azonenberg>
although i dont think it was of chinese origin
<azonenberg>
it was a manufacturing test feature left in there by microsemi
<electronic_eel>
yes, the same comparator, fpga link and sampling configuration could be used
<Pretzel4Ever>
At the time there the media was talking about it as Chinese backdoor as far as I remember (sometime around 2010-2011)
<azonenberg>
electronic_eel: yeah that's what i'm talking about. I think there's room for lots of shared resources
<electronic_eel>
DDR1 uses single ended lines, right?
<azonenberg>
Yes it's single ended SSTL, they might have differential DQS but for this i think you could get away with just oversampling the positive side
<Pretzel4Ever>
I have to mention, it is a LPDDR1
<electronic_eel>
is LPDDR1 different in this regard? do they have lots of differential lines?
<azonenberg>
electronic_eel: it looks like just 1.8V SSTL
<electronic_eel>
yeah, been looking at it too and it looks like just the clock is diff
<azonenberg>
Yeah. So basically feed clk+ and clk- into a comparator directly
<electronic_eel>
hmm, would it make sense to have 2 different versions of CONWAY available, one with grabbers and high impedance, one with sma/mmcx for transmission line probes?
<azonenberg>
then all of the other signals into a comparator against a DAC-generated reference voltage, nominally vcc/20 if you use 10:1 probes
<azonenberg>
Yes, that was my thought actually
<electronic_eel>
since you plug it into the scope, you could just plug in the different versions as needed
<azonenberg>
Yep. Same scope side interface
<azonenberg>
Then have MEAD be low-z only
<electronic_eel>
we could later also add a true differential one
<azonenberg>
Yep
<azonenberg>
I think thats the most flexible option
<azonenberg>
and then Pretzel4Ever would just need an alternative layout of the low-z version that has a ribbon cable input that attaches to the dram interposer
<azonenberg>
we might even be able to have the comparator board shared and just load/unload different components
<electronic_eel>
was just thinking about this too
<azonenberg>
then have an input board that mates to it and has either 100 mil headers or mmcx's or a ribbon zif socket
<electronic_eel>
how do we do the case?
<azonenberg>
you'd probably need different enclosures
<azonenberg>
but i expect low volume ones will be 3d printed anyway
<electronic_eel>
8 sma isn't that small...
<azonenberg>
yes which is why i suggested mmcx
<azonenberg>
mmcx is fine to 6 GHz and we wont be working nearly that high
<azonenberg>
we'd use sma for the higher speed version probably
<azonenberg>
MEAD is honestly probably going to be its own instrument
<azonenberg>
like an entire 1U system with 18 sma inputs or thereabouts
<azonenberg>
it won't be a peripheral for a scope
<electronic_eel>
hmm, so you plan two sell two different finished versions and the user isn't able to swap the parts
<azonenberg>
Correct. i expect the different CONWAY builds to have some parts missing/populated and different cases
<azonenberg>
I just want to avoid doing two pcb layouts
<electronic_eel>
I was more thinking about if the user could swap the parts, so that they only need one set of comparators
<azonenberg>
it would be a lot of rework to swap all of the passives
<azonenberg>
and for SI reasons i think putting the frontend on a separate board isnt practical
<azonenberg>
muxing might be an option but then you need rf relays or analog muxes
<azonenberg>
which will up the cost
<electronic_eel>
I don't mean resolder, I thought like a nice samtec connector where you plug in a different frontend
<azonenberg>
yes but we're changing the termination strategy
<azonenberg>
termination has to be really close to the comparator for SI reasons
<electronic_eel>
yeah, so probably it will be either one board with different population options or two boards
<azonenberg>
Correct. Or one board with both populated and some muxing
<electronic_eel>
if I think about it, you need proper pads for the mmcx
<azonenberg>
but i suspect the muxing will cost more than you'd save by just making two boards
<electronic_eel>
don't know if there will be enough space for pin headers
<azonenberg>
my plan is one board with the *connector* connected by a q-strip to the termination/protection/comparator board
<azonenberg>
this is how starshipraider was going to work too
<azonenberg>
but any given connector board will only be compatible with one load of the host board
<azonenberg>
the point of splitting is to avoid a re-layout of the host for the connector swap
<electronic_eel>
pcbs aren't that much of a cost factor now, good connectors are though
<azonenberg>
I guess we could do two layouts
<electronic_eel>
so I don't know if two different and complete boards aren't the better option
<azonenberg>
i'm thinking early on in the project pcb NRE is high
<azonenberg>
more so than the per board cost in volume
<azonenberg>
most of my projects to date have been optimized to reduce NRE even if the per-unit cost was higher
<electronic_eel>
you could just copy the complete comparator and output part and redo just the input part
<azonenberg>
because the setup fees for the pcb were of the same OOM as the components and i often only ever built one unit
<azonenberg>
Yeah i guess, although doing that in kicad is a bit tricky
<electronic_eel>
only problem I see is if you make changes to the common part after the copy was done
<azonenberg>
exactly the point
<azonenberg>
hmmmm
<electronic_eel>
I'd probably keep one version with just the pure comparator and output part and copy that 2 times to the different versions
<azonenberg>
Here's an idea
<electronic_eel>
then you copy again after a change in the common part
<azonenberg>
i wonder if we could just do a direct board to board castellation or similar?
<azonenberg>
you think we could get adequate SI that way?
<azonenberg>
keeping in mind this is only up to a few hundred MHz
<azonenberg>
heck, 100 mil headers might be ok
<electronic_eel>
you want the la pods to be small, so that you can get them near the dut
<electronic_eel>
additional headers and stuff work against that
<azonenberg>
yeah but 8 mmcx's isnt small
<azonenberg>
isnt that big*
<electronic_eel>
I think just copying the designs in kicad is easier
<azonenberg>
So i guess which one should we do first?
<azonenberg>
the comparator + mmcx version would be quite simple and easy to do, we dont have to worry about any protection other than ESD diodes for that since it's meant for low voltage probing with an attenuating probe
<electronic_eel>
we don't have to figure out much about the frontend for the transmission line one, don't we?
<azonenberg>
That was my thought
<azonenberg>
i feel like we could probably throw that together in a matter of days
<electronic_eel>
the other one needs a bit more thought
<electronic_eel>
also it would help Pretzel4Ever, so they could help with the design
<azonenberg>
well one of the reasons i suggested the socketed input module
<azonenberg>
is that we could put a ribbon input there
<azonenberg>
Rather than trying to run dozens of mmcx cables off a dram interposers
<azonenberg>
or doing a separate layout just for him
<electronic_eel>
hmm, true, that could also come in handy for other users that want to do their own connection module
<electronic_eel>
I remember seeing something similar from keysight
<azonenberg>
exactly, i feel like custom input modules just make sense
<azonenberg>
So, perhaps what we could do is make the 100 mil version with high z inputs be one layput
<azonenberg>
layout*
<electronic_eel>
they had specs which kind of samtec connector they were using for their 64 line probe or something along the lines
<azonenberg>
then have another layout with 50 ohm inputs and a socketed connector adapter
<electronic_eel>
a lot of these custom input modules will probably need more than 8 lines in parallel
<electronic_eel>
so they'll need multiple conway la pods
<azonenberg>
Correct
<electronic_eel>
how do they all connect up without wiring?
<azonenberg>
my thought was SFF-8087 from the CONWAY pods to the fpga board, 8 channels per cable
<electronic_eel>
you probably want them all on top of each other on the bench, but each in it's own case
<azonenberg>
then QTH-030 from the CONWAY pod to the connector board
<azonenberg>
then mmcx as the default loadout, then a custom one with some kind of ffc zif connector
<electronic_eel>
is there ffc zif stuff for 50 ohms?
<azonenberg>
i think so, worst case we could order our own flex pcb with impedance control
<azonenberg>
anyway so the interposer would contain the dut feedthroughs and 450R terminating resistors (probably just one resistor as super flat GHz frequency response doesnt matter for this application)
<azonenberg>
then at the ends of the "wings" just a zif socket
<azonenberg>
then ffc from that to the CONWAY pod
<electronic_eel>
the ffc I know has just n traces next to each other in some defined pitch, there is no groundplane or similar below
<electronic_eel>
the connectors are the same, they just take in the traces and bring them to the pcb
<azonenberg>
yes but we can spin custom flex adapters easily enough
<azonenberg>
two layer flex that mates with a normal ffc zif socket
<miek>
which model# is the keysight interposer?
<azonenberg>
oshpark even does flex now
<azonenberg>
thats a question for Pretzel4Ever
<electronic_eel>
then you just got the flex part, but not the connector - think about how small changes in your sma footprints matter much for the performance
<azonenberg>
it looks like the interposer doesnt have any resistors at all
<azonenberg>
electronic_eel: yes but that's at multiple GHz
<azonenberg>
and trying to be super flat
<azonenberg>
here we just want data recovery at a few hundred Mbps
<azonenberg>
the tolerances are overwhelmingly looser
<electronic_eel>
yeah, but I prefer a design that can be easily scaled up
<azonenberg>
for higher speed just do impedance control on the flex and use higher end connectors like q-strip soldered directly to the flex
<azonenberg>
in fact, that might even be viable for this
<azonenberg>
q-strip is 50 ohm controlled impedance
<miek>
if it's the same one i'm looking at, the resistors are buried
<azonenberg>
no need for an adapter board
<azonenberg>
solder a qth-030 directly onto the flex
<electronic_eel>
yeah, that looks better to me
<azonenberg>
so in that case the only custom design we'd need for Pretzel4Ever is a ffc that has a zif socket mating with the keysight interposer at one side
<electronic_eel>
some users might also just create their interposer or adapter thing directly out of flex and have one connector less
<azonenberg>
possibly some resistors if we want higher attenuation than whatever the interposer has
<Pretzel4Ever>
Keysight W2638A
<azonenberg>
and a q-strip at the far end
<azonenberg>
we could then use the off-the-shelf CONWAY 50-ohm version as the buffer module
<miek>
yup, that one's got buried resistors
<azonenberg>
and then he'd need probably some kind of adapter from sff-8087 to fmc or whatever connector the fpga devkit uses
<azonenberg>
sound reasonable?
<electronic_eel>
Pretzel4Ever: what kind of devboard to you plan to use?
<_whitenotifier-c>
[scopehal-apps] azonenberg edited issue #48: Add feature to reset/clear eye pattern and stats data - https://git.io/Jvc2L
<_whitenotifier-c>
[scopehal-apps] azonenberg commented on issue #17: Add UI for horizontal/vertical eye slice bathtub plots - https://git.io/Jf4P7
<azonenberg>
ooh if i'm reading tracking right, my new sma test boards are here
<Pretzel4Ever>
electronic_eel it is not a dev board. It is an industrial controller.
<Pretzel4Ever>
I do mostly software, so catching up with you guys is a little bit tricky for me. We want to sniff memory bus and decode LPDDR address and data line of the device.
<electronic_eel>
is the industrial controller your dut or the board you have a fpga on that you want to use to read the memory?
<azonenberg>
electronic_eel: it's the DUT
<electronic_eel>
"use to read the memory" is probably a bit sloppy. use to sample in the transactions on the dut is probably the better wording
<electronic_eel>
ok, I was more interested in the fpga board
<electronic_eel>
because that is what we have to interface the logic analyzer board to
<azonenberg>
yeah when i was talking to him earlier today he didnt seem to have any details about the fpga board
<azonenberg>
i dont even know if they have one yet
<Pretzel4Ever>
I want to connect the address and data lines of the LPDDR to an FPGA and decode it (which should be straight forward since it is based on JEDEC standard). It is not going to be in the same board. The FPGA will be a separated device and is going to be only connected to intercept the signals.
<Pretzel4Ever>
No we do not because we were stuck with acquiring signal
<electronic_eel>
ok, so basically you can buy whichever fpga board fits this problem well (and does not blow the budget)
<Pretzel4Ever>
As I explained to azonenberg, we were waiting for nearly 7 month for keysight to deliver us the interposer and the connector wings (W2639A). Now due to Corona we do not even have it yet.
<electronic_eel>
wow
<Pretzel4Ever>
I do not think it is going to blow the budget. How much budget for FPGA we are talking about?
<electronic_eel>
that kind of delays will blow your schedule
<azonenberg>
Pretzel4Ever: Depends on how many total bits of signal you're sniffing and how much io you need
<azonenberg>
it might actually be cost effective to do a custom design for this vs buying a devkit and making custom adapters
<azonenberg>
since most devkits include lots of peripherals you probably won't need
<azonenberg>
i'm picturing an artix7 in a high pin count package with a bunch of SFF-8087 connectors for the logic analyzer pods and then ethernet to the host PC
<electronic_eel>
also depends on the knowhow regarding board layout, signal integrity and so on
<azonenberg>
electronic_eel: there's a good chance i would end up doing the layout
<azonenberg>
Pretzel4Ever: re budget, the xc7a100t in fgg676, speed grade 2, is 180 USD on digikey for the bare chip
<electronic_eel>
azonenberg: ah, so you are taking this as a consulting side gig job or similar?
<Pretzel4Ever>
I think we can go up to 2k
<azonenberg>
you'd be looking at probably around 25 USD for all of the power infrastructure, maybe 10 USD for ethernet parts
<Pretzel4Ever>
I mean for that interposer without any connector we had to pay 2k
<azonenberg>
electronic_eel: more like a research collaboration. we havent figured out details but i'd be willing to do some free engineering in exchange for my name on the paper if they paid for components
<azonenberg>
Pretzel4Ever: well don't forget the buffer modules won't be free either
<Pretzel4Ever>
Sure. We are making a paper out of it.
<azonenberg>
those will probably be on the order of 100-200 USD per 8 bits
<azonenberg>
for the comparators, boards, and support parts
<azonenberg>
i think a 2k budget for the whole project is plausible if we can keep the number of layers on the fpga board to a minimum
<electronic_eel>
how about memory on the fpga board? don't you need to buffer like it is planned for the scope?
<Pretzel4Ever>
I think we can go to 3-4k
<azonenberg>
electronic_eel: no, he's going to be doing realtime analysis on the signals. not storing it
<azonenberg>
only reporting summary info when certain interesting things happen
<Pretzel4Ever>
If we have good reason for it. I can convince my professor for that
<azonenberg>
There might need to be a small external memory like QDR or something, we'd work that out later
<electronic_eel>
ah, so there is some kind of rle or even decoding on the fpga
<Pretzel4Ever>
yes
<azonenberg>
yeah they want to do full decode and analysis on the fpga
<electronic_eel>
hmm, don't know, is that really necessary?
<azonenberg>
without going into too much detail on their planned application i think it's the right choice
<electronic_eel>
wouldn't it be easier to do buffering to mem and then sending out via ethernet into scopehal be easier?
<azonenberg>
they need low latency and the actual summary data they're pulling off isn't that big
<azonenberg>
this isn't trigger and analyze offline
<azonenberg>
this is analyzing the entire bus, all of it, nonstop
<electronic_eel>
ah, ok
<azonenberg>
but only reporting certain interesting events when various addresses are hit etc
<Pretzel4Ever>
Exactly.
<azonenberg>
you'd need 40GbE or something to stream and then be faced with the analysis problem
<azonenberg>
Pushing the analysis to fpga is absolutely the right choice
<electronic_eel>
ah, so more something like a debugger where you set special breakpoints on memory change
<azonenberg>
then just send a small ethernet frame when a point of interest is hit
<electronic_eel>
or a hardware trigger on bus addresses
<azonenberg>
Exactly
<azonenberg>
anyway so i think basically you'd be looking at a minimialistic board with fpga, power, gig-e, jtag connector, and a bunch of sff-8087 lvds inputs
<azonenberg>
then the bog-standard CONWAY 50 ohm capture pod, some sas cables, and a custom flex adapter from the keysight interposer to CONWAY
<azonenberg>
(electronic_eel: did you see my pm btw?)
<electronic_eel>
can't you use one of your common fpga devboards for it and just design an input adapter?
<azonenberg>
yes, thats the other option, but then you need to do a FMC module with a whole bunch of 8087 inputs
<azonenberg>
fmc's arent cheap
<azonenberg>
and if they dont have a suitable fpga board already, i think a DIY option might actually be cost effective
<azonenberg>
they'd need something like an AC701 or biggerr
<azonenberg>
on their budget that's hard
<azonenberg>
compared to a $200 fpga, $500ish for PCB including setup fees, and a few support things i think i could do the entire board for less than the cost of an AC701 and that doesnt include the fmc to sff-8087 adapter we'd need
<azonenberg>
the ac701 just has a lot of fluff they dont need. most of the smalelr devkits like the arty don't have remotely close to enough lvds io
<azonenberg>
in fact i'm even concerned the ac701 wont have enough on the fmc, i havent actually checked how many total lvds lanes are required
<electronic_eel>
ah, no, I meant one of the fgpa board designs you did, wasn't it integralstick? I don't remember all the project names
<azonenberg>
Oh
<azonenberg>
integralstick only has 8 lvds input channels
<azonenberg>
these guys will need more like 40
<electronic_eel>
ah, ok, right
<azonenberg>
the full starshipraider host would have been perfect for this, had i ever designed it
<azonenberg>
but the prototype starshipraider single lane host only has 8 channels too
<electronic_eel>
would it make the board much more expensive if you add some capabilities we'd need for the scope project, like 10gbe and a ddr3l memory slot?
<electronic_eel>
would allow to use this board for scope development too
<electronic_eel>
so it is not just a one-off design
<azonenberg>
so i was actually just wondering if the BLONDEL host might be usable for htis
<azonenberg>
you might need to units of it
<azonenberg>
two*
<azonenberg>
but the savings in NRE might be worth it
<azonenberg>
we'll have external clock sync inputs already
<electronic_eel>
yea
<azonenberg>
Depends in part on how long they can wait as that board will take time to design as it's a lot more complex
<azonenberg>
in any case i think the logical next step all things considered is to design the CONWAY 50 ohm pod, then a starshipraider plugin that has a single sff-8087 connector for talking to it
<azonenberg>
so we can test the pod
<azonenberg>
then at some point in the future we can do a high impedance version of CONWAY but that won't change the host side interface
<electronic_eel>
it could also work as a rev 0 playground board, which has most of the stuff needed for BLONDEL, maybe not layed out in perfect physical location, but usable to test out all features
<azonenberg>
which is what we need finalized to move forward
<azonenberg>
hmmmm
<azonenberg>
i guess thats a possibility too but i'd want to have it mostly final by the time i do that
<azonenberg>
the single channel carrier can be used with integralstick
<azonenberg>
so thats a good starting point IMO
<electronic_eel>
but does integralstick has memory and 10gbe?
<electronic_eel>
have
<azonenberg>
no it would be there to test the CONWAY board
<azonenberg>
we'd capture to block ram then stream over 1gbe
<azonenberg>
it wouldnt be a production system, it'd be a quick cheap prototyping platform
<azonenberg>
ooh i just realized something
<azonenberg>
I think we could do this on one BLONDEL
<azonenberg>
build an adapter board that replaces the analog board and has a LA connector instead
<azonenberg>
that would allow at least four LA pods on a single BLONDEL system
<azonenberg>
with a new bitstream of course but completely reuse the host board
<azonenberg>
Pretzel4Ever: can you figure out how many total input channels the system needs?
<Pretzel4Ever>
So, do you mean how many I/O pins we want to trace, right?
<azonenberg>
Yes
<Pretzel4Ever>
Sure.
<azonenberg>
it looks like 16-bit LPDDR has DQ[15:0], A[13:0], then a DQS and DM for each byte group (4 total pins), CKE, differential clock, CS, WE, RAS, CAS
<azonenberg>
if my math is right that's 16 + 14 + 4 + 1 + 2+ 4 = 41
<azonenberg>
and if we only looked at one leg of the clock we could get it down to 40
<azonenberg>
i bet some clever hacking could squeeze 8 more inputs somewhere into the system
<azonenberg>
maybe on a connector we normally DNP or something
<azonenberg>
Having the ability to reconfigure a BLONDEL by trading LA pods out against analog channels might not be a bad thing
<electronic_eel>
but that would mean re-plugging the whole afe board, not switching some mux only, right?
<azonenberg>
Correct
<azonenberg>
it would involve replacing the entire afe board with a custom board developed for that purpose that has a sff-8087 connector
<azonenberg>
different pinout than the LA pod probably, since the LA board also will have the external trigger on it
<azonenberg>
but we might be able to make them compatible enough to swap with only a bitstream change
<azonenberg>
i.e. diff signals and clocks in the same spots, etc
<electronic_eel>
hmm, just one more la pod instead of whole 4 analog channels isn't that good of a deal for many people
<azonenberg>
Yes but in specialized applications like this it's potentially useful
<azonenberg>
i wouldnt necessarily offer it as an official feature
<azonenberg>
but if we can design the board with it in mind, it might be handy
<electronic_eel>
it will become more interesting for the higher end scopes
<azonenberg>
you mean swapping one analog channel for a bunch of LA inputs? yes
<azonenberg>
but right now i'm trying to think about how to solve Pretzel4Ever's problem with the minimum amount of extra work on our part
<electronic_eel>
tek has this design where you have 6 or 8 channels and you can either plug in a scope probe or a la pod with 8 channels
<azonenberg>
yeah i've seen that
<azonenberg>
and so i'm trying to think how we could get 40 la channels on a blondel without any major retooling
<azonenberg>
and i think it's doable
bvernoux has quit [Quit: Leaving]
<azonenberg>
electronic_eel: so Pretzel4Ever just sent me more info on the ram, its 32 bits wide. So that means something like 72 channels to sniff total
<azonenberg>
this just got harder :p i'm thinking a custom board is going to be a more viable option than trying to cram that much into a BLONDEL
<electronic_eel>
yeah, otherwise we'd need a bigger fpga for BLONDEL and make it more expensive
<electronic_eel>
also has the advantage that it will be finished faster
<azonenberg>
Yeah
<azonenberg>
So i guess the plan is going to be, design the CONWAY board and an INTEGRALSTICK host for it first
<azonenberg>
if it works well, then spin a custom board for nine channels of CONWAY to an artix7
<electronic_eel>
yes, sounds about right
<electronic_eel>
do we need a test board for the comparator first or go straight to the final board?
<azonenberg>
which comparator were we going to use again? lmh7322?
<electronic_eel>
yes, lmh7322
<azonenberg>
i have past experience with it and don't expect problems. my plan was to go direct to multech and order like 50 boards
<azonenberg>
once you pay the NRE, extra pcbs doesn't cost much
<azonenberg>
and they're going to be much cheaper than oshpark for volume
<azonenberg>
probably 4 layer enig on isola 370hr
<electronic_eel>
hmm, not 3 oshpark boards first?
<azonenberg>
no, for a couple of reasons
<azonenberg>
one is that i'd need to either redo all the impedance calculations or use fr408 (more expensive) for the final board
<azonenberg>
the other is that this is likely to be a fairly decent sized board and oshpark charges by area
<azonenberg>
it's probably going to be close to $100
<azonenberg>
given that the board is literally a bunch of comparators and some connectors, i'm confident enough we can get it right the first time that i'm willing to do a larger order
<azonenberg>
$100 for 3 vs $400 for 50 is such a huge drop in cost per board it just seems logical
<azonenberg>
although i'll make the final call once i get the rough board floorplan figured out and get a quote from multech for the actual size
<electronic_eel>
okish. I'm always worried about getting it wrong mechanically, like fitting somehow, but not being nice to use
<electronic_eel>
that is why I want at least one mechanical sample with all the bigger components on it before making the call for a bigger run
<azonenberg>
re mechanically, the shell will be 3d printed and designed around the board
<electronic_eel>
yeah, but if you get the spacing of the connectors too tight or similar that won't help you
<azonenberg>
and 3d printing has basically zero NRE
<azonenberg>
Oh. MMCX's are push con connectors though
<azonenberg>
push on*
<azonenberg>
you can pack them quite tight
<azonenberg>
and i have other boards i've made with lots of MMCX that i can compare against and see whats a good pitch
<electronic_eel>
that is just what I thought of now, the problem happens with the stuff you didn't think of
<azonenberg>
also more importantly the mmcx's will be on a separate socketed board
<azonenberg>
i may well oshpark that at least to start
<electronic_eel>
another thing is negative voltages: the lmh7322 allows just vee-0.2v, but I think it is reasonable to expect a sma input to survive a few volts negative
<electronic_eel>
and 0.2v is very tight for schottky
<electronic_eel>
and schottky isn't the best for low capacitance
<azonenberg>
i'll sit down and look at various comparators. these are mmcx and i was thinking of running +/- 6V supply with clamps to +5/0 or similar
<electronic_eel>
we'll have to do some diode searching
<azonenberg>
that will allow plenty of headroom
<azonenberg>
But like i said no final decision yet
<electronic_eel>
wasn't the problem with the lmh7322 and +-6v that it would get too hot?
<electronic_eel>
you don't want to install fans in a la pod ;)
<azonenberg>
it pulls 12 mA per channel max from vcc
<electronic_eel>
maybe something like -1v and +6v with clamping to 0/5v could work
<azonenberg>
so 96 mA @ 12V 1.1 watts
<azonenberg>
and we're using LDOs
<azonenberg>
that power gets dissipated somewhere regardless
<electronic_eel>
that is quite a lot
<azonenberg>
spreading it across 8 comparators vs one LDO seems logical
<azonenberg>
you think 1W of heat across something this big is going to be a problem?
<electronic_eel>
now we don't need to supply the la with +-12v
<azonenberg>
i was going to supply with +/- 7 or so
<azonenberg>
then ldo to +/-6 at the pod
<azonenberg>
which is a 12v span
<electronic_eel>
don't know if 1v dropout is enough for good quality, on the afe board we used more
<azonenberg>
we can do a bit more if needed but this is digital. its not like we need 90 dB PSRR :p
<azonenberg>
Re power, the adc+integralstick board combo is currently pulling 657 mA @ 5V which is 3.3W
<azonenberg>
if i hold my hand over them i can barely detect a bit of heat coming off
<electronic_eel>
hmm, I remember the guys on the eevblog forum reversing the rigol la saying that it got quite hot
<azonenberg>
the hmcad1520 is about 49C, the fpga is around 40
<azonenberg>
nothing else is even close
<azonenberg>
this is in still air
<azonenberg>
now, that is vcc and not vcco power
<azonenberg>
vcco is another 25 mA per channel
<electronic_eel>
12mA per channel is just the input for the lmh7322, the output is up to 25mA + the actual load
<azonenberg>
to get lvds compatible outputs we'd run the output at 2.5V
<azonenberg>
so perhaps we might want a tiny dcdc for that?
<azonenberg>
200 mA * 2.5V = 0.5W for output plus actual load
<electronic_eel>
yeah, better than driving 2.5v from 7v or higher
<azonenberg>
if reasonably shielded i dont think a dcdc for that is a big deal
<azonenberg>
shielded inductor and some space from the analog inputs should be fine
<azonenberg>
the probe inputs*
<electronic_eel>
the question is if we use one dcdc, if we shouldn't run it completely with internal dcdcs
<electronic_eel>
and just supply 12v
<azonenberg>
That is a valid argument. Active probes are a different story, the +/-7 was really meant for those
<electronic_eel>
would be more flexible for different kinds of la pods
<azonenberg>
Yeah
<electronic_eel>
I mean the scope side
<azonenberg>
But then we have the negative rail problem
<azonenberg>
unless we put some inverting dcdc's on the probe
<azonenberg>
Which i guess isnt a huge deal
<electronic_eel>
yeah, it is no big deal
<electronic_eel>
you just wanted to pick a very quick solution for the afe board, could have chosen a cheap&small dcdc there too
<azonenberg>
So i guess tonight i'll sit down and try to throw together a schematic for the LA pod
<azonenberg>
will you be around in a couple of hours to go over details?
<electronic_eel>
no, I'll go to bed very soon
<azonenberg>
ah ok
<azonenberg>
we can talk tomorrow once i have results then
<electronic_eel>
yes, I can take a look in the evening
<azonenberg>
electronic_eel: re blondel and this project though
<azonenberg>
i think it makes sense to turn this project into a standalone product with its own name, i'll go pick one in a bit
<azonenberg>
make it a 1U appliance with 10GbE and maybe even the same lcd and such as BLONDEL, as kind of a dry run for BLONDEL
<electronic_eel>
isn't the la pod still CONWAY?
<azonenberg>
then Pretzel4Ever can just not populate those parts if he doesnt need them
<azonenberg>
no i mean the host
<azonenberg>
a standalone LA, not a MSO, with like ten CONWAY inputs
<electronic_eel>
ok, for the host a new name makes sense of course
<azonenberg>
Exactly
<azonenberg>
what i'm saying is, we can make it a full system with the same LCD and back panel connections and maybe even clock generation as BLONDEL
<azonenberg>
and if most of those don't work Pretzel4Ever can still get his work done
<azonenberg>
but we've ironed out bugs for BLONDEL
<electronic_eel>
but the specs aren't really those of a traditional la, there is much too little throughput to the pc (or memory)
<azonenberg>
Well my thought was to throw a QDR-II or something on there
<azonenberg>
and then 10GbE using the same chipset we're using on BLONDEL
<azonenberg>
he can always not populate them
<azonenberg>
but if we're paying the NRE for a multilayer controlled impedance board, the marginal cost of adding some more features like that is just the engineering time
<azonenberg>
and if we end up with a schematic we can cut and paste most of into BLONDEL, then great
<electronic_eel>
yeah, standalone la with 80 channels might be an interesting product
<electronic_eel>
quite expensive to get from the likes of keysight or lecroy
<azonenberg>
And we can plug it right into scopehal and such. I'd definitely use it
<azonenberg>
i mean only ~1 Gsps but that's still enough for a lot of embedded debug
<azonenberg>
the other option is to maybe use a kintex7 instead which will let me run a decent bit faster
<azonenberg>
but i have to look at package options, how many pins various things need, etc
<azonenberg>
anyway i'm getting ahead of myself
<azonenberg>
first step is the CONWAY pod and the single channel integralstick test host for it
<electronic_eel>
don't traditional upper class las have some advanced timing options? like integrated pll with phase shift and stuff to match the timing of the dut?
<electronic_eel>
wouldn't something similar make sense for this too?
<electronic_eel>
maybe not strictly necessary for the ddr1, but still worthwile to find timing problems on memory controllers
<azonenberg>
electronic_eel: so the 7 series iodelay lines might be useful to use for this to enable fine phase shift on individual channels
<azonenberg>
i was going to just use an MMCM for the actual sample collection
<azonenberg>
since the jitter of the fpga clock tree is going to be a limiting factor if you use an external pll
<azonenberg>
SMA test boards came in. i have four, interestingly. Not three
<electronic_eel>
how would the main clock of the fpga be controlled? on the scope it would be a pll, controlled from a 10MHz in
<azonenberg>
i'd source 10 MHz from either an external reference on the mainboard or an on board TCXO
<azonenberg>
then feed that into a MMCM on the FPGA (xilinx PLL IP)
<azonenberg>
on the scope we're using an external pll because we can feed that clock directly to the adcs bypassing the fpga clock tree
<azonenberg>
on the la, the sampling is done in the fpga clock domain
<electronic_eel>
on the la one might want to use external 10MHz too, but it could also be from a special clock channel, coming from the dut
<azonenberg>
So i will have the ability to do arbitrary complex clock muxing in the bitstream if i want
<azonenberg>
i will certainly use clock capable inputs for some of the la outputs
<azonenberg>
maybe standardize channel 0 of each CONWAY pod can be used as a clock
<azonenberg>
or something like that
<electronic_eel>
yeah, that would make sense
<electronic_eel>
and then add some user controllable phase shift on top of that clock channel input
<electronic_eel>
and use x4 or x8 or something off the clock channel, of course, classic pll functions
<azonenberg>
well the clock channel would just go into the pll ip
<azonenberg>
at which point i'd be able to do whatever using partial reconfig on the pll
<azonenberg>
i'll probably have an external mux to select between the TXCO and a comparator on the back panel refclk input
<azonenberg>
feed that into the fpga
<azonenberg>
then have some kind of mux tree between the LA pods as alternate clock sources
<azonenberg>
i'll have to think about what makes sense
<azonenberg>
either way it wont influence the pod design
<azonenberg>
so the pod comes first
<electronic_eel>
ok, sounds reasonable
<electronic_eel>
the sma test boards that you just got - they were to test the sma footprints of the passive probe?
<azonenberg>
they're testing the new amphenol rf sma
<azonenberg>
on the oshpark stackup
<azonenberg>
the goal being to validate performance of that SMA against a sonnet model
<electronic_eel>
won't the enig of oshpark be a limiting factor there?
<azonenberg>
and then if i get good results probably do the same board with the samtec part
<azonenberg>
out to 6 GHz? it shouldnt. But i'm less concerned about skin loss because i can model that if i care to
<azonenberg>
i mean there will be more loss but we're talking a fraction of a db
<azonenberg>
it's more the impedance match that i care about
<electronic_eel>
or is the goal more to get this kind of loss simulated properly?
<azonenberg>
the goal is to have a frequency response that matches the simulation as a basic ground truth to use for future testing
<electronic_eel>
and impedance match of course
<azonenberg>
if there's differences i can quantify, like enig loss, that's not a big deal
<azonenberg>
what i want to avoid is a random 2 dB dip at 3.75 GHz that doesn't show up in the simulation :p
<electronic_eel>
so more of honing your sonnet skills
<azonenberg>
Kinda-sorta. also validating the footprints and vna and lots of other things
<azonenberg>
i basically want to have a halfway decently matched transition that closely matches the simulated design
<azonenberg>
and then go from there
<azonenberg>
because right now on the probe-characterization board there are a bunch of mismatches with sim that i am still trying to explain
<azonenberg>
although i'm getting closer
<electronic_eel>
do you plan to redo the probe-char board, once you got the footprints improved and such?
<azonenberg>
Yes, although first i want to (through a combination of reworking the board and tweaking the sim) get closer to some level of agreement
<azonenberg>
so i know *how* to improve
<azonenberg>
with the samtec connectors on that stackup, soldering the bottom side of the SMA made a huge difference
<electronic_eel>
you put a bunch of vias next to them, right? so I wouldn't have tought that it would make much difference
<azonenberg>
Yes. The sonnet engineer was confused too
<azonenberg>
his theory is that perhaps some of the vias are bad
<azonenberg>
he did a sim with all of the vias around the CPW deleted, and got some cavity resonances close to the frequency of (but more intense amplitude than) what i observed
<electronic_eel>
hard to find out in this case, without cutting the board
<azonenberg>
i am rapidly approaching the point that i am willing to sacrifice one in the name of science
<azonenberg>
i have ten of the bare boards, i'd want to VNA a board assembled with only the SMAs and see how it looks
<azonenberg>
(on the thru line)
<azonenberg>
then cut it approximately to size, pot it in epoxy, let it cure
<azonenberg>
do a final cut right down the midline, polish, etc
<azonenberg>
it would take a bit of work but should shed a lot of light on things
<azonenberg>
so i will most likely do it
<electronic_eel>
ok, I think I'll go to bed now
<electronic_eel>
good night
<Degi>
I wonder if you can stick PCIe onto SFF-8087
<Degi>
Wow those cables are cheap
<Degi>
7 bucks for a 70 cm cable
<azonenberg>
yeah
<Degi>
Lol those "RMF/RF shielding" tents look useful to put RF stuff like a DIY microwave in to.
<azonenberg>
Degi: what do you think of the logic analyzer idea we were talking about earlier?
<azonenberg>
making a standalone LA with no analog inputs, just like ten CONWAY connectors
<Degi>
Ah that one about the RAM thingie
<Degi>
Oh that'd be neat though I don't have much use for that, but yes for large parallel logic its definitely a necessity
<Degi>
A conway probe has 8 cables yes?
<azonenberg>
yes. so you'd get 80 inputs
<Degi>
Hmm you could debug old stuff like PCI or ISA lol or maybe a small RAM module
<Degi>
(I think modern DDR sticks are like almost 300 pins?)
<azonenberg>
240 but many are ground
<azonenberg>
its only 64 data plus addr/control, maybe 90 total
<azonenberg>
also we're going to make two variants of conway
<azonenberg>
one with 100 mil high impedance inputs and one with 50 ohm inputs for transmission line probes
<azonenberg>
idea: what if we named that one MEAD? I had planned to use that as the name for the GTP based LA
<azonenberg>
but mead and conway were coauthors of a rather famous textbook
<azonenberg>
so having them be two halves of what's conceptually the same project might make sense
<Degi>
Why not both in one
<azonenberg>
thought about it. it would mean lots of relays and muxing and make the pod much bigger
<Degi>
How much ios does the fpga have?
<Degi>
Hm yes
<Degi>
Conway is the probe itself, right?
<azonenberg>
Yes
<Degi>
Oh yeah making 2 different versions makes sense then
<azonenberg>
so my thought is to rename things, CONWAY is the high-Z variant and MEAD is the 50 ohm variant
<azonenberg>
both will have the same host side interface
<azonenberg>
just different front ends
<azonenberg>
same comparators, probably copy pasted layout
<Degi>
And both have 8ch?
<azonenberg>
Yes
<Degi>
So on the 10 input thingie you can mix a few, nice
<azonenberg>
the not-yet-named 10 input host will have a total of 80 LA channels
<Degi>
Hmm what if we put a tiny buffer IC at the head of a LA probe lol
<azonenberg>
split across 8 MEAD or CONWAY pods
<Degi>
Thats a neat idea
<Degi>
Though I'm not sure what does 50 ohm at < 1 Gb/s
<Degi>
Maybe USB
<azonenberg>
it would be used with transmission line probes for interposers and such
<Degi>
Hm yes
<Degi>
Soo uhm can we just add DNP to CONWAY for 50 ohm resistors?
<azonenberg>
well there will be other differences
<azonenberg>
CONWAY will have 100 mil header inputs
<azonenberg>
MEAD will have a q-strip that you can connect to either eight MMCX's or a custom probe adapter
<azonenberg>
MEAD might also be capable of running quite a bit faster given appropriate host side support
<azonenberg>
The LMH7322 has a max toggle rate of 3.9 Gbps
<azonenberg>
it's not implausible that we could build a host that can run at, say, 12 Gsps using MEAD as the input stage
<azonenberg>
CONWAY's high impedance wide range input stage will likely limit bandwidth
<Degi>
Huh that ones cheaper than I expected. Yes
<azonenberg>
i originally considered making them just load-time variants and i don't think that is viable
<Degi>
Hmmm or we put a 100 mil header onto a Q strip lol
<azonenberg>
the other advantage is, MEAD can be built right now
<azonenberg>
there's no additional design/engineering needed, just a straightforward board layout
<Degi>
Load time as in having switches inside?
<azonenberg>
no i mean board assembly time
<azonenberg>
CONWAY still needs some more work on the frontend
<azonenberg>
and Pretzel4Ever doesn't want to wait forever :p
<Degi>
Hm yes
<Degi>
So CONWAY right now is pretty much MEAD without the 50 ohm resistors?
<azonenberg>
CONWAY's frontend doesnt yet exist
<azonenberg>
but it's going to have some kind of high impedance attenuator or something
<azonenberg>
to get like 100k or something input impedance
<azonenberg>
MEAD is just direct 50 ohm inputs with ESD protection and not much else
<Degi>
oh, but with comparators?
<azonenberg>
Yes
<azonenberg>
both will use the same LMH7322s, power supply, and interface to the scope
<azonenberg>
and be drop in compatible
<Degi>
Hmm how do you translate the output from the LMH7322 to FPGA levels?
<azonenberg>
If you set VCCO=2.5 and terminate it right, it puts out LVDS-compatible levels
<Degi>
Oh neat
<azonenberg>
then we just use normal LVDS inputs on the FPGA
<azonenberg>
i used it on my original TDR
<azonenberg>
way back in like 2015
<Degi>
I wonder if you can just build a delta sigma with that lol and stick that to a fiber optic cable with an inverse delta sigma on the other end and tadaa, isolated analog probe
<azonenberg>
lol
<Degi>
It could actually work surprisingly well compared to the alternatives
<Degi>
How about a probe with 50 ohm output? That should provide similar performance on 1 MOhm input devices as a full 50 ohm system
<Degi>
Because itd swallow reflections
<Degi>
Good night
<azonenberg>
ok so i'm gonna try and assemble the sma test board
<azonenberg>
It fits the pcb a lot looser than i'm used to
<azonenberg>
maybe because its not supposed to make contact on the bottom?
<azonenberg>
i dont think its going to be easily reflowable
Pretzel4Ever has quit [Read error: Connection reset by peer]