<azonenberg>
whats funny is, if i ever tried doing product design for audiophools
Degi_ has joined #scopehal
<azonenberg>
i'd actually engineer it right, no pseudoscience or anything, just massively excessive
<azonenberg>
like, EMI cans over everything, coplanar waveguide on the audio traces
<Degi_>
lol
<azonenberg>
probably some exotic RF ceramic for the board
<Degi_>
Actually maybe not coplanar waveguide you dont wanna transmit all of the EMI lol
<Degi_>
Hm I think the most important thing you can have is a RF filter on the input for old audio amps. And shielding
<azonenberg>
gigasample ADCs and DACs with extreme linearity
<azonenberg>
because who doesn't need a JESD204 headphone amp?
<Degi_>
Especially if you're anywhere nearby my electricity connection and I mess shit up
<Degi_>
Lol instead of aux cable use SFp
<monochroma>
i think my favorite part of all of it, is they go to such "great lengths" to make everything "perfect" and "isolated" and then it just ends up going into a tube amp :P
<azonenberg>
monochroma: lol yes. or signal coming off of vinyl
<Degi>
Oh of couse magnetic compensation, you dont want the earth magnetic field. Reduce to nanotesla. Maybe make cables out of superconductor. Stirling helium cryocooler
<azonenberg>
Lol
<azonenberg>
monochroma: btw, the block diagram of this atomic clock includes a "physics package"
<azonenberg>
i'm... not sure i want one of those in my lab ;)
<monochroma>
azonenberg: you read all the wrong papers first :P
<Degi>
Lol add antennas before you do lithobraking
* monochroma
was familiar with the term "physics package" from such instruments before the /OTHER/ use of the term :P
<azonenberg>
Yeah i jsut need to sit down and write some code now
<Degi>
Kinda weird that it didnt instantiate the resistors before
<Degi>
okay
<azonenberg>
i think the io cells got optimized out
<azonenberg>
Oook so let me see if i'm interpreting this right
<sorear>
(the Earth's gravitational redshift is 10^-18 per cm of altitude, so getting beyond that requires an unreasonable degree of knowledge about *your lab geometry*)
<azonenberg>
So rising edge of FCLK denotes sample boundaries
<azonenberg>
Then it's bit serial within each lane it looks?
<azonenberg>
1A-1B-2A-2B-3A-3B-4A-4B
<Degi>
Each lane gives you 1 sample
<Degi>
Are you on the HMCAD1511 datasheet page 10?
<azonenberg>
Yeah
<Degi>
Hm yes that order should be right for successive samples
<azonenberg>
what i mean is, it's striped across lanes, not 8 bits = 1 sample per LCLK cycle
<Degi>
Yes
<azonenberg>
it's sample leve lstriping
<Degi>
Thats why the frame clk
<azonenberg>
Makes sense
<Degi>
Hm I kinda feel like this will take up a bunch of FPGA area lol
<azonenberg>
compare to tcp/ip? i doubt it
<azonenberg>
are you used to ice40s or something? :p
<Degi>
Hm nah
<Degi>
I never got a FPGA full tbh
<Degi>
Once got yosys or so stuck when I tried to synthesize a million 16x4 cells and it couldnt figure out how to fit loll
<azonenberg>
the xc7a100t has 63400 LUTs, 126800 FFs, 240 DSP blocks (18x25 multipliers plus other stuff), and 270 18Kbit RAMs
<azonenberg>
and twelve PLLs
<Degi>
Hm yes pretty similar to ECP5 85k
<azonenberg>
these are LUT6s
<Degi>
No idea what kinda luts lattice uses
<azonenberg>
i think lut4 based, i think xilinx and altera are the only lut6 based devices
<azonenberg>
xilinx estimates their 63k lut6s are equivalent to ~100k lut4s, hence the name
<azonenberg>
the actual conversion is of course very design dependent, some stuff uses the extra inputs well and some doesn't
<Degi>
Hm trellis counts usage in slices...
<azonenberg>
the 100t has 15850 slices, 4 LUTs + 8 FFs each
<azonenberg>
each LUT6 is constructed as two LUT5s sharing the same inputs, with a 2:1 mux on the output
<azonenberg>
So you can use it either as a 6-to-1 or 5-to-2 function
<azonenberg>
hence the double FFs
<Degi>
Hm ecp5 85k has according to prjtrellis 41820 slices with 2 LUT, 2 FF and fast carry logic
<Degi>
Neat
<azonenberg>
Yeah different architectures for sure
<Degi>
Hm if the SLICE[A-D].K[0-1].INIT are the LUTs then thats LUT4
<azonenberg>
yeah thats LUt4
<azonenberg>
LUT4*
<Degi>
Does the artix have hard IP PCIe?
<azonenberg>
If memory serves me right, they have hard IP for PCIe gen 2 and SERDES fast enough for gen3 with a soft IP
<azonenberg>
gen3 wasnt finalized when they taped out i think
<azonenberg>
(yay timing failures, let's see where it went wrong)
<azonenberg>
in the LA of all places
* azonenberg
adds some pipeline stages
<azonenberg>
Right now i have this input stage written as DDR but it's hard to get good timing performance
<Degi>
Hmh
<Degi>
Why
<Degi>
The LCLK is 90 degree phase shifted relative to data, which is pretty nice
<azonenberg>
no the on chip part is hard
<azonenberg>
having fpga fabric at Fsample/2 (312.5 MHz) in a -1 artix
<Degi>
Why is that? what does it need to do
<azonenberg>
or 500 MHz for 1 Gsps
<Degi>
Hmh
<azonenberg>
What i think i will do longer term is move to a /4 or /8 serializer on the input instead of /2
<azonenberg>
and run the fabric side proportionally slower
<azonenberg>
Just have to throw together a PLL for that
<Degi>
pll?
<Degi>
To divide the signal by 2? (I mean you could use FFs too lol)
<azonenberg>
To get low timing skew, no
<azonenberg>
the idea is to have a divided by two that doesn't introduce additional phase delay
<azonenberg>
a divide by two*
<azonenberg>
BUFGCE_DIV is a thing in ultrascale (clock buffer with divider)
<azonenberg>
7 series doesnt have it
<azonenberg>
Easy enough to do, i just want to try and get the DDR version to make timing first because it's simpler
<azonenberg>
at least for early testing
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<azonenberg>
yeah my code is working, i think, but the LA is having trouble making timing
<azonenberg>
lol
* azonenberg
strips down LA more
<azonenberg>
Still can't get the LA to meet timing
<azonenberg>
guess i'm gonna have to do the /4 frontend instaed
<azonenberg>
Ended up switching to 8:1, wasn't any more work and is a nicer number to work with
<azonenberg>
now to do the bitslip alignment for fclk
<azonenberg>
hmmmm
<azonenberg>
I think i have some bit ordering problems still
<azonenberg>
Either that or i have signedness errors
<azonenberg>
oh derp
<azonenberg>
i forgot about the inversion :p
<azonenberg>
lain: so i think we are very close to first light on the ADC
<azonenberg>
We're sampling at 625 Msps in 8-bit mode for this test, the test signal is a 5 MHz squarewave so we should have a period of 125 samples
<azonenberg>
or just short of 16 FCLK cycles
<azonenberg>
I see periodicity in captured data at 15-16 cycles. So i just have to get the bit inversions right and i think we're good to go
<lain>
yay
<azonenberg>
Btw the test signal is passing through the AFE. So this is almost an end to end test, only thing remaining is the TCP side as the AFE is currently configured via FTDI dongle
<azonenberg>
and waveform data is being pulled off via JTAG
<azonenberg>
Got valid looking data off for a few clocks then the bitslip logic went haywire. Easy fix though
<azonenberg>
this is the 8 phases off the ADC, 8 bits @ 625 Msps
<azonenberg>
Other than the lack of a GPIO connector which would have been handy, the ADC board is looking perfect. No bugs, nothing to
<azonenberg>
nothing to fix
<azonenberg>
it just works
<azonenberg>
Still lots more work to do on the ADC control side as far as multi-lane, 12 bit, etc goes. But i think i may save that until I have a board with a stm32 and the adc on it
<lain>
:D
<azonenberg>
lain, Degi, electronic_eel: what are your thoughts on doing "fake analog triggering" in BLONDEL?
<azonenberg>
IOW, when doing level triggering interpolate between adjacent samples (either linear or some higher order curve fit)
<azonenberg>
and calculate a sub-sample position of the theoretical trigger
<azonenberg>
it's not going to be as good as a real TDC, but probably less trigger jitter than putting all triggers at the sample after the edge
<azonenberg>
also, even the BLONDEL prototype will be an interesting test for glscopeclient wrt number of WFM/s it will be pushing. I expect i'll need to do some software optimizations to keep up
<lain>
azonenberg: sounds handy
futarisIRCcloud has joined #scopehal
<_whitenotifier-9>
[starshipraider] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JfI0H
<_whitenotifier-9>
[starshipraider] azonenberg d7ad1ce - Removed echoing and escape sequence handling from SCPI parser since it's now intended to be accessed via line-buffered sockets and not as an interactive shell
<_whitenotifier-9>
[starshipraider] azonenberg pushed 1 commit to master [+5/-0/±5] https://git.io/JfI0j
<_whitenotifier-9>
[starshipraider] azonenberg 06a7f62 - Continued initial work on BLONDEL FPGA firmware for characterization board
<azonenberg>
as of now the functionality present is:
<azonenberg>
* Initialize ADC in one mode (8-bit full rate on channel 1), record ADC waveforms in ILA but can't do anything with them after that
<azonenberg>
* Respond to incoming pings and ARP requests
<azonenberg>
* Listen for TCP connections on port 5025, echo incoming data out a UART to the STM32 at 115.2 Kbps
<azonenberg>
There is no support for transmitting any TCP data other than ACKs, no external memory interface, etc
<azonenberg>
I think my next step is going to be finishing the TCP UART bridge which will necessarily involve finishing TCP transmit capability, buffer management, etc
<azonenberg>
Then once I have full control of the AFE via sockets, work on streaming waveforms
<azonenberg>
At that point i will be able to start writing a scopehal driver for the prototype
<azonenberg>
Still a few days out
juli963 has joined #scopehal
<Degi>
azonenberg: You can do bit slip on the HMCAD with SPI commands if youw anna
<Degi>
Niec
<Degi>
Huh your LA has more than 1 bit resolution it seems
<Degi>
That sampled data looks like no incoming signal tbh
<Degi>
Hm you can also change LSB/MSB first
<Degi>
(Default is LSB)
<Degi>
(0x53 lvds_advance and lvds_delay)
balrog has quit [Ping timeout: 260 seconds]
balrog has joined #scopehal
<azonenberg>
Degi: i have bitslip on the SERDES in the FPGA
<azonenberg>
just took me a few mins to write the code to align it
<azonenberg>
and no this isn't multi bit resolution
<azonenberg>
this is me visualizing the 8-bit serialized data coming off each lane
<azonenberg>
Degi: this is a pure digital capture off the FPGA. The squarewave just looks that nice on it :)
<Degi>
I dunno the waveform looked kinda analog
<azonenberg>
Degi: yes, because i'm rendering the 8-bit bus coming off the ADC driver
<azonenberg>
(this is a feature i want in scopehal soon)
<azonenberg>
this is after deserialization, bitslip alignment, and correcting for LVDS pair inversion on the pcb
<azonenberg>
i'm using the ISERDESE2 on the FPGA in 8:1 mode (no 12-bit support yet)
<azonenberg>
so the actual adc driver is quite simple. It's 450 lines of code total, a sizeable fraction of that is the LA and I/O declaration boilerplate
<azonenberg>
then 150 of that is the SPI register init code that i will be replacing with MCU firmware on the final board rev
<azonenberg>
Also, status update re the probe PCBs
<azonenberg>
my sales rep tells me that they're busy dealing with increased orders from medical device manufacturers and have been de-prioritizing non-essential customers as a result
<azonenberg>
expected ship date is now june 2nd
<azonenberg>
I have an open request to, if they can do it sooner, make me a mechanical dummy out of any FR4-esque material routed to shape with no drilling or copper
<azonenberg>
just for testing of enclosure designs
<azonenberg>
Waiting to hear back if they can fit that in the schedule sooner or not
bvernoux has joined #scopehal
juli has joined #scopehal
juli is now known as Guest15401
<bvernoux>
hello
<bvernoux>
finally I received quickly free replacement from mouser to my Thermoset Chip Glue "AD1-10S "
<bvernoux>
very nice service from Mouser
<bvernoux>
and the new one is not dried so all is good
<Degi>
^^
<bvernoux>
Mfg Date is a bit newer too 200312 => 2020 March 12
juli963 has quit [Ping timeout: 272 seconds]
<Degi>
Wasnt the other one from feb?
<bvernoux>
yes
<bvernoux>
totally dried very strange
<bvernoux>
Mfg Date on old one is 2020 Jan 8
<bvernoux>
anyway support of Mouser or other like DigiKey is always very good to have fast free replacement
<bvernoux>
it is also for that we pay so much their stuff ;)
<bvernoux>
-so much+too much ;)
<Degi>
Hm too much?
<Degi>
I mean more than ordering a few k from manufacturers but I find the prices pretty ok lol
<bvernoux>
the prices are crazy for some parts ;)
<bvernoux>
especially SMA or connectors
<bvernoux>
or MCU too
<Degi>
yeah compared to the cheap shit on ebay that rusts after half a year...
<bvernoux>
I speak about official ones ;)
<bvernoux>
which can be bought for 4time less
<bvernoux>
especially connectors
<bvernoux>
also MCU there is big differences
<Degi>
oh
<bvernoux>
yes compare them with LCSC ;)
<bvernoux>
and yes LCSC have genuine STM32
<bvernoux>
or other brand
<monochroma>
digikey's prices for dev boards is usually a lot higher than other distributors, in some cases 50-100% higher. mouser is usually cheaper for devkits and such
<bvernoux>
I do not speak about dev boards but more about raw components mainly CPU, Connectors
<bvernoux>
which are a bit too expensive
<bvernoux>
Especially SMA they are crazy expensive
<bvernoux>
for something up to 6GHz
<Degi>
lol
<bvernoux>
they cost more than 3USD per unit
<Degi>
Usually i buy them on ebay for 10 cents
<bvernoux>
I have found on AlieExpress some good SMA connector up to 3GHz ;)
<bvernoux>
for 0.2USD per unit ;)
<bvernoux>
tested with my VNA and they are stable and good for the price
<bvernoux>
at least up to 3GHz ;)
<bvernoux>
the worst I have bought was good up to 1.5GHz
<Degi>
Are they corrosion resistant?
<Degi>
Hmm I hope my SMAs arent that bad lol... How did they even manage that??
<bvernoux>
I suspect the gold plating is bad too ;)
<bvernoux>
but I have bought some genuine SMA at more than 3USD at DigiKey which was bad also over corrosion
<bvernoux>
so ...
<Degi>
oh
<bvernoux>
yes crappy gold plating ;)
<bvernoux>
even on genuine ones
<bvernoux>
we should have those SMA connectors for 0.5USD max
<Degi>
Didnt expect that tbqh
<bvernoux>
especially compared to price of other stuff like MCU ... which are more complicated to produce & test
<bvernoux>
I do not speak about stuff going to more than 6GHz ;)
<Degi>
I thought standard SMA could do 18
<bvernoux>
I have big respect for those stuff which cost more than 100USD but are done with ultra accurate machine ...
<bvernoux>
so that explain the price
<bvernoux>
Degi, a lot are just specified up to 6GHz
<bvernoux>
the basic ones
<Degi>
Hm what makes some SMAs more suitable for higher frequencies? The dielectric?
<bvernoux>
yes and also the accuracy for the fab
<bvernoux>
thinner center pin
<bvernoux>
well matched
<Degi>
What do you mean with one connector being bad at 1.5 GHz? Did it have -3 dB loss there?
<bvernoux>
So far I'm very happy with my Powell 142-0771-831 ;)
<bvernoux>
Bought for the price of bad SMA connector on DigiKey... ;)
<Degi>
18 $ on digikey?
<bvernoux>
they are a bit tricky to solder but now all shall be easier with Thermoset Chip Glue ;)
<bvernoux>
yes
<bvernoux>
I have bought them 3 time less directly from Powell ;)
<bvernoux>
and of course they are genuine
<bvernoux>
they are official reseller
<bvernoux>
anyway on my TRL board i need to solder 12 connector ;) so it start to be expensive even at that price
bvernoux1 has joined #scopehal
bvernoux1 has quit [Remote host closed the connection]
bvernoux is now known as Guest71830
bvernoux1 has joined #scopehal
bvernoux1 has quit [Remote host closed the connection]
bvernoux1 has joined #scopehal
bvernoux1 has quit [Remote host closed the connection]
marcos_ has joined #scopehal
bvernoux1 has joined #scopehal
Guest71830 has quit [Ping timeout: 260 seconds]
bvernoux1 is now known as bvernoux
maartenBE has quit [Ping timeout: 250 seconds]
marcos_ has quit [Quit: Konversation terminated!]
maartenBE has joined #scopehal
bvernoux has quit [Quit: Leaving]
<azonenberg>
Yay, paperwork issues around my meter are *finally* solved
<azonenberg>
It's shipping out today/tomorrow
<azonenberg>
hopefully it will get here same time as the VNA
Guest15401 has quit [Quit: Verlassend]
<electronic_eel>
azonenberg: you posted on twitter about your monitor failing
<electronic_eel>
did you take a look at the power supply board?
<azonenberg>
electronic_eel: basically what it comes down to is, i really don't have the time or inclination to debug it
<electronic_eel>
flickering backlight, random reboots looks to me very much like bad caps on the psu
<azonenberg>
i'm willing to unload it for little or nothing to anybody local who wants to try their hand at fixing it once i've bought a new one
<azonenberg>
i just want to keep this one staggering on a few more weeks if i can
<electronic_eel>
I have fixed dozens of monitors just by opening, replacing all electrolytics on the psu board, closing, done
<azonenberg>
as thanks to the VNA purchase i'm a bit tight on cash right now
<azonenberg>
my hope is to keep this one alive until i can buy two identical displays
<electronic_eel>
one set of new caps added to your next digikey order won't break the bank
<azonenberg>
yeah but that will mean taking the thing off my desk, movnig a bunch of stuff around, opening the back up, finding the caps, etc
<azonenberg>
it's downtime i dont really want to deal with
<electronic_eel>
was just a suggestion, since the symptoms sound to me just like the typical dry electrolytics thing
<azonenberg>
yeah it probably is. But like i said i also wanted to upgrade to a pair of identical displays and this seems like a good excuse
<azonenberg>
if i had the time/motivation to recap i'll give it to my wife or sell it or something
<electronic_eel>
so nice progress with the adc gateware
<azonenberg>
yeah i'm gonna try and finish most of tcp tonight
<azonenberg>
lets see how far i go
<electronic_eel>
cool, so scopehal driver coming soon
<azonenberg>
gonna be another couple days probably
<azonenberg>
and we still have to troubleshoot the low gain on the frontend
<azonenberg>
i suspect it's those series resistors that we don't actually need
<Degi>
Yes it is
<Degi>
Hm I'd keep them on the lines to the ADC maybe, though not really needed
<azonenberg>
i'm thinking it's on the LMH6522 side
<azonenberg>
but we'll see
<azonenberg>
anyway, first priority is getting full end to end control via scpi uart over tcp
<Degi>
We have a pair of resistors on each lmh
<Degi>
Yes ^^
<azonenberg>
then bridging the ADC out to the socket
<azonenberg>
Then writing a scopehal driver
<azonenberg>
And then further board level debug
<azonenberg>
the hardware is now alive enough that a scopehal driver is possible once i finish the tcp firmware