<_whitenotifier-f>
[scopehal-docs] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/Jf7ku
<_whitenotifier-f>
[scopehal-docs] azonenberg fd85482 - Added skeleton headings for RGMII, current shunt, and multiply filters. Nothing much in them yet.
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/Jf7kz
<azonenberg>
Sooo i just ran a preliminary power budget for MAXWELL
<azonenberg>
Rounding a bit... 11W for the FPGA, 36W supplied to the MEAD/CONWAY pods, 0.6W for the 1G PHY, 1.5W for the 10G SFP+, 3W for the 40G QSFP+, 1W for the STM32, 8W for the DDR3, 1W for the front panel LCD, 8W for 4x 40mm fans
<azonenberg>
in total that's 70W for the whole system, then i'm going to add about a 10% safety margin on top of that for conversion losses etc
<azonenberg>
(Which should be fine because over half of the power budget is 12V loads that don't need conversion in this budget, so we really have more like 20% margin for conversion losses elsewhere in the board)
<azonenberg>
That comes out to 77W or ~6.5A @ 12V at the input
<azonenberg>
That's a bit much for the barrel jack i was originally thinking of using
<azonenberg>
and high enough power that i'm thinking of putting a mains-to-12V supply internally
<azonenberg>
commercial pre-engineered blob just thrown down inside our chassis
<azonenberg>
glad to see we're not the only ones with this ideea
<azonenberg>
front panel consisting of RF ports and a SFP
<monochroma>
:3
<azonenberg>
i wish the sfp was on the back though, as with the 10 MHz ref ports
<lain>
I'm so frustrated that Lime Micro hasn't released the LMS8001
<lain>
it's a up/down converter that lets you tune up to 10 GHz
<azonenberg>
he specifically mentions that the sweep rate is pushing up against ITAR limits
<azonenberg>
lol
<monochroma>
:D
<azonenberg>
monochroma/lain: so what do you think of my power problem re MAXWELL?
<azonenberg>
as i see it, 7A on a 12V barrel jack is just not an option
<azonenberg>
so i can either move up to a 24/48V barrel and put a step-down to 12V on the mainboard
<azonenberg>
or i can move the mains supply in
<lain>
24V 3.5A input sounds reasonable
<lain>
can probably find a decent step-down converter from some arbitrary like 24-48 or such down to 12V
<azonenberg>
yeah i like that idea. more specifically, i want to avoid putting mains in the chassis if i can avoid it
<monochroma>
yeah, mains only equipment is annoying
<azonenberg>
Are 48V wallwarts reasonably available?
<azonenberg>
I might standardize on that for all of my gear going forward
<monochroma>
yeah, they are pretty easy to find on digikey
<monochroma>
personally i like 24VDC better than 48, unless you are in a telecom environment 48 isn
<azonenberg>
why?
<azonenberg>
i was thinking of standardizing on 48 for all of my DC powered stuff
<monochroma>
personally i like 24VDC better than 48, unless you are in a telecom environment 48 isn't super common, but 24 is more common
<azonenberg>
Well i figure i'll design my lower power gear to run on 24 or 48
<azonenberg>
then step down to 12V intermediate and from there to whatever internal rails i need
<monochroma>
what i really like is wide input range converters
<monochroma>
but they are spendy
<azonenberg>
yeah thats what i meant
<azonenberg>
lower power stuff will accept 24 or 48
<azonenberg>
future higher power gear might be 48 only
<azonenberg>
What do you think of the CPE9B36P?
<azonenberg>
18 to 72V input, outputs regulated 12V at 9A
<azonenberg>
fully isolated, not that i need that
<monochroma>
ooo
<monochroma>
not a bad price
<azonenberg>
it's another of those "marketplace products"
<azonenberg>
but that isnt necessarily a bad thing given that i won't mind a bit more shipping delay
<monochroma>
ah
<monochroma>
yeah
<azonenberg>
Then 1866-2158-ND as the power supply for the prototype
<azonenberg>
Then i guess back ports for 10 MHz ref in, trigger in, and trigger out
<azonenberg>
and probably ref out for debug, although i don't expect to use that routinely
<azonenberg>
monochroma: does a 50 ppb OCXO sound reasonable as an internal timebase?
<azonenberg>
The clock distribution path will consist of 10 MHz from external and 10 MHz from the OCXO fed into a LMK04806, dual loop PLL to jitter clean, 2.5 GHz VCO
<azonenberg>
then output 25 MHz to the Ethernet PHY, 312.5 MHz to the FPGA SERDES for the 10/40GbE, 250 MHz to the FPGA SERDES for the input oversampling, and one or more clocks to the FPGA
<azonenberg>
the PLL will be configured via the stm32 using its internal RC oscillator (I don't see a need for precision timing on the MCU)
<azonenberg>
First block guaranteed valid at time of shipment
<azonenberg>
not managed like emmc, it's raw nand
<azonenberg>
monochroma: is there any reason to have PPS input on any of this gear?
<azonenberg>
I can't think of why you'd need LA samples to be synced to specific absolute time, the only purpose of using a GPSDO or similar would be to prevent drift between instrument clocks
<azonenberg>
right?
<monochroma>
hmmmmm i would probably at least leave an unpopulated port on the board for one maybe
<monochroma>
but yeah, mainly just making sure like, if you have a scope and LA probing signals on the same system, you would want to keep them in sync
<azonenberg>
this is going to be a huge, dense board lol
<monochroma>
maybe leave a u.fl or other similar tiny footprint part
<azonenberg>
no i was gonna stick a full edge launch sma on the back of the chassis going through a comparator against ground to an fpga gpio
<azonenberg>
we can always DNP it
<monochroma>
ah
<azonenberg>
also i almost forgot there is going to be a second fpga on this board lol
<azonenberg>
there's not enough pins on the kintex to run the 12 uarts, presence detect, and power enable pins for all of the probes
<azonenberg>
So i'm going to run spi or something to a little xc7s6
<azonenberg>
ftgb196 is so tiny and cute compared to the kintex lol
<Degi>
We can just make our own wide input range converter tbh
<Degi>
Tbh if it already uses like 80 W a builtin power supply would be okay
<azonenberg>
I like this solution, wallwart and just bumping up to higher voltage at the input
<Degi>
Hmh?
<azonenberg>
24V is not unreasonable. I also am being pretty conservative with that 80W, i expect actual load to be less
<Degi>
You mean to lower at input?
<azonenberg>
no i mean higher at the input to the unit
<azonenberg>
and then stepping down to 12 internally
<Degi>
Ah yes
<Degi>
I mean we could have 24 input and add an option where we ship it with a good psu
<azonenberg>
The PSU i specced tentatively will accept 18-72 at the input
<azonenberg>
giving you the choice of 24 or 48 basically
<azonenberg>
no connections, just figuring out high level structure of the schematic and working out what parts i'm using and what fpga banks are doing what
<Degi>
The PPS would theoretically go straight to the FPGA and the REFCLK to the LMK?
<azonenberg>
Yes. I don't expect to actually USE the pps but i figure i'll provision it in case it becomes necessary
<azonenberg>
the LMK has two refclk inputs
<Degi>
Why are there LMH7322's besides the SMA
<azonenberg>
Because the SMAs are single ended with potentially unknown amplitude
<azonenberg>
i figure a comparator is a better RX than an LVDS input buffer
<Degi>
Well but does your PPS or 10 MHz input have a 250 ps on time
<azonenberg>
square it off nicely and feed a clean differential signal to the PLL
<azonenberg>
are you saying the 7322 is overkill speed wise?
<Degi>
It probably wont be so clean when we put a OP amp with 2000000000 Hz bandwidth on a 1 Hz input
<azonenberg>
We can put hysteresis on it, and i intend to
<azonenberg>
But i want low propagation delay and fast edges on the output
<Degi>
And it costs like 7 bucks
<azonenberg>
you realize this is a $1000+ instrument right?
<azonenberg>
that's going to plug into about $2000 of LA pods?
<Degi>
Hmh with hysteresis it could work fine
<Degi>
Will there be 50 ohm termination on all inputs?
<azonenberg>
also i want to allow more than 10 MHz ref in
<azonenberg>
i want to allow 100 or 156.25 etc as well
<azonenberg>
anything you can multiply up to 2.5 GHz
<azonenberg>
a lot of stuff is moving away from 10 MHz to get higher precision
<azonenberg>
you mean the ext trig/refclk etc inputs? yes, 50 ohm terminations
<Degi>
Hm yeah, the LMH7322 for trigger makes sense and the second channel of that for the refclk
<Degi>
But for the PPS thats kinda overkill and leaves an unused channel
<azonenberg>
Yes, i'm iffy on if i'll even need the PPS
<azonenberg>
we can swap that to a slower comparator if you want
<azonenberg>
this is very early in the design so i'm just feeling around here
<azonenberg>
then as far as PLL outputs we'll have a single ultra low jitter 2.5 GHz VCO
<azonenberg>
This will drive 312.5 MHz to the 10G/40GbE serdes quad, 25 MHz to the 1G PHY, probably 250 MHz to the other serdes quad which will sample at 1.25 GHz, then probably 156.25 to the kintex as a general system clock
<azonenberg>
and then maybe 50 MHz to the spartan7 to run its logic, that doesn't need to be fast
<Degi>
Hm yes, especially for an unterminated input a faster OP amp may measure ringing. Breaking out some of the output channels from the LMK to SMAs could be useful for systems that support clocking off of that
<azonenberg>
I might break out a few extra ports on the back so we can use this for refclk distribution, although that is not the primary use case
<Degi>
You mean 250 MHz on the 1G?
<azonenberg>
to the gig-e phy? no, it wants 25 and has an internal PLL
<Degi>
Ohh
<azonenberg>
normally i'd just slap a 25 MHz xtal or oscillator there
<Degi>
Meh we already have the LMK
<azonenberg>
but as long as i have the LMK on there it costs me nothing to use an extra channel
<azonenberg>
exactly
<azonenberg>
so the whole board will be clocked off the one OCXO via the LMK
<Degi>
Hmh yes at least one channel out for refclk would be good...
<azonenberg>
there will definitely be at least one refclk out
<azonenberg>
with arbitrary frequency divided from the 2.5 GHz VCO
<azonenberg>
Then the STM32 will run off an internal RC oscillator because timing is non-critical for what it does
<Degi>
How is REFCLK usually distributed? A central clock buffer gets a ref in or makes its own and then has a bunch of SMAs where it outputs REFCLK?
<azonenberg>
and more importantly, it's the thing that has to configure the LMK at startup before anything else can happen :p
<Degi>
Lol yeah
<azonenberg>
You mean lab-wide refclk?
<Degi>
yeah
<azonenberg>
Right now i don't have one, but i have a design in the works for exactly that
<azonenberg>
it will use a LMK04806, stm32, and small spartan7
<azonenberg>
PPS + 10 MHz in from external GPSDO, or internal OCXO - basically the same distribution design i have in mind for this board
<Degi>
It'd kinda make sense to have loopback on the devices so that they can be series chained, but that would add jitter and path length
<azonenberg>
except i'll have all of the ports out to smas on the front and back
<Degi>
Should PPS be terminated?
<azonenberg>
if not we'll get crazy reflections, so yeah
<azonenberg>
Anyway so the refclk distribution system will also take advantage of the phase control on the LMK
<Degi>
I mean you could just pick the first edge it should be fine unterminated, since itll ring down in a second
<Degi>
Ah yes
<azonenberg>
the fpga will control a latching comparator that is used to sweep the phase on the pll to compensate for cable propagation delay
<azonenberg>
so you can feed each output one at a time through the actual cable you're using back into the phase reference port
<azonenberg>
and null out the cable skew
<azonenberg>
so the rising edge hits the end of each cable synchronized +/- 25ps with every other cable
<azonenberg>
this means your hardware doesn't just get a stable refclk, you can do phase coherent sampling
<Degi>
So the comparator compares a reference with a loopback port, where the other end of the cable is stuck to?
<azonenberg>
Yeah, basically
<azonenberg>
compare internal loopback to signal at the end of the cable
<azonenberg>
then adjust phase until they're synced
<Degi>
Hmh adjusting by sending a ref signal to all scopes / LAs / whatever and then adjusting the phase that they show the same waveform could work too, but thats gonna have more than 25 ps...
<Degi>
Hmh yeah
<azonenberg>
but then you remove the cable from the loopback port and connect to your actual instrument
<azonenberg>
and now it's coherent
<Degi>
Plus the instrument delay
<Degi>
Yeah
<azonenberg>
I dont know how useful that capability will be to me, but it comes free with the PLL
<azonenberg>
so i figured i'd allow it
<Degi>
Well you can use different length cables
<azonenberg>
you of course will also be able to do manual deskewing
<azonenberg>
and just say "output B is 500ps lagging output A"
<azonenberg>
But that's another project, i dont have time for it AND all of th eother ones right now
<azonenberg>
so i'm making sure all of my gear has 10/100 MHz ref in capability, but also has an internal OCXO so it can run standalone
<azonenberg>
I'm pushing MAXWELL ahead of BLONDEL because we're still waiting on some stuff like the active probe designs to be fine tuned, plus there's somebody interested in using it ASAP
<Degi>
Hmh okay
<azonenberg>
then the refclk thing will probably come after BLONDEL
<Degi>
Ah right that one
<azonenberg>
because at that point i'll have two lecroy scopes, one of our scopes, and the LA that all need to be synced
juli967 has joined #scopehal
<azonenberg>
Degi: NCP45525 for power gating the pods?
<Degi>
Ooh, high side switch with builtin charge pump
<Degi>
Kinda wonder where all these chips are produced
<Degi>
TSMC?
<azonenberg>
who knows
<azonenberg>
also they're cheap, 72 cents a pop
<azonenberg>
and a nice tiny 8dfn
<Degi>
Yeah sure go for it
<Degi>
Haha "BLEED"
<azonenberg>
BAGEL is my favorite pin name
<Degi>
Lol
<Degi>
"Typical Applications" is sometimes fummy
<azonenberg>
hotswappable peripherals? why yes
<azonenberg>
that is exactly what i am using it for
<Degi>
Yeah sure I'd use your plastic packaged part for video satellites (not sure what that was from but I found it yesterday, probably was a cheapish upconverter)
<Degi>
Does the connector have some recessed pins?
<azonenberg>
the SFF connector?
<Degi>
yes
<azonenberg>
Yes, the LVDS lanes mate after the rest
<azonenberg>
but ground and sideband mate at the same time
<azonenberg>
to prevent potential problems i'm gating the 12V power when nothing is mated
<azonenberg>
Then once presence detect is asserted wait half a second or so then enable the 12V power
<azonenberg>
that, times 12 ports, is one of the two duties of the spartan7
<Degi>
So theres no recessed other pins you could use for presence... Well okay
<azonenberg>
the other is bridging the twelve uarts out via i2c or spi to the kintex, because it doesn't have enough pins to talk to them
<azonenberg>
we're full up on the ffg676 package, going to be close to 100% io utilization
<azonenberg>
and i didnt want to move to the 900 ball package because that would mean more pcb layers
<azonenberg>
and the delta in price just from the bigger fpga was more than the cost of an xc7s6 :p
<Degi>
lol
<azonenberg>
MAXWELL is gonna be a lot of firsts for me
<azonenberg>
First >4 layer board fabbed for one of my own projects (vs a paying customer)
<azonenberg>
Largest board i've ever designed
<azonenberg>
It's going to beat BLONDEL and the clock distribution system to be the first rackmounted project i've made
<azonenberg>
Biggest FPGA i've ever put on a board
<azonenberg>
Most expensive board / BOM i've ever designed
<azonenberg>
First use of DDR on an FPGA (not counting devkits or the DDR1 I put on a spartan6 board and never used)
<Degi>
Yeah we better dont set the 1V0 to the wrong voltage heh
<azonenberg>
first FPGA board i've designed with SERDES
<azonenberg>
the TDR had them, but i never used them
<azonenberg>
(it was a 7k70t)
<azonenberg>
and probably some others too
<Degi>
Kinktex
<Degi>
Do you have any plans yet how many layers the PCB will be?
<azonenberg>
4 signal layers, 6-8 total
<azonenberg>
unsure if i'll need the second set of power/ground planes
<azonenberg>
I plan to floorplan the layout then decide
<Degi>
Guess that kinda depends where aux power balls are on the FPGA
<Degi>
Is that 0.8 mm pitch?
<azonenberg>
The FPGAs are both 1mm, the STM32 is 0.8 but small enough that i can fan it out on 4L
<azonenberg>
I'm also not going to be using nearly all of the pins
<Degi>
Oh neat, STM32 with BGA
<azonenberg>
same part i use on integralstick
<azonenberg>
overkill for this application, i think, but has room for flexibility
<azonenberg>
if i have pins left on the kintex i'll try and run a RMII bus between them so the stm32 can get direct ethernet access if we want
<Degi>
A breadboard made from a large TSV chip with builtin switches which you can soft-configure for a certain wiring would be neat
<azonenberg>
lol
<Degi>
stm32 has RMII?
<azonenberg>
the bigger ones, yeah. No gigabit but it can do 10/100
<Degi>
Neato
<azonenberg>
i plan to do what i am doing on blondel at least to start
<azonenberg>
i.e. tcp offload on the kintex, then bridge a socket to a uart
<azonenberg>
but if i have the pins i'll hook up the rmii, i can always not use it
<azonenberg>
Also, totally offtopic, but it just came in
<azonenberg>
a while ago i got annoyed by people mispronouncing "ferry boat" as "furry boat"
<Degi>
lol
<azonenberg>
sooo i decided to show the world a real furry boat, thanks to an artist i've worked with in the past
<azonenberg>
no i have not seen it before, i've seen surprisingly few ghibli films
<Degi>
Kinda wonder how the mouse heads got up there
<azonenberg>
Soooo did we want to put INA226's on the individual 12V rails for each probe pod?
<azonenberg>
To detect faults of various sorts?
<azonenberg>
i will probably also have fuses to be safe
<azonenberg>
not going to implement soft current limiting as that's more complicated and something would have to go really wrong for a pod to fail short. Especially because the pod also has a fuse at its input
<azonenberg>
but i at least want fusing because of the amount of power available on that 12V rail
<azonenberg>
MEAD has a 1 amp fuse at the input, i figure i'd put a 1A fuse at the host side too on each rail, then current monitoring to detect if something is wrong but not a dead short? the pods should only pull ~300 mA
<monochroma>
if all they are going to be doing is fault detection i don't see a huge point, a fuse and a non operational pod indicates the same thing
<azonenberg>
monochroma: well the idea would be to detect faulty pods that havent blown the fuse
<azonenberg>
as well as just internal health monitoring
<azonenberg>
Not sure if needed
<azonenberg>
Definitely having host side fuses though
<monochroma>
no harm in speccing them
<monochroma>
don't have to populate them
<azonenberg>
well i'd at least need the shunt resistors populated
<azonenberg>
i just want to avoid excessive scope creep at this point lol
<azonenberg>
i feel like the project has grown enough
<monochroma>
it does feel right on the line
<monochroma>
you can populate 0 ohm jumpers instead of shunt resistors if you don't want to populate in production
<azonenberg>
Except i normally use 4-terminal resistors for shunts
<azonenberg>
to do 4-wire sensing
<electronic_eel>
have a look at the INA233 instead, it has programmable current & voltage upper and lower limits, the INA226 has just one limit at one time
<monochroma>
azonenberg: 4 terminal is a bit overkill for this particular application :P
<azonenberg>
actually given the low voltages across the shunt
<azonenberg>
not really
<azonenberg>
electronic_eel: up to 16 devices on a bus, we'd have 12 - lol that's pretty close
<Degi>
U can use a trace as a resistor
<monochroma>
the app notes for most shunts like this basically have you put the amp right on the resistor
<azonenberg>
and look at that, it's a pin compatible drop in replacement for the ina226
<_whitenotifier-f>
[starshipraider] azonenberg pushed 1 commit to master [+0/-0/±12] https://git.io/Jf7RZ
<_whitenotifier-f>
[starshipraider] azonenberg 5013150 - Initial schematic capture for MAXWELL pod power
<electronic_eel>
maybe add physical pulldowns on the *_PWREN lines, that they stay disabled when the fpga is in reset
<azonenberg>
the load switch says that they have internal pulldowns
<azonenberg>
datasheet*
<electronic_eel>
ah, ok, didn't look too deep into the ds yet
<azonenberg>
So as long as i don't enable PUDC on the spartan7 (pullups on all GPIOs before configuration) then it should default to off
<azonenberg>
electronic_eel: btw not sure if you saw the chatter earlier but i'm going with a dual fpga design here
<azonenberg>
xc7s6 plus the big kintex
<azonenberg>
not enough pins on the kintex unless i go to ffg900 which means adding more pcb layers
<electronic_eel>
the xc7s6 is for control stuff, right?
<electronic_eel>
like all of the uarts to the pods and so on
<azonenberg>
yeah
<azonenberg>
and driving the power enables, monitoring the ina233 alerts
<azonenberg>
monitoring pod presence detect
<azonenberg>
its basically just a glorified pmic
<electronic_eel>
a smaller fpga makes sense for that, the stm32 have too few uarts
<azonenberg>
yeah exactly
<azonenberg>
somebody suggested lattice but i didnt want to mix device families on one board and i know xilinx stuff well
<azonenberg>
also the lattice stuff would have needed another power rail
<azonenberg>
the spartan can run on the kintex vccint rail
<azonenberg>
anyway so then a spi link to the stm32 from the spartan
<electronic_eel>
I think this is a good combo
<monochroma>
need to get azonenberg to play with lattice sometime ;)
<azonenberg>
then a second spi link from the stm32 to the kintex
<azonenberg>
for configuration
<azonenberg>
as well as a uart for scpi data since, as with blondel, there will be a tcp offload engine in the fpga that manages the tcp for the mcu
<electronic_eel>
monochroma: if he is used to fight with vivado and doesn't feel pain from it, I think he'll focus on the downsides, like not that many fast serdes and so on
<monochroma>
yeah
<monochroma>
a familiar evil ;)
<electronic_eel>
oh, and IIRC he uses system verilog, which is not well supported in yosys yet
<azonenberg>
yes
<monochroma>
yeah that is an issue with yosys
<azonenberg>
same reason i havent done much formal lately
<azonenberg>
given the choice of formal or vastly increased productivity, i chose the latter
<azonenberg>
also lol, bank 34 of the spartan is already at 72% utilization from the power rail stuff
<azonenberg>
and i havent even hooked up the uarts
<azonenberg>
And bank 14 is now at 70% utilization from the uarts, qspi boot flash, and spi to the stm32
<azonenberg>
overall 71 of the 100 pins used
<Degi>
Neat
<azonenberg>
This is on the small fpga
<azonenberg>
the big one will be very heavily loaded too between the 64-bit DDR3 interface and 92 LVDS inputs
<Degi>
Hmh arent 4 of them serdes
<Degi>
Ah nah that was included in the 96
<azonenberg>
Yes
<azonenberg>
it may end up being 93/3 not 92/4
<azonenberg>
because i think i may need one of them for sync
<Degi>
Whys that
bvernoux has joined #scopehal
<Degi>
Sync?
<azonenberg>
the phase of the 10 GHz serdes pll vs the 1.25 GHz LVDS sampling rate are not locked
<Degi>
Huh?
<Degi>
Isnt the 10 GHz generated by a PLL from a clock which also generates the 1.25 GHz sample rate?
<azonenberg>
Not exactly
<azonenberg>
the 10 MHz is multiplied up to 2.5 GHz
<azonenberg>
This then gets divided down to one clock to the fpga serdes and one clock to the fpga fabric. Most likely 250 and 312.5 MHz respectively, both phase locked to the 10 MHz
<azonenberg>
These then get multiplied up in the fpga, in two different plls, to 10 GHz and 1.25 GHz
<Degi>
So at least they are related by a rational number?
<azonenberg>
these are locked to the 10 MHz but may have arbitrary phase offset wrt each other
<Degi>
Ah
<azonenberg>
more specifically, the serdes is going to take the 10 GHz clock and divide down by say 64 to get 156.25 MHz of data coming off each serdes lane
<azonenberg>
then the 1.25 GHz LVDS will be divided down by 8to 156.25 MHz as well
<Degi>
You could measure the phase offet between the 156.25 MHz somehow
<azonenberg>
these will have a constant, unknown phase offset so i'll probably have to treat them as async wrt CDC, but will both be locked to the 10 MHz ref
<azonenberg>
that sounds hard
<azonenberg>
because i'd need extremely tight sync
<azonenberg>
see, the phase between those isn't what matter
<azonenberg>
the issue is that coming off these serdes i have a 64 bit word and an 8 bit word
<Degi>
Tbh with 4 channels you can do like PCIe x4, so M.2 cards and all that stuff
<azonenberg>
and i need to align these data streams so that i know which 8 samples of the fast channels line up with which sample on the slow channel
<Degi>
Hmh yes
<azonenberg>
It might be possible to do this with a one time mux that i switch out once the plls are locked
<Degi>
Do all SERDESs sample with the same phase offset
<azonenberg>
That's not super clear. I need to read more into the serdes manual
<azonenberg>
i know the CDR can be turned off
<azonenberg>
so they just sample on the main quad PLL
<azonenberg>
so i'd expect them to be synced in that state
<Degi>
Maybe we can do it software side
<azonenberg>
what i'm hoping is that since the serdes and the fpga plls are fed by the same refclk, they won't drift - which means i can do a one time sync at startup and keep all four
<Degi>
Like request the user to connect them to a common signal
<azonenberg>
i think i can do it with a 2:1 mux on every serdes lane
<Degi>
yes
<Degi>
You can use USB C MUX I think
<Degi>
Much cheaper than relays...
<azonenberg>
just need to find one that's fast enough. But i'm a ways from that part of the design
<azonenberg>
i'm working on the parts i know how to do first
<_whitenotifier-f>
[starshipraider] azonenberg pushed 1 commit to master [+2/-0/±12] https://git.io/Jf701
<_whitenotifier-f>
[starshipraider] azonenberg e30d66a - Refactoring: moved left/right 6 pods into separate sub-sheets of the schematic
<azonenberg>
This is now a fourteen page schematic
<azonenberg>
lol
<azonenberg>
To be fair many of them are still blank
<azonenberg>
but this is gonna be a big design
<azonenberg>
i'm a little terrified of trying to hand assemble it
<Degi>
yes
<Degi>
Pricy mistakes to be made
<azonenberg>
not just that, but the ergonomics of trying to work on a board this large without smearing the solder paste etc
<azonenberg>
fitting it under my microscope
<azonenberg>
without hitting the fume extractor or any of the other things i have sitting around
<Degi>
Not having too loose clothing which may swish all the components around if it touches the PCB
<azonenberg>
lol
<azonenberg>
well it will be a fun challenge
<miek>
might be able to borrow some ideas from manual pick and place machines. in particular, they usually have a travelling hand rest suspended above the board
<azonenberg>
miek: or i might just use this as an excuse to buy one of those benchtop PnP's
<azonenberg>
i'm not yet sure
<azonenberg>
i dont really have a place to put one...
<azonenberg>
If i don't dedicate a serdes lane to monitoring the trigger, i can only detect external triggers by monitoring them with the FPGA in the 1.25 Gsps clock domain
<Degi>
Isnt that possible with timestamps too
<azonenberg>
Which means +/- 800ps of trigger uncertainty
<Degi>
Well considering the meter of cable or so
<azonenberg>
vs +/- 100ps if i sampled the trigger with the SERDES
<azonenberg>
and that delay is constant
<azonenberg>
it can be measured and calibrated out
<azonenberg>
My 2x lecroy sync gets within like 1-2 samples of perfect sync from what i've seen
<Degi>
Well you could do sync based on timestamp if other devices support that
<Degi>
Or add a mux for that too
<azonenberg>
you mean 1588?
<Degi>
So you can choose whether you want trigger sync or four serdes channels
<azonenberg>
1588 isn't good to picosecond level
<Degi>
Idk what standards there are...
<azonenberg>
There isnt any sort of standard for this level of sync that i know of
<Degi>
But if its pps locked, you could make a timestamp for the trigger event and then get the samples from the LA around taht timestamp
<azonenberg>
yeah, my lecroy scopes dont have pps input
<Degi>
On two channels you can have a 2:4 MUX so you can chooe between 4 chan or 2 chan + ext trig
<azonenberg>
so there's no precision timing
<Degi>
Or a 1:3
<azonenberg>
it will be 3 chans + ext trig, or 4
<azonenberg>
anyway, for DENNARD I think i will use one lane always to monitor the external trigger, then use the mux based technique to determine the pll phase of each quad relative to the fpga clock at startup
<azonenberg>
But that will be on a much bigger fpga with more serdes lanes so wasting one isnt a huge deal
<azonenberg>
for MAXWELl burning one of four seems like a big problem
<azonenberg>
sooo what i think i'll do is put a 2:1 mux on all 4 lanes
<azonenberg>
Lane 1 is either ext trig or a channel
<azonenberg>
lane 2 is an internal sync pulse at startup, then a channel after init is done
<azonenberg>
Lanes 3 and 4 always keep the mux at position 1, but use it to match propagation delay across temp/voltage with the other lanes
<Degi>
Ah yes because mux delay
<azonenberg>
yeah. i could do trace delay or use a delay line, but i want something as close as possible to what the other channels have
<Degi>
Hmh idk how to find mux, just searching mux is probably not ideal. You'd need 1 channel MUXes, because ch1 and ch2 should be independently switchable
<azonenberg>
SY56017R
<azonenberg>
280ps propagation delay, data rates to 6.4 Gbps, CML with 80ps rise/fall times
<azonenberg>
fully differential inputs and outputs
<azonenberg>
80 mA @ 2.5V, 16 mA @ 1.8V
<azonenberg>
100ps part to part skew, so essentially one sample of worst case misalignment between channels
<azonenberg>
From my perspective the entire SERDES input subsystem on MAXWELL is a bonus
<azonenberg>
i don't strictly need it
<azonenberg>
so i'm considering it a dry run for DENNARD
<azonenberg>
if it doesnt work, i avoided a mistake on an even more expensive board
<azonenberg>
if it does work, great
<Degi>
Ah yes I found that one too
<Degi>
Kinda found the 6.4 insufficient but yeah the comparator can only do 4 anyway
<azonenberg>
Exactly, it's not the limiting factor at this point
<azonenberg>
realistically if you're oversampling and not doing CDR
<azonenberg>
you can't do 6 Gbps on a 10 Gsps input anyway
<azonenberg>
now we COULD turn cdr on in an alternate bitstream
<azonenberg>
but that would make a totally different instrument
<Degi>
WEll yeah a protocol analyzer...
<Degi>
It can do 66/64 right
<azonenberg>
The GTX has a gearbox for converting the native width to 66 bits
<azonenberg>
with bitslip
<azonenberg>
block sync detection and scrambling are left as an exercise to the reader :p
<Degi>
Huh? Even with CDR?
<Degi>
For example in the ECP5 the 8b10b unit output K and D codes
<azonenberg>
The GTX has an 8b10b block that does full codebook stuff
<azonenberg>
you have a bit for control vs data, a bit to force disparity, and a byte of data
<azonenberg>
for 64/66 it gives you 66 bits but you have to figure out the boundaries yourself
<azonenberg>
i.e. the sync header could be at any offset within that 66 bits
<azonenberg>
the gearbox will bitslip for you on request, but you need to determine that you need it
<azonenberg>
if you think thats bad, i worked on an asic project a while ago with a "naked serdes"
<azonenberg>
literally all it did was cdr
<azonenberg>
i had to do all of the line coding myself from scratch including several gearboxes to change data widths
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<Degi>
Lol
<Degi>
How does CDR work on a FPGA
<Degi>
As in fabric CD
<Degi>
*CDR
<Degi>
Do you just try to make a clock signal from a data stream and then feed that to a pll to stabilize the frequency
<azonenberg>
you dont recover a clock in fabric based rx's normally
<azonenberg>
you oversample and infer the location with more like a DLL
<azonenberg>
in the case of the gtx 64/66, the serdes finds bit boundaries for you
<azonenberg>
what it doesn't do is find *block* boundaries
<_whitenotifier-f>
[starshipraider] azonenberg pushed 1 commit to master [+1/-0/±14] https://git.io/Jf7ur
<_whitenotifier-f>
[starshipraider] azonenberg 86bb77c - Initial work on SERDES inputs
<Degi>
So it gives you the received bits basically
<Degi>
Oh well
<azonenberg>
yeah
<azonenberg>
it gives you bits, 66 at a time. Arbitrarily phased to the blocks
<azonenberg>
So you need to figure out the 64/66b block boundaries then descramble
<azonenberg>
in the case of the naked serdes i was talking about before, it gave me bits 32 at a time
<azonenberg>
so first i had to gearbox them out to 66 bits, then find block boundaries and bitslip until i had the correct sync, then descramble
<azonenberg>
then take the 64 bit data and gearbox it again to 72 bits because that was the native word size of the module it was hooked up to (custom protocol, not ethernet)
<azonenberg>
lots of data shuffling going on there
<Degi>
I guess that way you can support higher ratios??
<Degi>
Like 512b514b or something
<azonenberg>
no i think its because the block sync etc is complicated and not super speed critical
<azonenberg>
because it's 66x slower than the serdes rate
<azonenberg>
and a fair bit of logic
<azonenberg>
so they probably figured it didnt make sense as hard ip
<Degi>
ah
<Degi>
you could still do higher ratios
<Degi>
If the cdr can lock onto that
<Degi>
Oh, they usually have a maximum no-transition length
<Degi>
If it unlocks after like 80 bits of no transitions or so
<azonenberg>
well that's why 64/66 scrambles
<Degi>
still that could happen?
<azonenberg>
64/66 is designed to *guarantee* a transition every 66 bits, and have *extremely high probability* of transitions much more often
<Degi>
Hmh yes
<Degi>
But like if you have scrambled 128/130b you could have no transition for 129b
<Degi>
OK the probability would be like 2^128
<azonenberg>
exactly
<azonenberg>
the probability of getting the pathological sequence at the exact right offset in the scrambler is remote enoguh they simply accept it
<Degi>
Hmh yes especially if you have like a 128 bit lfsr hrh
<Degi>
*heh
<Degi>
Apparently there were problems with something using a 7 bit LFSR and an attacker being able to cause an unlock really easily