amclain has quit [Read error: Connection reset by peer]
amclain has joined ##openfpga
Guest76540 has quit [Ping timeout: 245 seconds]
carl0s has quit [Quit: Leaving]
carl0s has joined ##openfpga
promach has joined ##openfpga
digshadow has quit [Quit: Leaving.]
pie__ has quit [Ping timeout: 240 seconds]
<rqou>
i just daisy-chained a power strip
<rqou>
should i feel bad?
<lain>
probably
carl0s has quit [Quit: Leaving]
<rqou>
and i just discovered that my walmart-grade shelving has a 15-degree lean
<rqou>
and i never noticed before
_whitelogger has joined ##openfpga
DocScrutinizer05 is now known as lollita
lollita is now known as DocScrutinizer05
indy has quit [Ping timeout: 260 seconds]
indy has joined ##openfpga
amclain has quit [Quit: Leaving]
JvD__ is now known as JvD_
<azonenberg>
rqou: your ESR is bad and you should feel bad :p
<azonenberg>
also just assembled the characterization board for the STARSHIPRAIDER I/O buffer
<fpgacraft1>
<laincat> woo
<davidc__>
azonenberg: STARSHIPRAIDER? that your greenpak work?
<rqou>
I just turned on the microwave in my apartment!
<rqou>
fire in 3... 2...
<rqou>
:P
<rqou>
btw if someone other than me wants to reverse engineer a Broadcom switch, the eBay Quanta LB4M devices include some interesting information in their firmware
<rqou>
unfortunately it's a very old part
<azonenberg>
davidc__: No
<azonenberg>
This is the "bus pirate on steroids" project i've had back-burnered for a while
<azonenberg>
however, it will contain greenpak devices in the front end (it mates with the devkit for now) for level sensing etc
<azonenberg>
this will be my first production-y deployment of a greenpak
<rqou>
right we still need to hash out how the module interface will work
<azonenberg>
rqou: see pcb pr0n
<rqou>
unfortunately I'm currently stuck deep in the middle of the "unpack from 33C3 and clean my room" project
<rqou>
also gruetzkopf thanks for the Cisco console cable, works great
<rqou>
yay, finished microwaving without a breaker trip
<rqou>
hmm, i just realized my computer is using networkmanager for its wired connection and i have no idea why
<davidc__>
azonenberg: cool; I've been meaning to build one of those. Source/Schematics anywere? (I might help, if you want some)
<rqou>
wow apparently everybody has their own secret "bus pirate on steroids" project
<fpgacraft1>
<laincat> lol
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
<azonenberg>
davidc__: azonenberg/starshipraider is the github repo but for now its only the characterization board
<azonenberg>
Target specs are as follows
<azonenberg>
Four socketed I/O modules
<rqou>
i also had a project nicknamed "bus armada" that we're going to soon figure out how to duct-tape together
<azonenberg>
Each of the standard I/O modules can process eight single-ended inputs at up to 800 MSa/s, or use any of those same signals as outputs up to 250-500 MSa/s (depending on voltage)
digshadow has joined ##openfpga
<azonenberg>
Operating voltage range is 0 to 5V
<azonenberg>
I/O modules are fully specified as tolerant to +/- 12V for an indefinite time period, however the channel (and possibly the adjacent channel depending on how my final layout works) will tri-state to protect itself and not be usable until the fault is cleared
<azonenberg>
The main board will be an artix-7 in FGG484 that contains a SODIMM of DDR3
<azonenberg>
gigabit and optional 10gbit ethernet for talking to the host PC
<davidc__>
heh, thats a pretty fast frontend
<azonenberg>
FPGA contains a 32-channel GPIO module, a 32-channel LA, a crossbar switch, and a bunch of IP blocks for things like I2C, SPI, JTAG, UART, etc
<azonenberg>
800/500 Mbps *and* 5V operation *and* +/- 12V tolerance is VERY nontrivial
<azonenberg>
lol
<azonenberg>
Hence why i had to prototype the I/O cell to make sure it actually worked
<azonenberg>
i just assembled the board and havent tested
<azonenberg>
obvs the real thing won't be loaded with SMAs :p
<azonenberg>
My goal is to be able to sniff/MITM/generate any digital protocol commonly used in embedded devices other than DRAM
<azonenberg>
Inputs are comparator based so you can specify a threshold per bank and work with any input standard you want up to 5V
<azonenberg>
Output voltage in the test board is supplied on a header, in the real thing it will be a variable SMPS that has a set point either set over the IP interface or tracking an external VCCO reference (but not drawing current from it)
<davidc__>
yup. My goal was pretty similar, but about an order of magnitude slower
<azonenberg>
The design is scalable
<azonenberg>
There's no reason you couldn't make a pin-compatible host board that maxes out at say 100 MSa/s inputs and stores data in block ram only, and has gig-e or usb 2.0 as the host interface
<azonenberg>
Or a much less expensive I/O cell that doesn't use a $6 comparator on every channel
<davidc__>
TBH, I haven't come across many things faster than 100Mbaud that I didn't want to build a custom interface for anyhow
<azonenberg>
Well, I wanted to be able to oversample things i dont have a clock for
<azonenberg>
100 Mbps data needs ~400 MSa/s to reliably decode without a clock
<azonenberg>
Also, suppose you dont know which signal is a clock
<azonenberg>
i want to be able to drop probes down on whatever
<azonenberg>
then figure it out ex post facto
<azonenberg>
once you have the FPGA and RAM, sampling fast is trivial - there's no reason not to
<azonenberg>
the big challenge in my i/o cell was the wide voltage range
<azonenberg>
also "custom interface"
<azonenberg>
the eventual plan is to support partial reconfig (or at least runtime bitstream loading) so you can drop custom interface IP into the FPGA for a special protocol
<azonenberg>
Some of the I/Os will be usable as sampling clocks too, thats TBD once me and rqou figure out the exact pinout between I/O modules and the host board
<azonenberg>
most likely going to be a samtec q-strip
<azonenberg>
maybe 30 pins
<azonenberg>
My recommendation is that we all try to make our projects compatible and scalable as much as possible
<azonenberg>
There's no reason you cant make a lower speed version, but it should be plug-and-play with the faster and slower components
<azonenberg>
In any case, this is something i expect to be using on a daily basis both at work and in my home lab
<azonenberg>
So i can justify the engineering time and cash to go all out
<davidc__>
I mean, fair enough. I wouldn't tell you not to overengineer stuff; especially since given how often I do the same, it'd be hypocritical
<azonenberg>
The initial inspiratio nof the project
<azonenberg>
was when i killed a 1.8V flash chip not realizing the dumper i was using didn't go below 3.3
<rqou>
azonenberg: dumb question, does 10gbe have the concept of "jumbo frames?"
<azonenberg>
or when i got tired of looking for 2.5V FTDI dongles when all i could find is 3.3
<azonenberg>
rqou: jumbo frames etc are done at the link layer
<azonenberg>
1 vs 10gig etc is all physical
<davidc__>
I guess I just usually have such a different probing strategy for high speed stuff (IE: micro coax + tap + amplifier) vs lower speed stuff
<rqou>
and if i change my mtu what happens when i try to talk to a 1500-only device?
<azonenberg>
the link layer is exactly the same
<azonenberg>
If you change your mtu the device is likely going to drop the packets or just get very confused
<davidc__>
that by the time I get wires attached to the board I usually know my voltage ranges / signalling speeds
<rqou>
great
<azonenberg>
rqou: i just run 1500 everywhere
<azonenberg>
jumbo frames are kind of a hack IMO
<azonenberg>
like, trying to get a few percent more throughput
<rqou>
i assume my old 10mbps/half device won't like 9000+ byte packets very much :P
<azonenberg>
when you really should just roll out 10gig
<rqou>
right now i'm trying to set up a 10gbe to a switch with 48 1gbe ports
<azonenberg>
davidc__: well thats the point, i want one tool flexible enough to do everything
<azonenberg>
the plan is for the I/O boards to have a samtec q-strip that you can break out to anything from SMAs to 0.1" headers
<azonenberg>
depending on how fast the DUT is etc
<davidc__>
azonenberg: I mean, fair enough :). Good luck with it!
<azonenberg>
And if i slip and probe the wrong pin
<azonenberg>
and hit actual RS-232 levels
<rqou>
azonenberg: do you consider running 802.1q tagged frames to linux a hack?
<azonenberg>
or a +12V rail with ground on a signal pin b/c i screwed up the pinout
<rqou>
it seems the normal scripts aren't really set up to work that way
<azonenberg>
it doesnt have to *work*
<azonenberg>
but it has to survive
<azonenberg>
rqou: i run .1q to my desktop
<azonenberg>
i have one subif to the DMZ that's bridged to some of my VMs
<azonenberg>
one on the main R&D network
<azonenberg>
and one on the sandbox network that goes straight to my FPGAs and devkits and doesnt route anywhere else
<rqou>
yeah i'm trying to make something like that
<rqou>
except with a cheapo undocumented switch
<azonenberg>
Lol
<azonenberg>
i'm using a $150ish ebay'd cisco 2970G
<azonenberg>
planning to eventually replace with a homebrew but that's a long ways out
<rqou>
i'm using an iirc <$100 lb4m whitebox thingy
<rqou>
the fans are super loud unfortunately
<rqou>
i'm still trying to figure out how to even set up the management interface
<azonenberg>
do yourself a favor and get a secondhand cisco
<azonenberg>
it'll be backdoored by NSA instead of the chinese gov so no big win one way or the other
<azonenberg>
but you'll be able to get docs, a cli, etc
<rqou>
i have docs, they just don't match my fw
<rqou>
and i have a cli via a serial port
<fpgacraft1>
<laincat> just get an ubiquiti edgeswitch or edgerouter :P
<rqou>
huh, apparently the ixgbe driver is magic: "8021q: adding VLAN 0 to HW filter on device eth2"
<rqou>
someone actually wrote the code to make the modules talk to each other! wow!
<rqou>
it's almost like the ixgbe driver actually needs to be used by _real_ companies!
<rqou>
unlike some ralink/asix crap
<davidc__>
heh... don't overrate intel linux drivers. There's plenty of crap in there as well :)
<rqou>
like the sfp whitelist? :P
<davidc__>
rqou: or any of the SFP code
<azonenberg>
sfp whitelisting is just stupid
<azonenberg>
with cisco gear at least you can service unsupported-transceiver
<rqou>
heh, ixgbe afaik allows all DA cables
<azonenberg>
and it works
<rqou>
which is what i'm using
<rqou>
the ixgbe driver has a similar flag too
<rqou>
let's be honest, they're all finisar in the end :P
<davidc__>
but thats partly the fault of the SFP vendors
<davidc__>
I had the joy of digging around in SFP EEPROMs a while back to try and sort out some detection/link setup code.. and holy crap are SFP vendors bad at following standards
<rqou>
i thought you didn't have to deal with that at all if you didn't want to?
<azonenberg>
The ones i dumped a while ago when tinkereing all made sense
<davidc__>
A bunch of the vendor markup on the original finisar part is probably "putting a valid/accurate/WITH OUR STUPID QUIRKS" eeprom image on it
<azonenberg>
But yes you can ignore the eeprom most of the time
<rqou>
you would just spit a serial stream into the high speed pairs?
<azonenberg>
rqou: thats what i did in my 1g core
<davidc__>
rqou: you do if you're dealing with "copper" SFPs
<azonenberg>
i just assume i have a 1000base-* sfp attached
<azonenberg>
spit stuff out and see what comes back
<azonenberg>
eeew copper sfp
<rqou>
why eeew?
<davidc__>
Some copper SFPs take 1000-X, Some do SGMII, which is 1000-base X + some in band signalling
<rqou>
not nearly as weird as what i saw at broadcom
<rqou>
4x sgmii on a qsfp
<davidc__>
Anyhow, end result of all of the above; after looking at a bunch of SFPs that might end up plugged into the HW
<davidc__>
the only sane answer was "make a whitelist by vendor/model" and "fall back on trying what the EEPROM says with a big warning"
<rqou>
why can't it just be "ignore what the eeprom says, send data blindly?"
<rqou>
you only get screwed when somebody does something stupid like 10gbase-W
<davidc__>
rqou: because then you end up with a copper phy that will happily autonegotiate to 100baseT (this is for HW that needs to interop with possibly legacy systems)
<davidc__>
while the host is blindly assuming that its still a 1000baseT link
<rqou>
just don't support that? :P
<davidc__>
rqou: product requirement for that particular piece of HW
<rqou>
broadcom internal hw just fixed this by putting mdio onto an rj-11 jack so that you can poke the copper phy
<rqou>
the rest of it became the customer's problem :P
<rqou>
in general copper phys sucked
<rqou>
optical works much better
talsit has quit [Ping timeout: 240 seconds]
talsit has joined ##openfpga
cr1901_modern has quit [Ping timeout: 240 seconds]
massi has joined ##openfpga
cr1901_modern has joined ##openfpga
<nats`>
azonenberg, let's talk when you're back from your night :)
<nats`>
lot of changes going on on my side
<nats`>
but I should end up in a new company with an even more impressive lab and not against open source project :)
kuldeep has quit [Ping timeout: 240 seconds]
<rqou>
wow the vlan settings on the lb4m are totally dumb
<rqou>
but it does work
<rqou>
unfortunately /etc/network/interfaces is still totally screwed
<rqou>
also i forgot how really slow 10/half really is
<davidc__>
rqou: you're just using the stock lb4m firmware? or is this something custom/hacked?
<rqou>
stock
<rqou>
even if i had something hacked i can't legally release it
<davidc__>
eh; sure; well unless you'd done a linux port or something
<rqou>
i don't think i can legally release that either
<rqou>
i did an internship at broadcom
<davidc__>
Oh, heh, right broadcom
<rqou>
on the switch team
<davidc__>
Do they offer post-internship PTSD counselling?
<davidc__>
;)
<whitequark>
lol
<rqou>
heh, i was on the "deal with customers" team too
<rqou>
blarrgh the tds3054 web gui is useless
<rqou>
whatever, it's connected so i'll figure it out some other day
<davidc__>
rqou: I actually designed with some of BCMs silicon ~10yr ago. It wasn't too bad, but getting datasheets was like pulling teeth. Vitesse (RIP) got the socket just because they would pick up the phone
<rqou>
heh, my father designed with bcm silicon around that time as well
<rqou>
it was similarly bad
<rqou>
anyways, apparently the tds3054 has a bajillion layers involved that eventually lets you tunnel gpib commands over ethernet
<rqou>
i don't know what the bajillion layers in the middle is for though