<azonenberg>
So i just figured out the high level architecture of a product AND exactly which xilinx FPGA (well, one of two) it was using. Based entirely on the specs on the catalog page
<azonenberg>
It's actually a really clever design
<sorear>
transceiver count?
<azonenberg>
more than that
<azonenberg>
So, the product is the LeCroy HDA125. It's a 12.5 Gsps 18-channel logic analyzer that connects to a host oscilloscope via an "LBUS" link which contains usb 3.1, a reference clock, a trigger, and maybe some other random stuff
<azonenberg>
I know they're a Xilinx shop
<azonenberg>
i figured based on the rough price and age that they're using a kintex-7
<azonenberg>
12.5 Gsps is also a pretty good indication as that's Fmax of the transceivers in -3 speed on a FFG package
<azonenberg>
i dont think any other xilinx product line has 12.5 Gbps Fmax on anything
<azonenberg>
So, knowing they have at least 19 transceivers (18 for inputs and 1 for USB) means they're using the xc7k355t, 420t, or 480t in FFG901, or the 420/480 in FFG1156
<azonenberg>
which have 24, 28, 28, 32, 32 transceivers respectively
<azonenberg>
i ruled out the 1156 because i saw no reason for them to pay more for a bigger pacakge just to get 20 more GPIOs, and one extra transceiver quad they weren't gonna use
<azonenberg>
So that left the 355, the 420, and the 480 in ffg901
<azonenberg>
But i was confused as to why 18 channels when they had 24/28 transceivers. if they used one quad for usb3 they'd have 20/24 available for LA inputs, and even some of the usb3 quad was probably usable for LA
<azonenberg>
So i started thinking about how i'd build my own LA using an FPGA SERDES
<azonenberg>
there's an input to the GTX that lets you pause the CDR loop, essentially no longer doing phase shifting based on the input data and just having the CDR run at a constant phase angle to the SERDES quad PLL
<azonenberg>
The problem is, if you have multiple quads how do you phase them to each other? The quad PLLs are all sharing the same refclk but are potentially phase shifted from each other
<azonenberg>
then i realized what they're doing and it's genius
<azonenberg>
They're using *three* channels per quad as LA inputs
<azonenberg>
And one as a refclk
<azonenberg>
every quad oversamples a common refclk at 12.5 GHz, so 80ps per sample
<azonenberg>
and by finding the positioning of the edges, you can correctly phase all of the quads' sampling clocks to each other
<azonenberg>
So that means they're using six quads as LA inputs and one for usb3, which rules out the 355t
<azonenberg>
thus, they're using the 7k420t or 480t in -3 speed, ffg901
<sorear>
no possibility of a wide/low baudrate USB3 interface?
<azonenberg>
that would be ridiculous
<azonenberg>
i dont even know if such phys exist
<sorear>
is xgmii ridiculous?
<azonenberg>
Yes
<azonenberg>
when the fpga already has fast enough transceivers, upgrading to one that has a few more is obviously the way to go
<azonenberg>
the multiple-of-3 channel count is really what gave it away to me though
finsternis has quit [Ping timeout: 240 seconds]
finsternis has joined ##openfpga
lutsabound has quit [Quit: Connection closed for inactivity]
GenTooMan has quit [Read error: Connection reset by peer]
GenTooMan has joined ##openfpga
Bike has quit [Quit: Lost terminal]
bwidawsk has quit [Quit: Always remember, and never forget; I'll be back.]
bwidawsk has joined ##openfpga
X-Scale` has joined ##openfpga
X-Scale has quit [Ping timeout: 268 seconds]
X-Scale` is now known as X-Scale
edbordin has joined ##openfpga
____ has joined ##openfpga
Bob_Dole has quit [Ping timeout: 260 seconds]
edbordin has quit [Ping timeout: 260 seconds]
diadatp has quit [Ping timeout: 265 seconds]
diadatp has joined ##openfpga
diadatp2 has joined ##openfpga
diadatp has quit [Read error: Connection reset by peer]
azonenberg_work has quit [Ping timeout: 260 seconds]
diadatp2 has quit [Ping timeout: 260 seconds]
diadatp has joined ##openfpga
Bob_Dole has joined ##openfpga
Bob_Dole has quit [Ping timeout: 265 seconds]
Asu has joined ##openfpga
OmniMancer has joined ##openfpga
freemint has quit [Ping timeout: 260 seconds]
<tnt>
ERROR: IO pin 'iob[72]' constrained to pin 'T3', which does not exist for package 'CABGA381'
<tnt>
That's strange, it's definitely not the special CLK pins from SPI.
<daveshah>
I think there was a weird special case pin that isn't supported (something like DONE)
<tnt>
This one is 'WRITEN'
<daveshah>
Oh, hm, I'd need to look into that
<tnt>
It's used in those ECP5 board from ali-express.
<daveshah>
It will probably need some Trellis and nextpnr changes to work
<tnt>
(at least I'm pretty sure it's used ... that's the only pin I'm missing and it would "make sense" from the other nearby pins)
edbordin has joined ##openfpga
<omnitechnomancer>
cursed pin
diadatp has quit [Ping timeout: 265 seconds]
diadatp has joined ##openfpga
<edbordin>
omnitechnomancer I am now realising this fuzzing will take days on my laptop. maybe it would be more sensible for me to just wait for you to upload it
sgstair_ has joined ##openfpga
diadatp has quit [Ping timeout: 265 seconds]
esden has quit [Read error: Connection reset by peer]
bubble_buster has quit [Ping timeout: 258 seconds]
esden has joined ##openfpga
bubble_buster has joined ##openfpga
mithro has quit [Write error: Connection reset by peer]
mithro has joined ##openfpga
sgstair has quit [Ping timeout: 258 seconds]
ovf has quit [Ping timeout: 240 seconds]
ovf has joined ##openfpga
diadatp has joined ##openfpga
diadatp has quit [Ping timeout: 268 seconds]
diadatp has joined ##openfpga
OmniMancer has quit [Quit: Leaving.]
OmniMancer has joined ##openfpga
OmniMancer has quit [Client Quit]
<omnitechnomancer>
edbordin I'll try to get to uploading it tomorrow
<ZirconiumX>
I mean, fuzzing takes forever anyway, no matter the target
diadatp has quit [Ping timeout: 258 seconds]
diadatp has joined ##openfpga
diadatp has quit [Read error: Connection reset by peer]
<vup>
daveshah: great work on the nextpnr-xilinx stuff; I just saw that you merged zynq 7020 support, what is missing for zynq 7010 support?
<daveshah>
I forked Xray to support 7020, as that's what I had
<daveshah>
In theory upstream Xray should support 7010, but I think some of the files nextpnr needs (gridinfo and tile jsons for some of the IO related tiles) are missing
<daveshah>
I can probably hack together a 7010 db for you to try if you are interested
<vup>
yeah, that would be great
<mwk>
7010 is... special-ish
ym has joined ##openfpga
<mwk>
for some reason the grid is different around the hard CPU than for all other zynqs
<mwk>
though I think that's just the property of Vivado's/ISE's representation, not of actual chip
<vup>
interesting
<daveshah>
I don't _think_ that affects nextpnr - 7020 seems to work fine despite the fact Xray is currently targetting 7010
<daveshah>
vup: what package are you interested in?