<sajattack[m]>
Guess I should pay more attention/check that out
<azonenberg>
sajattack[m]: go for it, let me know if you have any issues
<azonenberg>
i have a sds2000x+ demo scope on my bench now that i've been too busy to touch the last few days but over the weekend i plan to implement the function generator and bang out the remaining trigger types
<azonenberg>
then i can send it back and get a different siglent model to play wtih
<sajattack[m]>
How does all this work? Does it just send scpi commands over ethernet?
<azonenberg>
It sends scpi commands over any supported transport
<azonenberg>
right now TCP/IP over ethernet is supported on all platforms, as well as USBTMC on Linux
<azonenberg>
there is currently no USBTMC support for Windows
<azonenberg>
it also can do RS232 although that is obviously slow, i think linux only?
<sajattack[m]>
Oh usb might be easier for me
<sajattack[m]>
Otherwise I'd need an ethernet switch in my bedroom I think
<azonenberg>
and there has been talk of adding old school gpib
<sajattack[m]>
Or unplug my thin client
<azonenberg>
but i dont think anyone has written the driver for that yet
<azonenberg>
as far as ethernet goes, we can use any of three possible transports there
<azonenberg>
raw scpi over tcp with no other encapsulation
<azonenberg>
LXI VXI-11
<azonenberg>
or the LeCroy Virtual Instrument Control Protocol (VICP)
<azonenberg>
check the manual, most instrments only support a subset of those 3 protocols
<d1b2>
<sajattack> cool
<azonenberg>
and finally there is the "twinlan" protocol, supported mostly by our own bridge servers but also by the [redacted] VNA firmware under development
<azonenberg>
twinlan transport*
<azonenberg>
which uses one socket to send raw scpi commands for configuration, and a second to move driver-specific raw sample data
<azonenberg>
(so you don't have to do string parsing on all of the sample content or have the data socket blocked when doing control transactions)
<d1b2>
<Darius> that sounds moderately sane
<d1b2>
<Darius> no wonder it doesn't exist in a test instrument 😄
<sajattack[m]>
looks like the aur package is broken
<azonenberg>
@darius: one vendor is working with us to implement it
<azonenberg>
sajattack[m]: interesting
<azonenberg>
AFAIK whoever set it up just makes it pull latest from git
<azonenberg>
sure your'e not just missing dependencies?
<sajattack[m]>
one of the dependencies won't compile, and also the git link in the pkgbuild isn't set to https, and github doesn't allow legacy git anymore
<azonenberg>
if you want to send a PR that fills in the list of valid sample rates (you might have to tinker a bit in the scope UI to figure out what the legal rates are)
<azonenberg>
it will be appreciated
<sajattack[m]>
cool
<azonenberg>
return value is a vector of sample rates in Hz sorted from lowest to highest
<azonenberg>
so yeah when mandl added sds1000 support to the driver that never got implemented
<azonenberg>
oops
<sajattack[m]>
it looks like adjusting the horizontal on the scope will tell me that
<azonenberg>
Yeah
<azonenberg>
There's just no way to query the valid set of rates via SCPI commands
<azonenberg>
(this is true for most scope families)
<azonenberg>
So someone has to actually look at the gui and enumerate them all manually
<azonenberg>
So in PushTrigger() it seems like everything is fine if it's not an edge trigger, it just prints "unknown trigger type"
<azonenberg>
PushEdgeTrigger() should not be called for anything that isn't an edge trigger
<azonenberg>
The code there to send the commands looks a bit funky though
<azonenberg>
rather than getting the index and printing as a number
<azonenberg>
this is what GetHwname() on the channel is for
<azonenberg>
the hardware name of the channel is supposed to be the name that the scpi api expects
<azonenberg>
such that you can just shove it into a command as a string without doing all of that messiness
<azonenberg>
e.g. to enable a channel in the LeCroy driver, I do m_transport->SendCommand(chan->GetHwname() + ":TRACE ON");
<azonenberg>
I'd suggest rewriting the code to do that. and if it still crashes do a bit more digging to see what trig->GetInput().m_channel is actually returning
<azonenberg>
also m_channel is a pointer not an array, so the [0] is funky too
<azonenberg>
it won't break anything, m_channel[0].GetIndex() and m_channel->GetIndex() compile to the same code
<azonenberg>
but it looks weird and should probably be rewritten for clarity
<sajattack[m]>
I don't totally follow
<sajattack[m]>
should I enumerate the trigger types and let you go from there?
<sajattack[m]>
I get the part about the pointers
<sajattack[m]>
but not the correct way to rewrite all this code
<azonenberg>
sajattack[m]: ok so i cleaned the code up a bit and also added a null check
<azonenberg>
it should now no longer segfault, instead it will print an error message and return without doing anything
<azonenberg>
you will not have control over the trigger config, but it won't die
<sajattack[m]>
ok
<azonenberg>
now you can investigate to see how the input is getting to be null
<azonenberg>
trigger input 0 should be whatever channel you have selected as trigger source
<azonenberg>
if it's not, PullTrigger() or one of the functions it calls is likely broken somehow
<sajattack[m]>
caaaaan do
<sajattack[m]>
pull trigger only recognizes edge triggers
<sajattack[m]>
and I was set to a serial trigger
<azonenberg>
that should have given you a null trigger
<azonenberg>
on line 2918
<azonenberg>
as well as an unknown trigger type warning
<azonenberg>
which in PushTrigger() should have put you in the error message on 3387 rather than in PushEdgeTrigger()
<sajattack[m]>
ok
<azonenberg>
that is the intended code path if the instrument returns a trigger the driver doesn't support
<azonenberg>
if something else happened, that's the bug
<sajattack[m]>
I got your warning now
<azonenberg>
yeah so that confirms the trigger is non-null, but has a null input
<azonenberg>
which shouldn't be happening
<azonenberg>
you should either have a fully null trigger indicating unsupported
<azonenberg>
or a valid trigger with valid inputs
<sajattack[m]>
so I can set up another edge trigger if an edge trigger is currently selected, but if a serial trigger is currently selected (on the scope itself), I get a crash when changing to an edge trigger
<sajattack[m]>
or something like that
<azonenberg>
yep, bug somewhere in PullTrigger
<azonenberg>
you're gonna have to investigate that on your own because i have no way to reproduce without a SDS1000
<azonenberg>
if you really get stuck i can ask siglent to send me a dev scope
<azonenberg>
but i will have to send back the 2000 series i have now to do that
<azonenberg>
i don't have bench space for too many dev scopes at once
<azonenberg>
(and they probably dont want me holding onto toooo much hardware)
<azonenberg>
so i was planning to finish up with the 2000 before i got another
<sajattack[m]>
haha
<sajattack[m]>
yeah it stopped reproducing suddenly
<azonenberg>
even more fun
<sajattack[m]>
ok so the first time I pick trigger type edge it gives the warning
<sajattack[m]>
and the next time it gives me more options and doesn't
<azonenberg>
yeah that "no input selected" is probably your problem
<azonenberg>
the gui is going through the list of inputs
<azonenberg>
and none of them match
<azonenberg>
because the input is null
<azonenberg>
so it shows nothing
bvernoux has joined #scopehal
GenTooMan has quit [Ping timeout: 250 seconds]
GenTooMan has joined #scopehal
<bvernoux>
azonenberg, Amazing your FPGA board but the power consumption is really crazy
<azonenberg>
bvernoux: i have 128 bit data buses at 325 MHz inside it
<azonenberg>
it's probably a pretty good power virus :P
<azonenberg>
in fact, i even have some stuff at 625 MHz
<bvernoux>
And your FPGA is maybe quite old like 65nm techno ?
<azonenberg>
(all hand placed with RLOCs)
<azonenberg>
28nm
<azonenberg>
xc7k70t-2fbg484c
<bvernoux>
28nm is really not bad
<azonenberg>
note that the power consumption i'm reporting is the entire system
<azonenberg>
not just the FPGA
<bvernoux>
It is strange it consume so much for recent FPGA at 28nm
<azonenberg>
this includes the ~3W burned in the probe pod for example (those SiGe comparators are power hungry)
<bvernoux>
You have only LDO or you have also some DC/DC converter ?
<azonenberg>
as well as the 64 bit DDR3 bus
<azonenberg>
All DC-DC
<bvernoux>
Yes but I was not thinking DDR3 bus will consume so much too
<azonenberg>
expecting around 90% efficiency for 12V -> 1.0V VCCINT and 12V -> 5V intermediate bus
<azonenberg>
i don't have numbers for 5V -> {3.3, 1.8, 1.35, 1.2}
<bvernoux>
Yes so the power is not wasted in the DC/DC converter and you cannot really optimize that
<azonenberg>
that's a LTC3374A though, i can check datasheet
<azonenberg>
i found a significant increase in power when i enabled each serdes channel
<azonenberg>
as well as when i created the ddr3 controller
<bvernoux>
Best case DC/DC converter have 95% efficiency so 5% will do not change a lot
<azonenberg>
and more when i started actually writing a lot of stuff to the ddr
<bvernoux>
the ddr3 controller is an hard IP ?
<azonenberg>
xilinx MIG. soft controller with some hard PHY logic
<azonenberg>
note that this is a whole sodimm not a single chip
<azonenberg>
that's a lot of SSTL_135
<azonenberg>
about 300 mA of that ~900 mA at 12V is going straight to the probe pod
<azonenberg>
the rest is going into the FPGA board
<bvernoux>
So it is strange it consume so much even if it is not LPDDR3 I will not imagine DDR3 consume more than 2W
<azonenberg>
It's DDR3L
<azonenberg>
so 1.35V not 1.5
<azonenberg>
there is a 10G SFP+ interface, probably close to a watt being burned in the optic itself and more in the fpga serdes driving it
<azonenberg>
then a decent bit in the 1G baseT interface as well
<azonenberg>
not a ton, but noticeably warm
<bvernoux>
SO 0.3A x 12V about 3.6V for the DDR3L only ?
<bvernoux>
3.6W
<azonenberg>
and no, 0.3A to the 8-bit active probe pod
<azonenberg>
(well one of two, but only one is plugged in right now)
<azonenberg>
i have not yet brought up the SATA interface. so that's two more 6 Gbps SERDES lanes, and more dram b/w, still to come
<bvernoux>
Yes I hope the DC/DC converter can provide enough power on all rails for all and also the FPGA will do not burn
<azonenberg>
The FPGA die temp is only 50C or so, i have another 35C of headroom. and i can always swap the fan out for a bigger one if i need more airflow over the heatsink
<bvernoux>
But it is a very powerful board anyway
<azonenberg>
i am concerned about power consumption especially on the 1.0V VCCINT/MGTAVCCINT rail
<azonenberg>
i only have 4A provisioned for that rail
<azonenberg>
and while i don't know the exact breakdown of power internally, i'm definitely eating more than i budgeted
<bvernoux>
glurps the
<bvernoux>
XC7K325T-L2FBG900E
<bvernoux>
cost is >2Keuros
<azonenberg>
my design was very conservative and i have at least an amp of extra capacity on that rail
<azonenberg>
but i might be dipping into it
<azonenberg>
(my worst case design target was 2.85A and i'm very likely in that ballpark... DCDC is rated for 4A)
<bvernoux>
It is definitely not a cheap board ;)
<azonenberg>
and i'm using a 70t
<azonenberg>
not a 325
<azonenberg>
it's only 200 USD ish
<bvernoux>
Ha ok 200USD is not bad in that case
<azonenberg>
I do not plan to ever use a 325T in a design
<bvernoux>
The PCB is probably more expensive ;)
<azonenberg>
the 70 and 160 are supported by free vivado
<azonenberg>
325 is not
<azonenberg>
and the smallest kintex ultrascale/ultrascale+ are bigger and faster than the 7k325t and cheaper (in the 1k USD range)
<bvernoux>
But 70t will be maybe too small to have all things you want ?
<azonenberg>
That is very much a concern for this design. i'm around 40% full right now on LUTs and 50% on BRAM
<azonenberg>
and i have a lot more stuff to pack into it
<azonenberg>
The PCB was around $1600 in china for 5 units
<bvernoux>
The PCB have impedance checks included ?
<azonenberg>
8 layers, controlled impedance, roughly 150 x 125 mm, Taiwan Union TU872 (FR408HR equivalent)
<bvernoux>
ha great
<bvernoux>
Could you show the impedance report I'm very interested to see what they check and obtained values vs expected for different impedance SerDes ...
<azonenberg>
and this is a 10.3125 Gbps PRBS out the SMAs on the left side of the board
<azonenberg>
(with cable loss de-embedded to the SMA mating plane)
<azonenberg>
no emphasis at the driver so you can see just the slightest bit of vertical eye closure
<bvernoux>
they eye is very nice
<azonenberg>
at some point i'll tweak that
<bvernoux>
Yes on top right there is something strange
<azonenberg>
what you're seeing is the fast toggles not *quite* hitting full amplitude
<azonenberg>
just the beginnings of 1/f loss in the channel
<azonenberg>
this is about 77mm of pcb trace plus a pair of vias
<bvernoux>
Jitter seems quite good too
<azonenberg>
plenty of margin, i actually had to turn the drive strength *down* to avoid overdriving the max amplitude spec for XFI
<azonenberg>
i was hitting the outer limits of the mask lol
<bvernoux>
You have a TCXO for the main clocks ?
<azonenberg>
(with the serdes configured with default drive)
<azonenberg>
SiLabs MEMS actually iirc
<bvernoux>
On my design which is intended to be as cheap and easy to use with 2.54mm dual row connectors
<azonenberg>
let's see, that serdes is using the 156.25 MHz refclk
<bvernoux>
there is some degradation on signal/IO at 120MHz with such connectors
<azonenberg>
ECX2-LMV-7CN-156.250-TR
<azonenberg>
so no, standard quartz
<azonenberg>
the 200 MHz is mems i think
<azonenberg>
but designed for very low jitter
<bvernoux>
ha yes very good a +/-25ppm Crystal
<azonenberg>
max 60 fs 12 kHz - 20 MHz
<bvernoux>
but it is very low jitter
<bvernoux>
the +/-25ppm does not really count if you have an environment which have very stable temperature
<azonenberg>
-82.6 dBc/Hz typical at 10 Hz
<azonenberg>
-111.1 @ 100 Hz
<bvernoux>
ha yes veyr good
<azonenberg>
typical RMS jitter 46.8 fs
<azonenberg>
so yeah, it easily handles 10GbE jitter tolerances
<bvernoux>
It is also quite cheap
<azonenberg>
absolute stability was less important for me than jitter
<bvernoux>
Yes the jitter spec is very good
<bvernoux>
I suspect you have an option for external 10MHz Ref too like a GPSDO ...
<azonenberg>
on what, my scope?
<bvernoux>
on the board
<azonenberg>
No. I didn't see the point for the intended use case
<azonenberg>
there is a LVDS expansion connector that i could plausibly put a refclk into
<azonenberg>
but there's no dedicated input connector
<bvernoux>
but yes in that case on the scope it is important too if you want to integrate on during long measurements to gain accuracy ...
<azonenberg>
I have a cheap leo bodnar GPSDO but plan to get a nicer one
<azonenberg>
Stanford Research FS752 is on the shopping list
<bvernoux>
ha yes will be interesting to compare both ;)
<bvernoux>
I have Leo Bodnard ones too and it is very good
<bvernoux>
Jitter shall be better on FS752 but I imagine the price is a lot more
<azonenberg>
yeah i specifically wanted low jitter + distribution amplifiers. and rack mountable is nice
<bvernoux>
@azonenberg, does your board have option to sniff more than 32bits bus (with CLK ...) ?
<bvernoux>
Mainly ultra fast LA use case
<azonenberg>
No. Oversampling only, 16 bits across two 8-bit probe pods
<azonenberg>
5 Gsps
<azonenberg>
This board is primarily a SATA sniffer, I threw the LA on as a bonus
<azonenberg>
And based on my findings, I may want to make some changes to MAXWELL (the full 96 channel LA)
<azonenberg>
for example, even if i "only" run the inputs at 1.25 Gsps, DDR B/W will be a major concern
<azonenberg>
i also need to provision for a larger heatsink
<azonenberg>
with mounting brackets or something
<azonenberg>
This board is basically two purposes - sata sniffer, and technology demonstrator / testbed for MAXWELL
<azonenberg>
with two rather than twelve probe pods
<azonenberg>
DDR bandwidth will be a major issue in MAXWELL even if I run the LA inputs slower (plan was to only clock at 1.25 Gsps)
<azonenberg>
but i dont think i have the pins for an additional sodimm
<d1b2>
<louis> @azonenberg I am cleaning up a number of things in the Tek driver, since it may actually get some first-order use at work here soon
<d1b2>
<louis> a) I think I've fixed the instability in very long captures, now happily taking 50M+ point captures 🙂
<d1b2>
<louis> b) Fixing this has exacerbated locking issues in the UI.... if AcquireData can be sitting there transferring data for 750ms+ it will lock up the UI real good (3s+) when we try to do something like open the timebase window (and it needs to populate)
<d1b2>
<louis> c) There's some serious usability issues with the default behavior of showing all channels on a scope. We should think a little about how to deal with this. I think a good behaviour goal would be to make connecting glscope to a scope as nondestructive as possible of the scope's UI/settings. So instead of enabling and resetting everything, querying what is currently enabled and reflecting that in glscope.
<azonenberg>
Yeah that could work
<azonenberg>
i do agree defaulting to everything is bad
<azonenberg>
as far as locking issues, yes. one possible strategy there is to prefetch the list of valid timebases and such when initiating a session, and aggressively cache
<azonenberg>
as much as possible i try to avoid blocking api calls in the ui
<d1b2>
<louis> Pretty freakin' sweet to see this :). glscope's happy to eat the captures as fast as they come from the tek
<d1b2>
<louis> I've got patches here that do that (query the scope for what channels are enabled and show only those) for the Tek (as far as glscope, it's just querying ->IsChannelEnabled in OscWindow where we instantiate all the WaveformAreas
<azonenberg>
Yeah
<azonenberg>
That has been an ongoing pain point i've wnated to fix
<d1b2>
<louis> That's the behaviour that I think folks here want when they want to pick up glscope "in anger" 😛
<azonenberg>
just wasn't sure what the best UX was
<azonenberg>
in particular, consider headless scopes
<azonenberg>
that may not have a concept of "channels left active"
<azonenberg>
or in general, behavior if no channels are active
<d1b2>
<louis> It's not unreasonable IMO to default headless hw to all channels
<azonenberg>
if you have enough channels, it can be :p
<d1b2>
<louis> The pain point for me is connecting glscope to the Tek and having it nuke the way it was configured
<azonenberg>
defaulting to ch1 makes more sense IMO
<azonenberg>
if none are active
<d1b2>
<louis> Sure
<azonenberg>
and the other thing to consider is what happens when you disconnect
<d1b2>
<louis> With the enabled check in glscope that's as simple as having the driver init do that
<azonenberg>
glscopeclient maintains a list of enabled channels and does ref counting
<azonenberg>
so when you delete the last user of a channel it's disabled
<azonenberg>
but all refs are also freed upon exit
<azonenberg>
so it will try to close channels upon termination
<azonenberg>
we might want to change that behavior so the set of active channels is preserved among exit
<azonenberg>
note that you cannot simply add an extra ref to all channels active when you connect
<azonenberg>
because that makes it impossible to turn them off from glscopeclient
<azonenberg>
which you might want to do to interleave more BW on other channels etc
<d1b2>
<louis> Hm... that does make sense as a possible pain point, but interestingly that (closing channels when glscope closes) dosen't seem to work at the moment so it's not actually causing pain 😛
<azonenberg>
Lol
<azonenberg>
anyway, in general i support the idea, it definitely needs to be improved