The author's example about a huge multitude of ethernet drivers doesn't really map well to the solution suggested (i.e. A big blank slate of FPGA logic with a bunch of ADC/DAC/codec fabric on the chip periphery). The wire side of Ethernet is really well specified, and tightly implemented. (Your chip won't be 802.3 compliant if it's not!) That's a result of really good specs on the IEEE's part. They put a TON of time into detailing how the Ethernet physical layer talks chip-to-chip. The driver side implementation for Ethernet, however, is basically the wild fucking West.
There are cases where the author's approach makes sense - software defined radio jumps to mind. Adding one more layer of abstraction to ethernet drivers isn't one if them. That seems like an area where software could learn from hardware - namely, that good specs drive good implementations.
There are cases where the author's approach makes sense - software defined radio jumps to mind. Adding one more layer of abstraction to ethernet drivers isn't one if them. That seems like an area where software could learn from hardware - namely, that good specs drive good implementations.