3 ms·

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 b

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.

donlzx 10y ago
AFAIK, the digital interface of the physical layer (PHY) of the Ethernet stack are pretty much standardized (MII/RMII/GMII/RGMII). Most SOCs implement their own MAC layer, but are usually compatible with off-the-shelf PHY chips. The function and interface differences in proprietary MAC implementation is where the complexity of the kernel driver comes from. Suppose that we also standardized the interface between the MAC layer and the kernel and add an FPGA inside the existing PHY chip which is opened to real-time programming, a ton of optimization can be done. For example, DDOS packets could be thrown away well before reaching the kernel space. Previously I had done that with some low-cost FPGA kits, with less than 1K of HDL codes, it could get out only the IP packets wanted and then pass the packets directly to the application layer via the memory interface between the embedded CPU and FPGA logics. I think a programmable network interface is well worth the money if we care enough for openness and efficiency.
- cushychicken 10y ago
  You're right - MII and it's derivatives are fairly standard. I agree that the MAC -> CPU interface is the root of a lot of the complexity that the author writes about. However, that still sort of serves to illustrate my point: the software to interface with the MAC is the chunk that introduces the most variability. Standardize that and a lot of your problems are solved. Integrating a bunch of analog/digital/vice versa fabric onto the same die is not a tenable solution to this particular issue. I'll admit the concept is mildly intriguing, but I think you'd find quickly that the silicon demands for a DAC/ADC of the quality needed to emulate any high speed waveform are a little out of reach fab wise. Too much space, not enough drive speed.

donlzx 10y ago

AFAIK, the digital interface of the physical layer (PHY) of the Ethernet stack are pretty much standardized (MII/RMII/GMII/RGMII). Most SOCs implement their own MAC layer, but are usually compatible with off-the-shelf PHY chips. The function and interface differences in proprietary MAC implementation is where the complexity of the kernel driver comes from. Suppose that we also standardized the interface between the MAC layer and the kernel and add an FPGA inside the existing PHY chip which is opened to real-time programming, a ton of optimization can be done. For example, DDOS packets could be thrown away well before reaching the kernel space. Previously I had done that with some low-cost FPGA kits, with less than 1K of HDL codes, it could get out only the IP packets wanted and then pass the packets directly to the application layer via the memory interface between the embedded CPU and FPGA logics. I think a programmable network interface is well worth the money if we care enough for openness and efficiency.

cushychicken 10y ago
You're right - MII and it's derivatives are fairly standard. I agree that the MAC -> CPU interface is the root of a lot of the complexity that the author writes about. However, that still sort of serves to illustrate my point: the software to interface with the MAC is the chunk that introduces the most variability. Standardize that and a lot of your problems are solved. Integrating a bunch of analog/digital/vice versa fabric onto the same die is not a tenable solution to this particular issue. I'll admit the concept is mildly intriguing, but I think you'd find quickly that the silicon demands for a DAC/ADC of the quality needed to emulate any high speed waveform are a little out of reach fab wise. Too much space, not enough drive speed.