Live data from Hacker News

Designing an Ethernet Switch ASIC

essenceia.github.io

61–62 of 62 posts

Re: Designing an Ethernet Switch ASIC

#61
post #51

Earlier quoted context omitted.

It's easy enough to write a bit of Verilog to perform partial updates on the CRC to only compensate for what has changed. I did so for an FPGA project I implemented a number of years ago when processing VLAN tags and doing IP forwarding. That said, there are lazy hardware designers that just slap on a block to recompute the CRC and replace the old one with the new. An experience I had years ago at Red Hat taught me t…

Wow that rings a bell. The lack of end to end ECC protection in some packet paths on very high end ASICs is something I just can’t get over.

ECC tends to be too expensive to be used widely in hardware data paths. Most of the time hardware will use a parity bit as checking it is far less costly (both in terms of gates and power). Parity bits are usually sufficient, as the purpose is really limited to identifying hardware failure. The CRC should prevent delivery of a corrupted packet provided the hardware doesn't cheat and blindly recompute it.

Re: Designing an Ethernet Switch ASIC

#62
post #61

Earlier quoted context omitted.

Wow that rings a bell. The lack of end to end ECC protection in some packet paths on very high end ASICs is something I just can’t get over.

ECC tends to be too expensive to be used widely in hardware data paths. Most of the time hardware will use a parity bit as checking it is far less costly (both in terms of gates and power). Parity bits are usually sufficient, as the purpose is really limited to identifying hardware failure. The CRC should prevent delivery of a corrupted packet provided the hardware doesn't cheat and blindly recompute it.

ECC is _not_ too expensive to use in hardware data paths. The existence proof of this is almost every medium to high end NPU has end to end ECC.
Post reply on HN