<Bird|otherbox>
L6 -- Buried Capacitance laminate again
<Bird|otherbox>
P7 -- power
<Bird|otherbox>
L7 -- FR408
<Bird|otherbox>
P8 -- slow signals
<azonenberg>
So that would work well for a design that had a mix of fast and slow signals
<azonenberg>
But the big 676-ball FPGA is >90% IO utilization and about the slowest thing on it is RGMII
<azonenberg>
i have four io banks stuffed almost to capacity with 1.25 Gbps LVDS and a bunch of 10G SERDES
<azonenberg>
i fully expect to have fast signals on all four signal layers
<azonenberg>
also i'm skeptical of the benefits of buried capacitance for digital stuff because via/bondwire inductance etc. I'd much rather just have a cap right next to the part with via-in-pad down to the power/ground planes
<Bird|otherbox>
ah
<azonenberg>
The big FPGA also has in-package decoupling so high freq decoupling isn't that critical
<azonenberg>
as does the PLL
<Bird|otherbox>
yeah, I can see where you're going then -- the in-package decoupling makes the need for high-speed onboard decoupling less critical
<azonenberg>
What i could potentially do is move things around so L4/L5 were power/ground and put a buried capacitance laminate there
<azonenberg>
however, then L1/3 are ref'd to ground while L6/L8 are ref'd to power
<Bird|otherbox>
yeah
<Bird|otherbox>
with 4 high speed signal layers
<Bird|otherbox>
on an 8 layer board
<Bird|otherbox>
you're a bit stuck :P
<azonenberg>
basically your stackup and mine are the two reasonable options
<azonenberg>
And which makes more sense depends on the design
<Bird|otherbox>
yeah, I see where you're going with the combination of almost all fast signals and the in-package decoupling
<azonenberg>
for this design, i think mine is the better choice, and i think going to 10L is ill advised as this is already going to be a $2K-ish board
<azonenberg>
oh and i almost forgot the DDR3 1600
<Bird|otherbox>
more than fair. I wonder if having "slower" traces on the outer layers and "faster" traces on the inner layers might be wise, even?
<azonenberg>
That was my plan, to the extent possible, but...
<Bird|otherbox>
even the "slower" stuff's mighty zippy eh? XD
<azonenberg>
the big FPGA has one bank of 10G SERDES inputs for fast LA channels, one bank of 10G SERDES in/out for ethernet, three banks of DDR3 1600
<azonenberg>
four banks of 1.25 Gbps LVDS input
<azonenberg>
and one bank of miscellaneous that's a combination of RGMII, some SPI buses, and assorted other things
<azonenberg>
but really that one bank is the only one with less than 1 Gbps data rates on it at all
<azonenberg>
and on a 676-ball package i will need all four signal layers to fan it out
<azonenberg>
i think i have 30-odd of the 400 GPIOs unused
<azonenberg>
i actually added the spartan7 (~70 of 100 pins used) as an io expander because the kintex had no free space whatsoever
<Bird|otherbox>
LOL
<azonenberg>
And then the STM32 has 159 GPIOs out of 216 total pins, and i think i'm around 75% utilization there too
<Bird|otherbox>
"that's one heck of an IO expander you have there, sir"
<azonenberg>
Lol
<azonenberg>
The overall control flow is, essentially, the kintex is the big cheese for dataflow
<azonenberg>
the stm32 is kinda like a BMC or EC for it to some extent. It's in charge of sequencing power rails, monitoring all of the i2c temp/voltage sensors, etc
<azonenberg>
as well as running the front panel status LCD and parsing SCPI control-plane commands to do things like configure triggers or voltage thresholds
<azonenberg>
then the spartan7 will be in charge of managing hotswap control for all of the LA pods
<azonenberg>
monitoring the presence detect pin and turning power on when they're plugged in, and removing power when unplugged
<azonenberg>
it will also be bridging the UARTs on each probe pod out into SPI-mapped FIFOs
<azonenberg>
because the stm32 doesn't have a dozen uarts
<azonenberg>
so the spartan7 will have a dozen separate uarts mapped to SPI registers that can be read/written via the stm32
<azonenberg>
the SPI interface will also allow the stm32 to query presence detect status and force pods on/off regardless of the hotswap detect state
<azonenberg>
The kintex will run a TCP offload engine that will likely need optimization, my current stack probably can't do 40GbE :p
<azonenberg>
one socket will go to the logic analyzer subsystem on the FPGA
<azonenberg>
and another socket will be bridged out to a UART on the stm32, which will run the scpi interface
<azonenberg>
There is also a RMII interface between the STM32 and FPGA which would permit full ethernet bridging out to the stm32 if we so desired, however initial firmware won't be using it
<azonenberg>
The stm32 will also have a SPI interface to the kintex, for downloading trigger settings onto the FPGA
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #scopehal
<_whitenotifier-f>
[starshipraider] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/JfhBY
<_whitenotifier-f>
[starshipraider] azonenberg 785d0de - Continued design review, finished power portion
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #scopehal
<_whitenotifier-f>
[starshipraider] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/Jfh03
<azonenberg>
added step models for the fans and LCD
<azonenberg>
i think the LCD is going to have to be attached via some kind of flex pcb adapter, i don't think it will be possible to fit it on this board without making it too wide to fit in my reflow oven
<azonenberg>
but i'm including it here just for reference and mechanical fit testing et
<azonenberg>
The fans are important to have because i will need cutouts at the back of the board for at least some of them
<azonenberg>
The leftmost is likely to be in the free space behind the LCD and not actually need board notching
<azonenberg>
But we'll see
<azonenberg>
monochroma: btw for the power rails, thoughts on having two of the horseshoe shaped test clips i use for each vreg? power/ground
<azonenberg>
spaced so you can slap a probe down between them
<azonenberg>
with spring ground
<monochroma>
yeah, i'm a big fan of test clips for power rails
<azonenberg>
also would you mind double checking the load caps on the 32 kHz crystal seem sane?
<monochroma>
and any general low speed test points you might want to probe for extended periods
<azonenberg>
yeah i'm approaching the test point insertion stage
<azonenberg>
not quite there yet
<monochroma>
like *pulls bag out of box sitting next to her* 36-5007-ND and such
<azonenberg>
my default is keystone 5016
<azonenberg>
i finally ran out and ordered another hundred-ish on cut tape the other day
<monochroma>
yeah i like those for grounds, they are a little big for other signals
<azonenberg>
that's what i normally use them for
<azonenberg>
5007 looks nice though, might want to play with it for something. I like 5016 because it's SMT and you can just touc ha probe to it
<azonenberg>
5006 is harder to use with a spring grounded probe without the clip on the tip
<azonenberg>
5007*
<azonenberg>
with 5016 i can put the probe in a bipod and just push it up against the end of the horseshoe
<monochroma>
probably not super different with 5007 if you have a fairly large pad around it, but yeah, i usually use them with J hook probes to meters/PSUs etc
<azonenberg>
yeah i'm thinking of scopes
<azonenberg>
5016 can be used with hook probes to a meter too
<azonenberg>
but is more scope friendly
<azonenberg>
for looking at rail noise etc
<monochroma>
yeah, is there something a little smaller?
<azonenberg>
Suggest something?
<monochroma>
i would guess there is something basically identical, but slightly less long, more square than rectangular (actually i think i remember seeing some examples of that before)
<azonenberg>
i mean suggest a specific part number
<monochroma>
not sure if it matters on this design (doesn't look like you are going to be very tight on space on this PCB)
<azonenberg>
no i expect to have ample room
<azonenberg>
it's gonna be weird lol
<azonenberg>
i'm used to ultra dense layout
<azonenberg>
but here depth is set by the case and width by the connectors
<azonenberg>
and the rest of the stuff will just go with the flow in between
<azonenberg>
MCU internal pullups should be ok for PGOOD pins right?
<azonenberg>
trying to minimize use of discrete pullups for things that don't need to have defined statuses before the MCU starts up
<monochroma>
i tend to DNP a pullup just incase
<azonenberg>
yeah should be safer
<azonenberg>
No host-side caps needed on SFPs right? the coupling caps are all module side?
<monochroma>
iirc that's correct, but i am extremely sleepy :3
<azonenberg>
especially if characterized on a vna or something
<azonenberg>
all of these test fixtures, ethernet, usb, etc
<azonenberg>
i think there's a market for
<azonenberg>
Especially if you have the data you need to de-embed them
<monochroma>
yeah. though for a lot of this stuff people only care about relative measurements
<azonenberg>
i'd want to do one more spin of each board to correct a few things, like switching to the nicer SMA and having a sonnet-optimized launch transition
<azonenberg>
and probably moving to rogers+immersion silver
<azonenberg>
and more importantly actual impedance control
<monochroma>
yeah there are def a lot of markets for such things
<azonenberg>
Any reason for termination on the STM32 SPI bus to the FPGAs?
<azonenberg>
i figure we can just use lowish slew rate on the MCU and hope for the best. It's not a high speed line
<monochroma>
lain: poke ^
<lain>
azonenberg: how fast is it?
<azonenberg>
lain: as fast as i decide to run it :p
<azonenberg>
mcu fmax is probably somewhere around 50 MHz but i expect to run it more like 1-2. I can't imagine it being at all performance critical
<lain>
if slow is fine, then don't bother. I normally put series termination if I plan on exceeding 25 MHz, simulations will generally agree that it is necessary
<azonenberg>
Yeah that's kinda my rule. this won't be close to that
<azonenberg>
maaaaybe 10 MHz
<lain>
yeah you're fine then
<azonenberg>
also the stm32 has programmable slew etc
<azonenberg>
so i can just slow it down :p
<_whitenotifier-f>
[starshipraider] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JfhgT
<_whitenotifier-f>
[starshipraider] azonenberg edf6313 - Continued schematic signoff review
<lain>
ah yeah
<azonenberg>
aaand found a flipped diffpair
<Degi>
Wow why would anybody pay 500 bucks for a sfp breakout...
<Degi>
Huh why does the 5016 cost 29 cents per piece... Isnt that just sone bent wire?
<_whitenotifier-f>
[starshipraider] azonenberg pushed 1 commit to master [+0/-0/±6] https://git.io/Jfh2I
<_whitenotifier-f>
[starshipraider] azonenberg efcacac - Continued design review. Added pulldowns to various power rail enables. Fixed pulls to on instead of off on active-low power rail enables.
<azonenberg>
Degi: i imagine at some point you're mostly paying for the packaging
<Degi>
hm yes
<azonenberg>
also i'm down to just a few things left on the checklist
<azonenberg>
Can you verify the crystals load caps on the MAXWELL 32 kHz RTC crystal?
<azonenberg>
i'm terrible at crystal calculations since 99% of the time i use oscillators so wanted a second set of eyes on it
<azonenberg>
The crystal is XC2842CT-ND and I'm using 10 pF load caps
<azonenberg>
my math says after parasitics that should be pretty close
<Degi>
I think thats right?
<Degi>
It needs approx 12.5 pF
<azonenberg>
So 10 + parasitics should be quite close
<_whitenotifier-f>
[starshipraider] azonenberg pushed 1 commit to master [+0/-0/±19] https://git.io/JfhVj
<_whitenotifier-f>
[starshipraider] azonenberg e9ee86f - Continued schematic review
<azonenberg>
woop almost done. Probably won't finish tonight but hopefully tomorrow
<_whitenotifier-f>
[starshipraider] azonenberg pushed 1 commit to master [+0/-0/±5] https://git.io/Jfhwr
<_whitenotifier-f>
[starshipraider] azonenberg d80d5ab - Continued signoff review. Added ESD protection for presence detect and UART lines on pods.
<_whitenotifier-f>
[starshipraider] azonenberg pushed 2 commits to master [+0/-0/±16] https://git.io/JfhK9
<_whitenotifier-f>
[starshipraider] azonenberg f375063 - Added missing series resistors to RJ45 LEDs
<_whitenotifier-f>
[scopehal-apps] nshcat assigned issue #118: When starting glscopeclient with no arguments, allow a file to be opened for offline analysis instead of connecting directly to an instrument - https://git.io/JfA1Y
m4ssi has quit [Remote host closed the connection]
<katharina>
azonenberg: What do you think about having a splash screen like this (this is just a quick prototype thrown together in GLADE) https://i.imgur.com/picMl7Q.png
<azonenberg>
katharina: that sounds more like a startup dialog than a splash screen, but i like the general idea. The current convention is for "glscopeclient" to be all lowercase" though
<azonenberg>
What if you make the text in the dialog just say "welcome"?
<azonenberg>
To me, a splash screen is something that displays while the app is loading. and i hate them, i think effort is better spent optimizing things so you don't need a loading screen :P
<azonenberg>
but a welcome dialog is obviously needed no matter how fast things are
maartenBE has quit [Ping timeout: 265 seconds]
maartenBE has joined #scopehal
<katharina>
azonenberg: yes, its a welcome dialog for sure
<katharina>
Welcome sounds better as well!
<azonenberg>
katharina: also we might want to re-tool how we launch the welcome dialog
<azonenberg>
have the main app window appear first and then the dialog over it
<azonenberg>
rather than having it launched before the app starts like we do now?
<azonenberg>
just an idea
<azonenberg>
but i think the UX would be better that way
<miek>
woot, offer accepted on a set of SMA gauges :D
<katharina>
azonenberg: I actually wanted to ask just that later, since thats exactly how both Blender and Autodesk Maya do it (which i have been using today and gotten the inspiration from)
<azonenberg>
Yeah go ahead and do that. Have it shown in some startup function (end of on_realize maybe?) of OscilloscopeWindow
<katharina>
azonenberg: should be modal then, right?
<azonenberg>
Yes
<katharina>
kk
<katharina>
If the user clicks on the [X] of the modal dialog, should the whole app terminate?
<azonenberg>
Hmm
<azonenberg>
no, just have it fall back to an empty OscilloscopeWindow with no session active
<katharina>
kk
<azonenberg>
Also when you're done with all that grab some new screenshots and update the text in the manual for the new look/functionality of the welcome dialog
<azonenberg>
and write something for the preferences too
<katharina>
ill make an issue for that in the docs repo rn so i dont forget
<azonenberg>
Ok
<katharina>
also, for work we will need good 4K scaling support. Ill work on that after the welcome dialog
<azonenberg>
ah yes 4k on small screens
<azonenberg>
it works great on my 4k 40" display though :p
<katharina>
:P
<azonenberg>
I am getting the new toolbar icons drawn in 24x24 and 48x48 sizes for low/high dpi displays
<azonenberg>
Also just a FYI i'll probably be offline all day saturday but will try to get through all PRs submitted by mid friday before then
<azonenberg>
(Seattle time)
<katharina>
no problem
<katharina>
the thinkpads in our big lab at work do all have 17.3" 4k screens
<azonenberg>
At some point we should also do some more testing on laptops and just see how the UX is on touchpads and if we can improve anything for that
<azonenberg>
pretty much all work to date has assumed a 3+ button mouse
<katharina>
yea, for sure.
<_whitenotifier-f>
[scopehal-docs] nshcat opened issue #14: Document new welcome dialog and loading saved sessions - https://git.io/Jfjf3
<_whitenotifier-f>
[scopehal-docs] nshcat opened issue #15: Document application preferences and preferences dialog - https://git.io/Jfjfs
<_whitenotifier-f>
[scopehal-apps] nshcat created branch startup-window - https://git.io/JvExD
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<_whitenotifier-f>
[starshipraider] azonenberg pushed 2 commits to master [+11/-0/±0] https://git.io/JfjJg
<_whitenotifier-f>
[starshipraider] azonenberg 52fdb51 - Initial MAXWELL fab notes
<_whitenotifier-f>
[starshipraider] azonenberg 14dc94a - Initial stackup simulations for MAXWELL
Stary has joined #scopehal
<Degi>
Oh yes touch support would be nice
<azonenberg>
miek: nice
<azonenberg>
I should probably get some of those at some point too
<azonenberg>
so far i've just relied on buying high quality connectors and hoping nothing ever gets bent
<Degi>
Huh, measuring every SMA before connecting?
<azonenberg>
when connecting them to expensive stuff, yeah. it's more important with air dielectric connectors like 3.5mm
<azonenberg>
which is SMA compatible but made to tighter tolerances and air instead of PTFE dielectric
<Degi>
And like type n
<azonenberg>
if you mate an out-of-spec SMA to a 3.5mm you can easily destroy it
<azonenberg>
N's are much more rugged
<azonenberg>
i mean you still want to be careful but they're a lot harder to accidentally destroy than a 3.5 or 2.92
<miek>
yeah, i've got a bunch of second-hand stuff that should be good but i'd like to check. also i'd like to to be able to make & check rigid cables for fussy measurements
<miek>
i've got a 3.5mm connector saver on my siggen, but even the saver is worth £100+ :p
<Degi>
lol
m4ssi has joined #scopehal
<azonenberg>
yeah so far nothing i have goes higher than you can do with standard SMAs
<azonenberg>
So i've stuck with them for cost reasons
<azonenberg>
my scopes have BNCs and my VNA has N's
<azonenberg>
(and yes i actually do have proper torque wrenches for them)
m4ssi has quit [Remote host closed the connection]