azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing |,, | Logs:
<_whitenotifier-f> [starshipraider] azonenberg pushed 1 commit to master [+0/-0/±4]
<_whitenotifier-f> [starshipraider] azonenberg 7d75154 - Continued design review. Added over a dozen forgotten decoupling caps.
<Bird|otherbox> azonenberg: so, while I think the stackup you came up with is reasonable, mind if I float an alternative by you?
<azonenberg> Bird|otherbox: Sure
<azonenberg> and i dont have a full stackup yet, just layer ordering
<azonenberg> the way i see it is, i need four signal and two power layers, so the other two are ground
<azonenberg> and referencing all of the signals to ground lets me use stitching vias for transitions instead of needing caps
<Bird|otherbox> P1 - slow signals
<Bird|otherbox> L1 -- FR408
<Bird|otherbox> P2 - power
<Bird|otherbox> L2 - Buried Capacitance laminate (very thin FR4)
<Bird|otherbox> P3 -- ground
<Bird|otherbox> L3 -- high-speed laminate (Rogers)
<Bird|otherbox> P4 -- fast signals
<Bird|otherbox> L4 -- Rogers? (not sure what to put here between the two signal layers)
<Bird|otherbox> P5 -- also fast signals
<Bird|otherbox> L5 -- high-speed laminate (Rogers)
<Bird|otherbox> P6 -- ground
<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]
<_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]
<_whitenotifier-f> [starshipraider] azonenberg 4462bf5 - Continued schematic review. Completed thermal analysis section.
m4ssi has joined #scopehal
<_whitenotifier-f> [starshipraider] azonenberg pushed 2 commits to master [+0/-0/±2]
<_whitenotifier-f> [starshipraider] azonenberg f548427 - Deleted pulldowns on EN signals as these are redundant
<_whitenotifier-f> [starshipraider] azonenberg 9e39e4d - Finished verifying voltage levels
<_whitenotifier-f> [starshipraider] azonenberg pushed 1 commit to master [+0/-0/±3]
<_whitenotifier-f> [starshipraider] azonenberg a7f5041 - Added mechanical footprints for fans etc
<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
<monochroma> also, lol
<_whitenotifier-f> [starshipraider] azonenberg pushed 6 commits to master [+0/-0/±7]
<_whitenotifier-f> [starshipraider] azonenberg 1767b68 - Fixed bad pullup value on Kintex INIT_B
<_whitenotifier-f> [starshipraider] azonenberg baa5bf9 - Added pullups to I2C1/2
<_whitenotifier-f> [starshipraider] azonenberg c26fb30 - Added DNP'd pullups to power rail PGOOD pins
<_whitenotifier-f> [starshipraider] ... and 3 more commits.
<azonenberg> monochroma: so it does exactly what ours does, but for $495
<azonenberg> and without the splitters or second port
<azonenberg> i seriously think selling just these test fixtures would be pretty profitable
<azonenberg> we could make our own versions on rogers and everything for a tiny fraction of this price, open source everything
<azonenberg> and companies would still pay up the nose
<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]
<_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]
<_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]
<_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]
<_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]
<_whitenotifier-f> [starshipraider] azonenberg f375063 - Added missing series resistors to RJ45 LEDs
<_whitenotifier-f> [starshipraider] azonenberg 7d6ea8d - Finished design review!!
<_whitenotifier-f> [starshipraider] azonenberg pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-f> [starshipraider] azonenberg 80e25ae - Initial PCB with all components after review
<azonenberg> still have to finalize the stackup and design rules before i begin layout
<azonenberg> but schematic is done
katharina has joined #scopehal
juli969 has joined #scopehal
<_whitenotifier-f> [scopehal-apps] nshcat synchronize pull request #122: Basic implementation of the preferences dialog -
juli969 has quit [Quit: Nettalk6 -]
<_whitenotifier-f> [scopehal-apps] nshcat closed pull request #122: Basic implementation of the preferences dialog -
<_whitenotifier-f> [scopehal-apps] nshcat deleted branch preferences-gui -
<_whitenotifier-f> [scopehal-apps] nshcat closed issue #117: Create preferences framework -
<_whitenotifier-f> [scopehal-apps] nshcat commented on issue #117: Create preferences framework -
<_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 -
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)
<_whitenotifier-f> [scopehal-docs] nshcat opened issue #13: Document preference file location -
<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 -
<_whitenotifier-f> [scopehal-docs] nshcat opened issue #15: Document application preferences and preferences dialog -
<_whitenotifier-f> [scopehal-docs] nshcat closed issue #13: Document preference file location -
<_whitenotifier-f> [scopehal-apps] nshcat created branch startup-window -
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<_whitenotifier-f> [starshipraider] azonenberg pushed 2 commits to master [+11/-0/±0]
<_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]
juli969 has joined #scopehal