<azonenberg_work>
Because there is currently no good way to send data from a PC to an FPGA/ASIC in a structrured form without writing two separate implementations of the protocol
<azonenberg_work>
protobufs solve this problem for e.g. C to java
<azonenberg_work>
one of the reasons libjtaghal's socket protocol currently doesn't use protobufs is that i wanted it to be FPGA-parseable
<azonenberg_work>
so STARSHIPRAIDER could implement it
<azonenberg_work>
and i didnt want to write a custom protobuf parser on one side and then use a .proto on the other
<azonenberg_work>
so i want to write the FPGA parser generator once and be done with it
<rqou>
why not bson or some other binary-json format?
<rqou>
also, a while back a friend and i designed a custom DSL for essentially this purpose
<azonenberg_work>
It'll take in 8 bits at an arbitrary clock rate, at 250 MHz that's 2 Gbps and most 7-series etc parts can go even faster
<rqou>
but it _sucked_ to use because we used yaml and it was way too verbose
<azonenberg_work>
So it wont be able to max 10G but it'll be able to saturate gig or run several fat flows over a 10G pipe
<rqou>
we didn't have fpga support of course
<azonenberg_work>
And for my 10G applications i mostly expect a low bandwidth control channel on one socket using protobufs
<azonenberg_work>
and then a high bandwidth data channel that's just (say) raw I/Q
<azonenberg_work>
no parsing needed
<azonenberg_work>
this is explicitly intended for PC-to-FPGA comms over a LAN
<azonenberg_work>
but it could work over pcie etc too
<rqou>
IIRC i looked at protobufs and didn't like using it
<azonenberg_work>
I have a good idea for how the parser will be structured
<azonenberg_work>
i just have to implement
<azonenberg_work>
Wanted to get the repo up so i could make some wiki notes and design stuff then implement later
<azonenberg_work>
My eventual plan is for all of starshipraider's virtual instruments to provide a .proto
<rqou>
yeah, varints are a pain to decode, that was a big reason i didn't go with protobufs
<azonenberg_work>
so you can talk to them over a lan from an arbitrary language
<rqou>
my friend and i basically wanted "take c struct declarations (without the need for forward declarations) and generate parsers in scripting languages"
<rqou>
but we didn't want to write a c parser and used yaml instead, big mistake
<azonenberg_work>
lol
<azonenberg_work>
I'm actually hoping i can split this up so i have a parser generator, a .proto wire format parser, and a .proto text file parser
<azonenberg_work>
So i can reuse the backend to create a parser for, say, TCP
<azonenberg_work>
or IP
<rqou>
oh yeah, another reason i disliked proto was that its wire types aren't great
<rqou>
i basically never want varint, and i wanted a lot of u8/u16
<rqou>
azonenberg_work: what's mii "MAC mode" vs "PHY mode?"
<rqou>
oh nvm, that's some quirk specific to _MII_, not RMII/RGMII
<azonenberg_work>
Unlike GMII, MII uses one clock for both buses
<azonenberg_work>
So it probably specifies who drives it
<azonenberg_work>
GMII is source synchronous and the only real difference is who drives the MDIO bus (if it's even used)
<rqou>
if i use rgmii between an fpga and a switch, can i force it to "always gigabit?"
<rqou>
now i get "tri-speed support" for "free" :P
<azonenberg_work>
Yes you can autonegotiate to gig
<azonenberg_work>
and say you dont support 10/100
<azonenberg_work>
a sane switch should do that just fine
<rqou>
apparently this switch can't negotiate on the rgmii port
<rqou>
the rgmii port is set by a strap
<azonenberg_work>
Lol
<azonenberg_work>
That works too then
<rqou>
of course, the baseT ports do
<azonenberg_work>
Force to gig and call it good
<azonenberg_work>
I guess that makes sense actually
<rqou>
and the switch will buffer packets for me
<rqou>
i think?
<sorear>
do the common binary-JSON formats guarantee field sorting? I notice that protobuf doesn't
<rqou>
can't you just apply the jwt field sorting while encoding if you want that?
<rqou>
hrm, i swear jws/jwt/jose defined a way to sort fields in an object, but apparently not??