Russ Nelson's blog

[ Home | RSS 2.0 | ATOM 1.0 ]

Tue, 02 May 2006

Poor Protocol Design

Why do chip designers design poor protocols? You'd think that with the millions of dollars spent on a typical large chip design, they would at least ask a protocol designer how they're doing. But no, they have to design their own protocol, and frankly, they're chip designers, not protocol designers.

Here's the bee currently in my bonnet: The Intel 8254x Family of Gigabit Ethernet Controllers has microcode on board to clock bits out of the serial EEPROM containing the chip's configuration. That's fine. They even reuse that code by making it accessible via the PCI bus through a register. Unfortunately, the protocol design is wrong. They have an EEPROM Read Register with the following bit definitions:

Can you see the problem with this protocol? The microcode has to be faster than the CPU, otherwise you can have a race condition between the CPU and the microcode. If the CPU is faster, it can read the old DONE before the microcode has read START. Now, you might, as a chip designer say "Oh, but my chip is so sTuDlY that it will always read START before the CPU can read DONE!" That's foolish, since you can use a simpler design with a simpler protocol that has no race condition.

Use just one bit which indicates the "owner" of the register. When the bit is zero, the CPU owns the register, and is free to write a new EEPROM address. As it does so, it sets the bit, which indicates that the microcode owns the register. It leaves that bit set until it has read the EEPROM register, at which point it resets the bit back to zero.

No potential race conditions; simpler to describe; simpler to implement.

posted at: 20:22 | path: /opensource | permanent link to this entry

Made with Pyblosxom