<Degi>
omg, when the trigger is paused and I scroll the vertical axis on a scope trace rapidly, the rigol lags a few seconds behind
<Degi>
When I add a generated waveform it doesn't use the values I entered, instead I need to press escape, right click the info thingy and then escape again for it to update
<azonenberg>
ok, one issue at a time
<azonenberg>
as far as deferred commit of stuff like that, i like the general idea but the implementation would be tricky
<Degi>
So: timebase works
<Degi>
Hmmy eah
<azonenberg>
as there's no way to know when the scope has executed a command other than by sending a query to it
<azonenberg>
which adds (very slow) round trips
<azonenberg>
for the most part, the UI assumes the scope can execute simple set commands faster than you can move your mouse
<Degi>
I mean we could send the command after the user stopped changing the scale, so it only updates once instead of on every mouse scroll (on known slow scopes)
<azonenberg>
the failure modes you're seeing are what happens when a scope is stupidly slow
<azonenberg>
yes, that is a possibility
<azonenberg>
we'd have to update the cache live thoguh
<azonenberg>
because the display updates after each scroll wheel click
<Degi>
Hmm yeah
<azonenberg>
and the renderer reads the current scale from the cache
<azonenberg>
so you'd need to do deferred commit *in the driver*
<azonenberg>
not in the gui
<azonenberg>
and do so in way that doesn't break the headless ATE use case
<Degi>
Hmm I see
<Degi>
(I mean the just doing it in the driver might be okay, since then you can implement it only where it is necessary, though for the headless case that would add some complexity that it can be turned off or so maybe, probably not worth it)
<azonenberg>
exactly
<azonenberg>
in general i am not optimizing the ui or library core for hellishly slow hardware like rigol
<azonenberg>
if it works on them great
<azonenberg>
and i will accept PRs to make it work better as long as it doesn't break anything else
<azonenberg>
but my focus is on things that are fast enough to be useful in industry
<azonenberg>
as far as the context menu, same thing
<azonenberg>
it makes a bunch of blocking API calls to figure out channel coupling modes etc
<azonenberg>
until the cache is hot, they'll be slow
<azonenberg>
normally this is imperceptible
<azonenberg>
when the scope takes 500ms to tell you if it's ac or dc coupling a channel, though... :p
<Degi>
Even when I right clock on a generated sine channel?
<Degi>
(While oscilloscope channels are loaded but paused)
<azonenberg>
hmm, that should not be slow. but it's possible it's still hitting up the scope for some reason, i'd have to do some tracing to see why/how that is
<azonenberg>
as far as generated waveforms, we only recently switched the filter model from "filter is created when you click OK on filter dialog"
<azonenberg>
to things updating live as you edit fields
<azonenberg>
it's possible the sine generation filter is missing some update triggers. it's not the only one
<azonenberg>
ok yeah i can confirm that
<Degi>
Hmm, when I start a new instance of glscopeclient the context menu still takes about that long, maybe I can debug that tomorrow)
<Degi>
(Maybe it has to do with it using 72 % of a core in idle)
<Degi>
(If I keep right clicking it goes up to about 80-90 % but I can't see fast spikes in htop)
<Degi>
Interesting, the network menu of my scope has a QR code which redirects to some subpage of rigol.com which is a 404
<_whitenotifier>
[scopehal-docs] azonenberg 84a2118 - Added "internals" section discussing a bunch of glscopeclient and libscopehal internals. Need a lot more content, but a good start. Fixes #10.
<d1b2>
<Herr Brain> Q-strip will hopefully be in the KiCad official libraries at some point. I made those footprints.
<d1b2>
<azonenberg> (oh look i think the irc bridge is back)
<d1b2>
<arjenroodselaar> Any reason not to already feed the control signals through the ADC board and the Q-strip output?
<azonenberg>
Yes
<d1b2>
<Herr Brain> Like, all of them (at least the vertical variants)
<azonenberg>
Risk reduction for the prototype
<azonenberg>
The ADC board is going to be $$$$
<azonenberg>
the less tricky the mechanical fit is, the more likely we won't have to respin it during prototyping
<azonenberg>
i guess we could spin a dummy board with just connectors and do fit testing
<azonenberg>
basically i want to minimize the odds of making a board with a $1500 ADC that we have to scrap
<azonenberg>
So the less separate connectors we have to align mates of, the more reliable it will be
<d1b2>
<arjenroodselaar> Fair. I guess my risk tolerance has been stretched significantly over the past year 🙂
<azonenberg>
i don't have oxide's R&D budget to spend on respins lol
<azonenberg>
Anyway what i might do is have the SMPM directly connected for the RF, then have a short flex jumper with some little hirose square board to board connectors on either end
<d1b2>
<arjenroodselaar> Ha neither does Oxide 🙂 (time budget that is)
<azonenberg>
that we can use to get the i2c/spi/gpio between boards
<azonenberg>
the flex gives us margin to handle misalignments
<azonenberg>
and we can respin the flex if too long/short
<azonenberg>
i think that is acceptably low risk given how cheap oshpark flex is
<d1b2>
<arjenroodselaar> Sure, that'll work and will be less error prone than just some 100 mil headers/wires.
<azonenberg>
Yeah
<azonenberg>
Anyway, so then there will be a stm32 for management. I guess i'll put that on the FPGA board
<azonenberg>
originally i was thinking put it separately, to replicate the backplane board the real scope will have
<azonenberg>
but the real scope will use an ultrascale fpga anyway, budget permitting
<azonenberg>
so there's 0% chance of us reusing the prototype's fpga board in the final rev
<azonenberg>
(while the frontend and adc boards are intended to evolve into what we actually ship)
<d1b2>
<arjenroodselaar> Assuming the FPGA doesn't need the MCU is it worth considering a soft CPU? I don't know what you had in mind in terms of peripherals, trading engineering time vs. buying a couple $ part.
<azonenberg>
The MCU will be running a TCP/IP stack, we want a fair bit of SRAM
<azonenberg>
(for SCPI)
<d1b2>
<arjenroodselaar> Ah ok, in that case it's worth just getting something off the shelve.
<azonenberg>
Yeah. i have a bunch of stm32s sitting around
<azonenberg>
i will not be using ssh here so i don't need one with a crypto accelerator for the prototype
<azonenberg>
anyway, so I'm thinking about what board it makes sense to do first
<azonenberg>
the ADC board in isolation is pretty useless
<azonenberg>
so that's definitely last
<azonenberg>
The FPGA / MCU board we can bring up a lot of stuff wrt scpi and 10GbE on
<azonenberg>
get the ddr up and tested
<d1b2>
<arjenroodselaar> Yeah there's quite a bit of stuff to get working on that control board, so getting that done first probably makes sense.
<azonenberg>
and then spin a dummy board with the cheapest 8-bit jesd204 adc on digikey (I think it's like $75 or so)
<azonenberg>
and a fixed sinewave fed into it or something
<azonenberg>
just to bring up all of that
<azonenberg>
then the next i think should be the frontend
<azonenberg>
because the frontend can be VNA'd without an adc
<azonenberg>
or we can hook the outputs up to a scope etc
<azonenberg>
test everything before we hook it up to the adc
<d1b2>
<arjenroodselaar> Sounds like a reasonable plan. One variable at the time.
<azonenberg>
As far as parts go, I want to figure out key BOM items ASAP and get stuff ordered
<azonenberg>
even before we start the schematic
<azonenberg>
given the lead times
<d1b2>
<arjenroodselaar> Yeah we've had difficulty getting good PDN parts, even in lowish qty's.
<azonenberg>
as of now, in the bin of parts earmarked for ZENNECK prototyping, I have one XC7A200T-1FFG1156C
<azonenberg>
ten LMH6552s for the front end
<azonenberg>
ten BUF802s for the 1M ohm front end (originally for a high-z active probe, i plan to pursue that too)
<azonenberg>
and the single AD9213 you sent me
<azonenberg>
Additionally, in the bin of parts designated for the sata sniffer project, i have a tray of five DDR3 SODIMM sockets of which i only need one
<azonenberg>
so i've got four to spare, which is enough to build a dual channel test board and have some extras
<azonenberg>
(as in one scope channel, two memory channels)
<azonenberg>
The 7a200t needs 128mbit or larger spi flash to boot from
<d1b2>
<arjenroodselaar> I may have some.
<azonenberg>
I have ten S25FL128SAGBHIA10
<azonenberg>
just checked
<azonenberg>
(and worst case we can fall back on jtag boot in a pinch)
<azonenberg>
So we have the ddr sockets, i'm not worried about being able to buy laptop ddr3 - that's easy enough to source even now, we have the fpga, we have the flash, i have jtag connectors
<azonenberg>
i don't yet know what q-strip we will be using for the fpga - adc connection, IIRC I have a fair number of QTH-060 and QSH-060s
<azonenberg>
I have exactly one 1gbit magjack left and i need it for the sniffer part. Digikey is out of stock of the one i usually use but they have more expected to arrive very shortly
<azonenberg>
I have more in my digikey cart for now, we can worry about that later if needed
<azonenberg>
I do not have any sfp cages or connectors to spare so i have to source those
<azonenberg>
I have three KSZ9031RNX ethernet PHYs left, i need one for the sniffer so we have two to spare for this project
<azonenberg>
I already have 25 more on order but the estimated ship date is next Christmas
<azonenberg>
I also have plenty of TLK10232 XAUI -> XFI bridge chips (since the artix cannot do 10g itself)
<d1b2>
<arjenroodselaar> I think I have some 1G MagJacks. I ordered them for a prototype, but then a coworker ordered another batch so these can be used.
<azonenberg>
This PHY is picky about magjacks
<azonenberg>
it needs isolated center taps as the common mode of the drivers can change vs other channels IIRC
<azonenberg>
i normally use bel fuse 0826-1g1t-23-f
<azonenberg>
Digikey says they're out of stock but expect more Wednesday
<d1b2>
<arjenroodselaar> Yeah trying to find a PN for these, 1 sec.
<d1b2>
<arjenroodselaar> Oh nvm, these are 100M jacks without the isolated taps. Nope.
<azonenberg>
Digikey has my usual SFP+ cage in stock so that's good
<azonenberg>
and the connector
<azonenberg>
i'll grab 10 of each for later use
<azonenberg>
As far as the MCU goes, I have a couple of STM32F031s which are way too small
<azonenberg>
25 STM32L031s, also too small
<azonenberg>
one lone STM32H750 which is slight overkill and i want to preserve for something that actually needs the horsepower
<azonenberg>
a STM32L052 which is also a little small
<azonenberg>
And three STM32L081s which are 192 kB flash + 20 kB RAM
<azonenberg>
32 pin QFN is a little light, and no hardware ethernet. but if this is just for a simple SCPI interface i think i can make do
<azonenberg>
the 10G and 1G will terminate in the FPGA anyway
<azonenberg>
we can put a mac in the fpga, send the high speed data transfer to the hardware accelerated processing and then the tcp scpi sessions and low speed stuff like arp etc over spi to the mcu
<azonenberg>
I think i could make it work. we can keep the packet buffers small and put a fifo in the fpga if we need to
<azonenberg>
Not my first choice but it's a part i have in hand and that's worth a lot these days :p
<azonenberg>
so, i think that checks all the boxes other than power right? in terms of major components, forget about passives for now
<d1b2>
<arjenroodselaar> Sounds like it.
<azonenberg>
oh and i have ten W25Q128JVs in the sata sniffer parts bin
<azonenberg>
i only need on there
<azonenberg>
(going through that bin now, i ordered overages of stuff since the shortage was already in full swing)
<d1b2>
<arjenroodselaar> I haven't looked at all at what the Artix parts need for power.
<azonenberg>
I'm inventorying what i *have* for power first
<azonenberg>
ignoring all of the LDOs and low current stuff...
<azonenberg>
I have one PTH08080WAH, a 5V -> whatever 2.25A buck module
<azonenberg>
Four LTC3374A, a 5V -> whatever 8 channel buck IC
<azonenberg>
That one is really nice for smaller FPGA projects
<azonenberg>
four phases, 2 1A bucks on each phase for a total of 8
<azonenberg>
and you can parallel up to four of the eight to get up to 4A on a single rail
<azonenberg>
Additionally, I have in the sata sniffer bin five OKL-T/3-W12P-C, a 5/12V -> whatever 3A buck module
<azonenberg>
of which i only need one
<azonenberg>
ten more LTC3374As
<azonenberg>
and ten LP2996 DDR3 termination regulators
<azonenberg>
Let me spin up a quick spreadsheet and figure out power requirements here...
<azonenberg>
So, the TLK10232 needs 650 mA VDDD (1.0V), 650 mA VDDA (1.0V), 700 mA DVDD (1.0V), 600 mA VDDT (1.0V), 140 mA VDDR (1.5 or 1.8V, not sure when you'd use one or the other - have to read the datasheet more), and 10 mA VDDO (also 1.5/1.8V)
<azonenberg>
actual consumption will be less as it's a dual channel part and i will only be using one half
<azonenberg>
but i'll budget for worst case
<azonenberg>
Each of the two DDR3L SODIMMs needs 2A @ 1.35V + 0.6A @ Vtt
<azonenberg>
The SFP needs 300 mA @ 3.3V
<azonenberg>
The 1G PHY needs 250 mA @ 1.2V, 20 mA @ 1.8V, 70 mA @ 3.3V
<azonenberg>
flash is insignificant
<azonenberg>
FPGA depends heavily on how much we stuff in there
<d1b2>
<j4cbo> putting the MAC in the FPGA having a side channel over to the MCU for low-bandwidth stuff seems like it will make for a more elegant result anyway
<azonenberg>
j4cbo: I was going to do that anyway, but then have a RMII interface to a beefier MCU
<d1b2>
<j4cbo> ah, nod
<azonenberg>
the only thing changing architecturally is that i'm using a different bus there
<azonenberg>
So for the FPGA I'm going to estimate 70% logic utilization, 100% BRAM, 50% DSP (I dont think i will be doing much DSP on the FPGA but it's safer to assume more)
<azonenberg>
at 200 MHz for all of that
<azonenberg>
then dual ddr3 800 / ddr3l 667 (I'll assume worst case of 800 for now) memory channels, 64 bits wide each
<azonenberg>
and substantially no other high speed i/o other than the ddr and the serdes
<azonenberg>
...
<azonenberg>
ok sooo we have a problem
<azonenberg>
I misread the speed grade chart on the FPGA, I need a -2 speed to do the GTP rate I wanted. -1 maxes out at 3.75 Gbps
<azonenberg>
gaaaah
<azonenberg>
I can buy a -2 but it won't ship until *september*
<azonenberg>
and that is perhaps an optimistic estimate
<azonenberg>
I can still populate the board with the fpga i have now i guess, and do bringup with the adc underclocked
<azonenberg>
then make a second board when the faster fpga comes in for full speed testing
<azonenberg>
that might not be the end of the world
<azonenberg>
but gaaah i ordered this fpga like six months ago for this exact purpose
<azonenberg>
i could have ordered the right part and it would have been here
<d1b2>
<arjenroodselaar> Well that's a bummer.
<azonenberg>
Or i could just leave this fpga in storage, design the board
<azonenberg>
but not stuff it until the parts come in
<azonenberg>
and focus on other aspects of the project
<azonenberg>
(this was always planned to be a very long term project so that might not be TOO horrible?)
<azonenberg>
In any case... FPGA power estimate (rounding to be conservative) is 6A @ 1.0V VCCINT, 0.2A @ 1.0V VCCBRAM, 1.25A @ 1.8V VCCAUX, 1A @ 1.5V VCCO for DDR, 1.5A @ 1.0V MGTAVCC, 1.25A @ 1.2V MGTAVTT
<d1b2>
<arjenroodselaar> The other parts of the board are not that expensive I think? You can always populate one, get bringup started and then build another one once the -2 device has shipped.
<azonenberg>
Yes, that is very much an option
<azonenberg>
and it's not cost that is an issue
<azonenberg>
it's do i have enough of all the other parts to stuff 2 boards
<azonenberg>
or do i have to wait another six months for something
<azonenberg>
lol
<d1b2>
<arjenroodselaar> You'll have to put an actual BOM together anyway. With that spreadsheet in hand it should be quick to see which other items are long lead time and order those at the same time.
<d1b2>
<arjenroodselaar> Based on that you can make a decision on whether you want to build the -1 version board.
<d1b2>
<arjenroodselaar> But granted, anything not available now-ish could very well get pushed back in three months time.
<azonenberg>
Yeah
<azonenberg>
Ok so, if i split up the FPGA SERDES, the XAUI bridge, and the FPGA core onto separate 1.0V rails
<azonenberg>
and ignoring safety margins on top
<azonenberg>
We need 2.6A, 6.2A, 1.5V on three 1.0V rails
<azonenberg>
1.5A @ 1.2V
<azonenberg>
2.0, 2.0, 1.0A on three 1.5V rails
<azonenberg>
250 mA on a 1.5/1.8V rail TBD
<azonenberg>
1.5A at 1.8V, 0.4A + MCU power for 3.3
<d1b2>
<arjenroodselaar> It's not unreasonable to start with the other boards. Those all require significant work from you and the reality may be that I won't really have time for non-Oxide stuff until the end of the year.
<azonenberg>
and then 600 mA on each of two DDR3 termination regulators
<azonenberg>
the reason i'm splitting rails like this is to keep as much as i can below 4A per rail
<azonenberg>
which allows me to use the LTC3374s I have in stock for everything except the FPGA VCCINT rail which needs over 6A
<azonenberg>
so while i will need to order passives, the only power component i need to order is a single high current dc-dc for the fpga core rail
<azonenberg>
Assuming i run the board off 5V input which would pull a fair bit of current (if I do 12V I'd need a 12 -> 5V intermediate rail converter)
<azonenberg>
the other thing i'd need to consider is that i need to draw power off this board to run the ADC and frontend boards. so probably 12V in makes more sense, i can feed the unregulated 12V on to the ADC/AFE boards and regulate point of load there
<azonenberg>
Anyway, at this point i know for sure i need the RJ45 and the SFP cages/jacks
<azonenberg>
and the -2 FPGA
<azonenberg>
So i'm going to order those
<azonenberg>
Then probably spend some time the next few days thinking about what other power ICs I might need for this board to get those rails
<azonenberg>
order those
<azonenberg>
then shift focus to the frontend
<azonenberg>
source as many key parts as possible
<d1b2>
<arjenroodselaar> LTC3374 is a pretty neat device. That many channels usually comes with a requirement for PMBus, which is kind of a hassle on boards like this.
<azonenberg>
Yes. I love it, a lot of my smaller fpga boards use it as the sole pmic
<azonenberg>
i get core and io rails all off the one chip
<azonenberg>
midsized usually use a 3374 for everything but fpga core and a separate regulator for that
<azonenberg>
which is iirc what the sata sniffer does
<azonenberg>
At a quick glance, this board needs a ?? for 1V0_2
<azonenberg>
then i could pack say 1V0_1 @ 3A, 1V0_3 @ 2A, 1V2 @ 2A, 3V3 @ 1A into one LTC3374
<d1b2>
<arjenroodselaar> Yeah not bad. And having some extra channels means you can dedicate a few as a step down into an LDO and not worry about thermal performance.
<azonenberg>
which leaves 1V35_1 @ 2A, 1V35_2 @ 2A, 1V35_3 @ 1A (I might merge 3 and 2 TBD, but same total current), 1V8 @ 2A = 7 channels, so i could throw the extra one on one of the 1V35 rails to improve efficiency
<azonenberg>
actually wait, the ddr termination rail will need to come off 1.35 too
<d1b2>
<arjenroodselaar> We use LT3072's in a variety of roles, but they really shine as a secondary step for SerDes. The only catch is their requirement for an external 5V bias.
<azonenberg>
i didnt account for that so i might need one for just the 1.35, then a second chip for the 1V8
<azonenberg>
anyway, point is i think i can get by with 2-3 LTC3374s for everything but fpga core rail here
<azonenberg>
I like LT3042 / LT3093 for low noise analog rails, that's what my last scope frontend used
<azonenberg>
so far, my serdes rails have been straight off a SMPS with a bit of filtering
<azonenberg>
and it's seemed to work out OK. This eye is from a board i made in 2014 when i had no idea what i was doing, there's some big impedance mismatches at coupling caps and such
<azonenberg>
but jitter wise it looks quite decent
<d1b2>
<arjenroodselaar> So.. I should just cancel my XC7A200T-1?
<azonenberg>
this is feeding the serdes off the same ltc3374 output as the fpga core, in fact, through a simple pi filter
<azonenberg>
although the fpga is pretty empty
<azonenberg>
so it's not contributing much noise
<azonenberg>
i'm just using the prbs generator on the serdes ip and the bitstream is otherwise empty
<azonenberg>
and yes
<azonenberg>
i think that would be advisable
<d1b2>
<arjenroodselaar> Looking at XC7A200T-2 availability.. Mouser is claiming 58 weeks lead time. It may be worth it to shell out and get a -3 device.
<azonenberg>
Digikey is saying september
<azonenberg>
they might have some already inbound
<d1b2>
<arjenroodselaar> Ah that's not too bad then.
<azonenberg>
which is why i'm saying, table it and work on other parts of the project
<azonenberg>
and if we really get stuck i can stuff a board with my -1
<d1b2>
<arjenroodselaar> Sounds good.
<azonenberg>
realistically i think we will do a few iterations of the frontend
<azonenberg>
and between component sourcing issues and pcb fab delays, that will easily kill a few months
<azonenberg>
plus a month or so of engineering time on each board given how busy everyone is
<azonenberg>
(a month of calendar time that is)
<d1b2>
<arjenroodselaar> Yeah it's fall before you know it.
<azonenberg>
this is why the component shortage hasn't been such a huge issue for me lo
<azonenberg>
lol
<azonenberg>
my load average is probably in the triple digits
<azonenberg>
i'm so oversubscribed there's always something to context switch to, like a GPU
<azonenberg>
so if i table one project for six months while working on another, no big deal