<azonenberg>
And they already have i2c on the connector to the platform from the amp etc
<azonenberg>
Bird|otherbox: any updates on the static analysis stuff during the week? I've been going through gradually fixing errors
<azonenberg>
there have been a lot of little performance suggestsions as well as a few "OK now but could be iffy if things changed" like default copy constructors on classes that should have been noncopyable
<azonenberg>
and one legitimate memory leak so far
<azonenberg>
After lots of fixing i'm now about 18% of the way through a full build with analysis with no errors
<Bird|otherbox>
azonenberg: still trying to figure out how to get ccc-analyzer to dump the command line it passes to gcc *sigh*
<azonenberg>
other than that one you're working on
<monochroma>
Bird|otherbox: i have temporarily modified files to replace toolchain binaries with scripts that log the environment and argumented, and then pass those to the real binary in the past
<monochroma>
arguments*
<Bird|otherbox>
yeah, I'm hoping there's a better-supported way than having to inject stuff into the toolchain like that though
<_whitenotifier-f>
[scopehal-apps] azonenberg opened issue #237: cppcheck false positives due to LogFatal not being parsed as noreturn - https://git.io/JTn6O
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #237: cppcheck false positives due to LogFatal not being parsed as noreturn - https://git.io/JTn6O
<azonenberg>
Bird|otherbox: in case you wanted more static analysis excitement to work on, lol
<azonenberg>
if not, i'll poke at it myself when i get a chance
<azonenberg>
first step is gonna be fixing the easy stuff though
<azonenberg>
$ git status | wc -l
<azonenberg>
188
<azonenberg>
this is going to be a big diff. but i'm making tiny changes like changing string to const string& arguments across zililons of files
<azonenberg>
not really a good way to break it up into multiple commits
<Bird|otherbox>
yeah, I know the pain man
<Bird|otherbox>
I think I have a bead on why cppcheck is false-positiving on LogFatal btw
<azonenberg>
this was definitely a good idea though
<azonenberg>
and oh?
<azonenberg>
great
<azonenberg>
i have a noreturn declaration but it might not be formatted in a syntax cppcheck understands
<azonenberg>
well if you can fix that easily then go for it
<azonenberg>
Sorry to turn you into the build system guru, lol, but you seem to be good at it
<azonenberg>
If you want to work on another area of the project let me know, there's plenty of stuff to be done
Pretzel4Life has quit [Ping timeout: 265 seconds]
Pretzel4Ever has joined #scopehal
electronic_eel has quit [Ping timeout: 260 seconds]
electronic_eel has joined #scopehal
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-2/±1] https://git.io/JTn7q
<_whitenotifier-f>
[scopehal-apps] azonenberg 8878adc - cppcheck now runs in C++ 11 mode, rather than suggesting improvements using C++ 20 features not available on older-but-still-supported platforms like Debian. Removed old ibistest prototype
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±179] https://git.io/JTn78
<_whitenotifier-f>
[scopehal] azonenberg 7a81e35 - Lots of small fixes found by cppcheck. Mostly adding missing =delete copy constructors/assignment operators on noncopyable classes, and passing constant strings as references.
<azonenberg>
Bird|otherbox: i spent way too much time fixing if(str.find("foo") == 0) to if(str.starts_with("foo")) before trying to compile
<azonenberg>
at which point i realized
<azonenberg>
a) that is a c++ 20 feature
<azonenberg>
and b) debian stable's gcc 8.3 does not support C++ 20
<azonenberg>
I think we could go to c++ 17 if we wanted to and had a good reason, but i have no immediate plans to do that
<azonenberg>
Once all supported platforms have c++ 20 support, starts_with alone is probably enough of a reason to migrate to that
<azonenberg>
but until then i think we'll be sticking with 11 unless someone has a good reason to switch to 17
_whitelogger has joined #scopehal
<azonenberg>
lain, monochroma, Kliment: wish me luck...
<azonenberg>
I just took apart my 1.5 GHz active probe (ZS1500)
<azonenberg>
Took some photos
<azonenberg>
Going to try and power it up on the bench, sans scope, and put it on the VNA
<monochroma>
:O
<monochroma>
good luck!
<lain>
がんばって！
<azonenberg>
ok, step one done
<azonenberg>
it powers up and didnt let out any magic smoke
<azonenberg>
about 90 mA load on both +12v and -12V
<azonenberg>
so far got a bunch of scope screenshots
<azonenberg>
it seems to have not super flat response :p
<azonenberg>
i think they correct in post
<monochroma>
:o
<azonenberg>
going to compare the scope with the "naked" probe and with it propelry detected and assembled on the same test signal
<azonenberg>
First step is vna measurements though
<monochroma>
:D
<azonenberg>
interesting, it seems like it's actually closer to a 1 GHz probe than a 1.5 on my VNA
<azonenberg>
It's flatter than the TA061 for sure :P
<azonenberg>
yeah i measure -8 dB of insertion loss at 1.5 GHz
<azonenberg>
interesting observation: the probe gets unhappy if you don't have a 50 ohm load on the output
<azonenberg>
it draws about double the usual current and puts out -8V into a high impedance load
<azonenberg>
But if you put a 50 ohm load across the output the offset is a mere -113.59 mV
<azonenberg>
Speaking of which, do you know how hard it is to get a multimeter to measure a coaxial signal across a 50 ohm load? :p
<azonenberg>
I had to use a SMA-to-banana adapter
<azonenberg>
then a SMA tee with a F-F adapter coming off one port to a terminator
<azonenberg>
then a SMA cable to a SMA-BNC adapter
<azonenberg>
which finally went to the DUT
* Kliment
is reminded of the contraption for measuring flex antennae on a VNA
<azonenberg>
So, at this point i think the tricky part is done, Only thing left is to see if i can sniff the i2c
<azonenberg>
i wonder if i can do an acquisition on the same scope
<Kliment>
SMA to u.fl, custom board with u.fl to flex
<azonenberg>
or if it will halt the trigger or something during the i2c transactions
<Kliment>
and same board with 50 ohm load for calibration
<Kliment>
and for the "short" calibration I just short it out with tweezers
<_whitenotifier-f>
[scopehal] azonenberg pushed 2 commits to master [+0/-0/±2] https://git.io/JTctB
<_whitenotifier-f>
[scopehal] azonenberg ce1a2ed - ClockRecoveryFilter: removed dead profiling code
<_whitenotifier-f>
[scopehal] azonenberg 61b51ec - ClockRecoveryFilter: fixed memory leak in error handling. Thanks cppcheck!
<azonenberg>
you cant tell me there is a better way to ground this probe
<azonenberg>
VNA right into the fixture, and then a BNC-to-SMA port on the output of the amplifier going into the other VNA port
<azonenberg>
The one thing i might want to re-test at some point is changing the DC bias of the VNA and see if that makes a difference
<azonenberg>
the probe appeared to act strange if you didnt have a 50 ohm *DC* load on the output
<azonenberg>
and the VNA inputs have a 300 kHz ac coupling with bias tee
<azonenberg>
so at some point i'd like to try figuring out a way to put a 50 ohm resistance across the bias tee (nontrivial because it's a SMB connector which i have nothing to mate with)
<azonenberg>
and see if i get any different results
<azonenberg>
I plan to go ahead with the review as is and state this as a potential source of error in the writeup
<azonenberg>
then possibly amend in the future if i repeat the experiment
<azonenberg>
Rise time connected to the scope was 269 ps though, which is what you'd expect from ~1.3 GHz bandwidth
<azonenberg>
So if the DC bias has an impact it's not huge
<monochroma>
azonenberg: this is the same interface that's on my scopes right?
<monochroma>
connector*
<azonenberg>
what, the bias tee? no, prolink is BMA
<azonenberg>
not SMB
<azonenberg>
i mix them up too
<monochroma>
okay, yeah i was making sure you knew those were BMA
<monochroma>
mouser had some nice BMA adaptors
<azonenberg>
Yeah the VNA has SMB for the bias tees and N for the actual signal inputs
<azonenberg>
So if i have a 50 ohm terminator across the SMB on port 2 i can give the probe the DC load it expects
<azonenberg>
my fear is that some of this frequency response is the amplifier railing or something
<azonenberg>
But looking at time domain plots between the two tests they look quite similar
<azonenberg>
so i don't *think* this is the case
<azonenberg>
oh nvm forget what said
<azonenberg>
the time domain plots were both into the scope with 50 ohm loads, just one open on the bench and one put together
<azonenberg>
the VNA had dc blocking internally
<azonenberg>
So i dont know what the time domain waveform looked like there
<azonenberg>
but i am seriously considering ps -> fs
<azonenberg>
some higher scope sample rates don't divide cleanly into ps
<azonenberg>
80 Gsps = 12.5 ps for example
<electronic_eel>
ah, ok, clean dividing can become an issue
<azonenberg>
it would be a significant refactoring though, since all drivers and a bunch of math filters would need to be updated and we'd have to be sure we didn't miss anything
<azonenberg>
We'd also have to do a file format version bump, since i don't want to lose my test data acquired with current scopehal
<azonenberg>
i dont know if there is a version field in the scopesession yet but if not i guess we can say no version = version 0
<azonenberg>
anyway, it's planned but a long ways out from happening
<electronic_eel>
yeah, the zeptosecond scope on your bench is also a way out unfortunately
<azonenberg>
lol
<azonenberg>
That too
<azonenberg>
monochroma: also, the perfectionist in me isn't willing to do the review with any doubts about data quality
<azonenberg>
i'm going to redo the measurements soon
<azonenberg>
I just realized something
<azonenberg>
my nearfield EMC probes are SMB and i think the right gender
<azonenberg>
and i have a SMB-to-SMA cable that came with them
<azonenberg>
if i put a terminator on the other end with a SMA M-M coupler, i can do a 50 ohm SMB load
<azonenberg>
it will be hanging off a foot or two of coax but it's on the DC side of a bias tee
_whitelogger has joined #scopehal
<azonenberg>
and actually... there is a little "magic"
<electronic_eel>
monochroma: you asked wrong. it is "did you put an x-ray on your ebay searchlist"
<azonenberg>
because i believe the baseline tetris does not have offset control
* azonenberg
double checks
<azonenberg>
Yeah. i'm seeing nothing about that
<azonenberg>
i think lecroy added the offset feature
<azonenberg>
there was probably a bias trimpot to correct for the zero in the baseline design
<azonenberg>
and then lecroy put a dac there instead
<electronic_eel>
ok, so a little magic with the additional dac. so definitely worth doing
<azonenberg>
also it pulls ~90 mA @ +12 and -12V with the output floating or high-Z
<azonenberg>
and the output has about a -8 to -7.8 volt DC bias (seems to slowly drift downward as you leave it on longer, it's not stable)
<azonenberg>
unsure if oscillating or just a huge bias
<azonenberg>
if you apply a 50 ohm load to the output, power consumption drops to 40 mA
<azonenberg>
and the output with the probe tip shorted to ground is -113.59 mV DC offset
<azonenberg>
interestingly i do not see that offset when i plug the probe in with the full probus interface, rather than plugging in BNC only with the probe powered by a bench supply
<azonenberg>
So i suspect the eeprom has a cal coefficient stored in it to remove that dc bias
<azonenberg>
either in postprocessing, or by loading an offset correction into the DAC
<azonenberg>
unfortunately it's nontrivial for me to sniff the probus
<azonenberg>
it appears that the scope UI freezes momentarily when you mate a probe as it reads the ID and it doesnt trigger during that time usually. I got it to happen once but didnt have glscopeclient connected to download the waveform
<azonenberg>
And i can't plug it into my other scope because it's just a little bit too far away for a probe from the first one to reach
<Degi>
Hmh
<azonenberg>
so i'd need to unrack it
<Degi>
The 8 V could be from a current mode drivfer?
<azonenberg>
Degi: I dont know. it's the kind of thing i would expect from an RF amplifier biased at the output or something
<azonenberg>
except this goes down to DC so it's not that
<electronic_eel>
it's just i2c, right? use the el cheapo logic analyzer instead?
<azonenberg>
electronic_eel: the one i just bought and havent added a scopehal driver for yet?
<azonenberg>
yes, that was actually my plan
<azonenberg>
i have to write said driver first
<azonenberg>
now i have an excuse
<electronic_eel>
yes, that one. or any other la you have around
<azonenberg>
I have nothing else
<azonenberg>
just the two lecroy scopes and the cheapo fx2 la
<electronic_eel>
ok, so that one
<azonenberg>
yes i could use sigrok but if i force myself to do it in scopehal now i have an excuse to write a driver
<azonenberg>
So that's the plan
<azonenberg>
but before i do more scopehal R&D work i'm also focusing on fixing a bazillion static analysis findings
<electronic_eel>
IIRC sigrok has created their own firmware for them, maybe have a look at that
<azonenberg>
so far two legit memory leaks and a bunch of relatively minor performance improvements
<azonenberg>
that is my plan
<azonenberg>
ship the sigrok firmware as a blob, write a libusb-to-socket host app, then use SCPISocketTransport to connect to that host
<Degi>
I wonder if you add a second 50 ohm resistor to the output, whether the output voltage halves (in a voltage mode amplifier with a 50 ohm output, it would reduce to 0.666 of nominal)
<azonenberg>
Degi: i can experiment once i get the bias tee load working
<azonenberg>
i have zero visibility into what the actual probe tip amplifier module looks like as its all potted
<azonenberg>
all i can see is the power supply area
<Degi>
Hmh yes, the amp is in the potted tip...
<azonenberg>
Yep
<azonenberg>
anyway i'm off to get some sleep, the latest analysis run is 18% done with no errors
<Degi>
I guess you don't have random stuff laying around that might be usable for an x-ray image?
<Degi>
Good night!
<azonenberg>
and my boss is coming over tomorrow to drop off some hardware for $dayjob
<azonenberg>
and get a lab tour
<electronic_eel>
oh, so you need to clean up
<azonenberg>
Being asleep when he shows up is probably ill advised :p
<azonenberg>
electronic_eel: no i did the tidying up already lol
<azonenberg>
but he's coming in... something like 7 hours
<azonenberg>
so i should sleep between now and then
<electronic_eel>
yeah, so better get some sleep. have a good night!
juli966 has joined #scopehal
FFY00 has joined #scopehal
<azonenberg>
Bird|otherbox: cppcheck keeps proving its value
<azonenberg>
this latest round of fixes includes... two? memory leak fixes
<azonenberg>
as well as a potential crash in the spi flash protocol decode if you are looking at a x1 spi data stream and encounter a quad read command
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±15] https://git.io/JTCLC
<_whitenotifier-f>
[scopehal] azonenberg 43b611c - Lots of small fixes from cppcheck scans. Fixed two memory leaks, plus a potential segfault in SPIFlashDecoder if a quad read command is seen without a valid quad data stream.
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±6] https://git.io/JTCL8
<_whitenotifier-f>
[scopehal-apps] azonenberg 49268ff - Minor cleanup of issues found with static analysis. Suppressed some false positive warnings.
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JTCt6
<electronic_eel>
azonenberg: about the scophal interface to the el cheapo fx2 la. your plan is to write a separate program that talks usb to the fx2 and provides a ethernet socket for a scpi connection to scopehal, correct?
<electronic_eel>
so in this kind of configuration the interface between the two programs is completely in your hand. the question i have is if scpi is really the best way to do this
<electronic_eel>
how about something with a split control and data channel instead? something scpi like to control the interface and raw data on another socket
<azonenberg>
electronic_eel: That had been the plan all along
<azonenberg>
use this as a trial for the "scpi control plane plus push-based data" protocol i want to use for maxwell
<azonenberg>
with any luck i can use the same driver for both
<azonenberg>
or at least very similar code
<azonenberg>
scpi is pretty industry standard so it makes sense to use for control plane where performance isnt critical. It's just dumb to put data in the same stream
<electronic_eel>
exactly my thought
<azonenberg>
sorry if i wasn't clear earlier. But yes, that was the intention
<electronic_eel>
no worries, that is why I'm asking
<azonenberg>
Shorter term i have a few other priorities
<azonenberg>
Finishing up adding support for all of the trigger types (or as many as i can) on the tek mso6 before the guy wants it back
<azonenberg>
maybe adding function generator support
<electronic_eel>
in which direction do you want to open the connection? I'd prefer from scopehal, with a predefined list of port nos on the usb-bridge. to allow for easy ssh tunneling
<azonenberg>
Yes. scopehal initiates all connections
<azonenberg>
the tcp stack i will be using for maxwell doesnt even have client support
<azonenberg>
it can't send a SYN
<azonenberg>
but once the connection is open, triggers will be push based
<azonenberg>
you subscribe to waveforms on the scpi interface then eac htrigger you get a header with timestamp and length info then a blob of data
<azonenberg>
The other big thing i'm busy with right now is static analysis cleanup
<electronic_eel>
ok. for the fx2 thing it will probably be a constant stream. but splitting it into virtual blocks shouldn't be an issue
<azonenberg>
My plan is to support a 'dummy' trigger mode for continuous streaming mode
<azonenberg>
but logically it will be triggered
<azonenberg>
and i will also support downloading trgger commands to the server
<azonenberg>
so i can experiment with e.g. a software i2c trigger
<electronic_eel>
you mean send a complex trigger command to MAXWELL?
<electronic_eel>
maybe built out of logic primitives you prepared for such stuff in the gateware?
<azonenberg>
Did you not see the design i came up with for maxwell's trigger arch?
<azonenberg>
i havent figured out the details yet but the first stage is pretty worked out and even tested in sim / compiled and verified for timing iirc
<electronic_eel>
either I didn't see it or I forgot it
<azonenberg>
So the basic idea is, we have the 92 probe inputs (the serdes ones are special and for now wont be trigger capable
<azonenberg>
so we have a bunch of 92:1 muxes to select inputs to each trigger block
<azonenberg>
The first type of trigger block is a Serial Pattern Matching Engine or SPME for short
<azonenberg>
It takes in one channel as a reset/sync line, one as a clock, and one as data
<azonenberg>
clocks data into an 8, 16, or 32 bit register (there are gonna be a few of different widths)
<azonenberg>
each time a new word of data is available, it's compared to four constant values and a boolean match flag is generated
<electronic_eel>
can you provide a virtual clock line to it? like something out of a pll inside maxwell? to cover protocols that don't have a dedicated clock signal
<azonenberg>
the implementation is a little complicated as it has to be pipelined/unrolled, the input is running much faster than the SPME can clock so it has to take input from an ISERDES and handle 4 bits at once and output a 4-bit match position flag, etc
<azonenberg>
but thats the gist of it. And this isn't the only primitive i plan to implement
<azonenberg>
this is targeting spi-esque protocols
<azonenberg>
clock can be rising, falling, or double rate and reset polarity is programmable too
<azonenberg>
Second type is the Parallel Pattern Matching Engine or PPME, which takes in 8 bits of data, a clock, and compares to a couple of 8-bit constants
<azonenberg>
there will eventually be some other types too, details TBD
<azonenberg>
all of the comparison targets are ternary so you can have 1, 0, or dontcare
<azonenberg>
all of the match flags feed into a not-yet-designed state machine block
<azonenberg>
Which ultimately outputs a trigger pulse
<electronic_eel>
too bad that yosys/nextpnr don't properly work for xilinx yet, otherwise you could just create the direct gateware for the trigger on the fly
<azonenberg>
PR is still going to be a big issue though
<azonenberg>
i dont want to burn an entire clock region on it
<azonenberg>
you have granularity issues with PR on xilinx arches
<azonenberg>
So my plan is to create a coarse grained architecture specifically for triggering that has programmability at particular blocks
<azonenberg>
I expect that as an optimization at some point, various parts of these matching blocks will take advantage of programmable LUTs
<azonenberg>
you can use a xilinx SRL32 as a 5-bit programmable lut and load contents on the fly through the shift register
<electronic_eel>
right. if PR were the only issue, you could use a separate fpga just for the triggers and completely reconfigure it
<azonenberg>
connectivity is static of course, but this can give you significant gains in logic density vs having a lut based comparator
<azonenberg>
eh, no
<azonenberg>
the bandwidth between the chips would need to be absurdly high. on the order of half a Tbps
<azonenberg>
it wouldnt be practical to split
<electronic_eel>
just double the input signals to both fpgas?
<azonenberg>
you do realize you're talking almost a hundred LVDS pairs right?
<azonenberg>
and either active buffers or RF splitters plus 6 dB of insertion loss for each one?
<electronic_eel>
hmm, yeah. makes the board much more complex
<azonenberg>
Like i said there were significant engineering considerations :)
<electronic_eel>
is a theoretical thing anyway, as an open toolchain is still some way out and i don't know how fast it will be for xilinx
<electronic_eel>
for ice40 and ecp5 it is really fast, so you wouldn't have any issues creating the gateware live. but the xilinx you have are much bigger & more complex devices
<electronic_eel>
and you wouldn't want to wait half an hour until your trigger is synthezised...
<azonenberg>
I was about to bring that up as the other issue
<azonenberg>
So my plan is to create a "virtualized FPGA" specifically designed for triggering
<azonenberg>
kinda like a greenpak
<azonenberg>
where you have a bunch of coarse grained IP blocks specialized to your problem, some LUTs to glue it together, and a state machine block
<electronic_eel>
I hope it will be a bit beefier than a greenpack though ;)
<azonenberg>
Lol yes
<azonenberg>
i'm targeting 4 or 8 bit datapaths per channel (deserialized) at 312.5 MHz for the trigger path
<azonenberg>
so 1.25 or 2.5 Gsps
<azonenberg>
meanwhile the capture-to-memory path will hopefully be able to run at 5 Gsps, 312.5 MHz @ 16 bits, if i can get a RLE compressor to run that fast
<azonenberg>
the ISERDES can do it, it's a question of if the FPGA can process the data fast enough in order to shoehorn ~0.5 Tbps of raw sample data - plus address/refresh overhead - into ~100 Gbps of DDR write bandwidth
<azonenberg>
even at 1.25 Gsps compression is a must if all channels are active
<electronic_eel>
problem with compression is that the data can get larger than the original, e.g. if you have a clock that toggles every other cycle and you use pure RLE on it
<azonenberg>
Correct
<azonenberg>
There's a couple of things I'm going to do about that
<azonenberg>
the first is, although i am sampling the input at 5 Gsps the max specified toggle rate will be 1.25 Gbps. That's the fastest data i could realistically oversample and do CDR on
<azonenberg>
Anything faster is undefined behavior
<electronic_eel>
;)
<azonenberg>
Second, the RLE isn't going straight into the DDR
<azonenberg>
The plan is to have samples coming off the ISERDES, maybe a tiny LUTRAM FIFO, then into the RLE engine, then into a block RAM based FIFO per channel or small group of 2/4/8 channels, exact architecture TBD
<azonenberg>
then the write logic will pull samples out of those FIFOs and shuffle them into DRAM
<azonenberg>
More-full FIFOs will be prioritized
<azonenberg>
The BRAM FIFOs are intended to cover both refresh cycles and bursts of poorly compressing data
<azonenberg>
And the assumption is that even if some channels like clocks compress poorly, others like enable/reset lines will compress extremely well
<electronic_eel>
ok, so you can survive a short burst on one channel without data loss
<azonenberg>
Not just one channel, i intend to allow you to sustain worst case overhead on some specified fraction of the channels without exceeding available bandwidth
<azonenberg>
But if you feed a 1.25 Gbps PRBS-31 into all 92 channels at once, yes you will run out of buffer space
<electronic_eel>
maybe have some logic detect that one channel compresses badly and switch off compression for some time?
<azonenberg>
the plan is not to *lose* data per se, if the fifos fill up it will simply stop the acquisition
<azonenberg>
your waveform will be truncated but everything up to that point will be correct
<azonenberg>
but again the intent is to make it so that the bandwidth from any one fifo to dram is adequate to sustain worst case expansion of the RLE
<azonenberg>
the only way you can run into problems is if you have more than say 2/3 of the channels active and they all compress badly
<azonenberg>
I think that's an extremely improbable scenario, although i will document it as a possibility
<azonenberg>
and you can still use the LA in that case, you're just limited to the block ram buffer capacity
<azonenberg>
since the BRAM does have the bandwidth to sustain the full sample rate
<electronic_eel>
I'm sure other LAs on the market have similar restrictions, maybe not documented that explicit though
<azonenberg>
Yes, i know at least one Tek that says you can only use full sample rate on half the channels
<azonenberg>
they likely do not compress to RAM so the bandwidth limit is an on/off deal
<azonenberg>
in my case i'm compressing the ram so it's data pattern dependent
<azonenberg>
although there are going to be channel count/sample rate conditions below which i can say yes, for all possible data you have enough bandwidth
<azonenberg>
above there it's pattern dependent
<electronic_eel>
will be fun to develop all this. do you have some pattern generator that can do 92 channels at once at these speeds?
<azonenberg>
Nope :)
<azonenberg>
Gonna rely heavily on sim for it i suspect
<azonenberg>
so far i have the SPME and PPME mostly tested in sim but none of the rest
<electronic_eel>
the curse of building your own test gear
<azonenberg>
i fully expect maxwell firmware dev to be a 6+ month project
<azonenberg>
the 40G capable TCP offload engine will probably be at least a month by itself
<azonenberg>
my current 1G one (that didn't quite fully get finished, it worked for IP and UDP but i never did TCP retransmits etc) needs a complete rewrite with deeper pipelines and a 128 bit datapath
<electronic_eel>
retransmit buffers capable of 40G will be fun
<electronic_eel>
will they go into DDR or BRAM?
<electronic_eel>
or do you recompute the packets?
<azonenberg>
I will definitely use the DDR for that in this board. but the plan is to have an abstract "transmit buffer interface" that hides the details of this
<azonenberg>
My plan is to optimize for the common case of no packet loss
<azonenberg>
as long as i can recover from a dropped packet it's OK if it's slow
<electronic_eel>
yeah, i think that makes sense. but having to copy over the packet to DDR will break the burst needed for reading/writing sample data
<azonenberg>
Correct. My plan is actually to do things a bit differently
<azonenberg>
i won't be copying the packet to ddr
<azonenberg>
I'm going to pull data out of ddr, generate a tcp segment around it, send that out to the wire
<azonenberg>
and then hopefully just mark that buffer as free once i get the ack
<azonenberg>
so with any luck a given chunk of waveform data is written once and read once
<electronic_eel>
ok, that is what i meant with "recompute the packets"
<azonenberg>
The read will use bandwidth that competes with waveform capture, but i don't see a way around that
<azonenberg>
not unless i moved to QDR-II+ but that would come at a huge cost in buffer capacity
<azonenberg>
the "proper" solution would be multi-channel DDR but that means a bigger fpga with more pins and more pcb layers
<electronic_eel>
is QDR-II+ some kind of dual port ram?
<azonenberg>
More importantly, it would mean a bigger fpga not supported by webpack ,or moving to ultrascale
<azonenberg>
both would be a multi thousand dollar increase in project budget
<azonenberg>
QDR-II+ is true dual port SRAM, yes. DDR bus on both read and write ports, generally 36 bits wide
<azonenberg>
one single rate address bus taking turns issuing bursts of 4 words to the read and write port
<azonenberg>
i plan to use it on the ethernet switch as a packet buffer
<azonenberg>
but you're talking $1 or more per MB of buffer
<electronic_eel>
but SRAM sounds like you don't get the sizes/density you are used to with DRAM
<azonenberg>
Correct. for MAXWELL density was more important. I figure MOST of the time, i won't be using all 96 channels and if i am, it's likely not going to be all with super fast signals
<azonenberg>
ultimately i started with the width of a 19" chassis and the pin count of an xc7k160t and shoved as much as i could in it
<azonenberg>
and i get whatever performance i get
<electronic_eel>
32 GByte at $1 per MB...
<azonenberg>
the 160t is a sweet spot for price/performance that made sense to target here. same reason i'm using it in the switch
<azonenberg>
lain, Kliment, electronic_eel: so i just re-tested the ZS1500 with the 50 ohm DC loading on th ebias tee
<azonenberg>
it performed slightly better, -3 dB at 1.21 GHz vs 1.07
<electronic_eel>
now you just need to find a magic bullet to use as gnd wire to get it up to 1.5...
<azonenberg>
lolol
<azonenberg>
well, no - i tested it under realistic conditions
<azonenberg>
this is how it would be used with the scope
<azonenberg>
i'm gonna quote performance as i see it, if someone has problems with my methodology i'm publishing photos of the test setup and the measured s-parameters
<azonenberg>
so i welcome anyone pointing out flaws :p
<electronic_eel>
so you don't put a probe into a custom designed fixture holding it directly on your siggen to use it in the field?
<azonenberg>
lol
<electronic_eel>
jokes aside, I think using the gnd leaf is the right way to get realistic results
<azonenberg>
more to the point, i'm testing these commercial probes on the same fixture, using the same test methodology, as I evaluate the AKL-PT1
<electronic_eel>
do you want to put these pictures in the review article? I'd remove the one unused red clip cable
<azonenberg>
I can't, they're taped together in pairs
<azonenberg>
that's the other half of that channel but it's jumpered at the PSU to put them in series with a virtual ground
<electronic_eel>
don't you have single cables?
<azonenberg>
i mean i could have untaped it
<azonenberg>
but no
<azonenberg>
all of my power cables are taped together in color-coded pairs
<azonenberg>
so i can tell which psu channel they're on
<electronic_eel>
I often need pairs, but also singles are often needed to wire in a current meter or something
<azonenberg>
no that's quite rare for me
<azonenberg>
since i have 0.1 mA resolution in the current readback on the psu itself
<azonenberg>
this is a rohde & schwarz psu, not a cheap ebay one :p
<electronic_eel>
yeah, my psu has 0.1mA too, this is really handy
<electronic_eel>
wouldn't want a psu without it now that I'm used to it
<azonenberg>
Yeah
<azonenberg>
i mean it's also a $1200 psu
<azonenberg>
but it's SUPER nice. has features i've never even used yet
<electronic_eel>
mine is a TTI, a bit cheaper than that
<azonenberg>
like the ability to program custom i/v curves
<electronic_eel>
I think mine can do that too, but I never used it too
<azonenberg>
one that i use all the time is overcurrent shutdown
<azonenberg>
it supports constant current mode of course, but with non-ohmic loads like SMPSes it makes more sense to shut down if they go over the limit
<azonenberg>
you can even program in an inrush period where it current limits
<azonenberg>
then shuts down if it goes over the limit after that
<electronic_eel>
yeah, the OCP is quite nice. mine doesn't have the inrush thing, so you have to go a bit beyond the final current draw
<azonenberg>
mine will also log CSV to a front panel thumbdrive
<azonenberg>
not something i use super often but its convenient at time
<azonenberg>
times*
<electronic_eel>
in the future this is something I hope to get from scopehal for mine
<azonenberg>
scopehal already has support for my R&S PSUs in the library
<azonenberg>
there just isnt a proper ui yet
<azonenberg>
there's the psuclient app in scopehal-apps but its incomplete
<azonenberg>
if somebody wants to give it some love, it will be more than welcome. i think that makes sense to be separate from glscopeclient
<electronic_eel>
they have lxi and the scpi is well documented, so a driver shouldn't be that much of an issue
<electronic_eel>
but I think I should take a look at adding support for my rigol first
<electronic_eel>
but I'll also need to do some firmware work for the next revision of Glasgow
<miek>
which tti do you have?
<electronic_eel>
we added current measurement, but don't have support for the new ic in the firmware yet
<electronic_eel>
miek: QL564P
<electronic_eel>
there are two generations of these available, the older ones just have usb and gpib, the newer ones also ethernet
<electronic_eel>
so if you buy these on ebay, make sure you get a newer one or a deep discount
<miek>
ah nice. i've got the same but without the remote control unfortunately
<electronic_eel>
the control board is the same for both, there is just an extra comms board for the P version
<electronic_eel>
maybe you could take a look at the internal interface and hack together your own comms board?
<electronic_eel>
they are built nicely modular internally, so I think this should be possible
<miek>
yeah, that would be cool. if you ever get a chance to tear yours down, please send photos :)
<electronic_eel>
do you have the service manual?
<electronic_eel>
I asked nicely at TTI and they sent it to me
<electronic_eel>
there are board layout graphics in them IIRC
<miek>
i do not
<miek>
ah, looks like it's on xdevs
<miek>
oh cool, it just speaks serial to the main pcb
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JTCMW
<_whitenotifier-f>
[scopehal] azonenberg 0a7e15d - Minor cleanup to BytesToFrames()
<azonenberg>
ok, data acquired, time to write the review of the zs1500 now
<miek>
if you haven't already, it would be interesting to compare the vna s21 sweep to a sweep terminated into the scope
<azonenberg>
what do you mean "a sweep terminated into the scope"
<azonenberg>
i can do s11 easily enough
<azonenberg>
s21 needs access to both ends of the probe
<miek>
using the probe as normal with a scope, and recording amplitude vs frequency
<azonenberg>
Oh
<miek>
i'd be curious to see if it agrees with the VNA setup as a sanity check, or maybe to see if the scope does some de-embedding
<azonenberg>
yeah i might do that at some point. i was planning to do that with the wavelink probe since that is not something i'm willing to crack open
<azonenberg>
and i know for a fact they do some de-embedding there
<azonenberg>
whether its full s-parameters or just attenuation vs frequency i dont know