Engineer struggles when developing fiber optic inter-repeater link chipset from scratch using discrete components
In the late 1980s my employer decided to jump on the hot Ethernet
bandwagon and manufacture LAN (local area network) hubs using the
then-new 10BaseT technology. At the time Ethernet cabling was moving
away from thick vampire-tapped RG-8 coaxial cable and thin RG-58 BNC
Tee coaxial cable, to be replaced with unshielded twisted pair (UTP)
cable between each remote access point (desktop PC) and local
concentrators, or hubs.
A typical hub resided in a wiring closet and
was nothing more than a multi-port Ethernet repeater. Network expansion
was accomplished by interconnecting hubs with fiber optic cables based
on the IEEE 802.3 FOIRL (Fiber Optic Inter-Repeater Link)
My assignment was to design and develop the fiber optic hardware. This
was about a year before the Micro Linear ML4661/4621 FOIRL chipset
became available, thus I had to build it all from scratch using
discrete components. Armed with the 802.3 FOIRL specification, I jumped
in feet first and attempted to learn how to do it.
One of the more difficult hurdles was how to generate the 1 MHz
inter-packet idle signal required to keep the optical link alive
between data packets. The FOIRL specification was picky about this in
regards to frequency tolerance and specific pulse width on the first
cycle at the start of the idle signal when the packet ended. Simply
dividing a local 20 MHz clock to 1 MHz had the potential for
metastability problems since the packets were asynchronous, and the
synchronous recovered packet clock ended along with the packet.
decided that the easiest way was to start up a 1 MHz oscillator at the
end of the packet, but I had to design it in such a way that our
production test people did not have to tweak the frequency (adds labor
cost). I was also very concerned about the constraints on that first
cycle: what sort of oscillator could be started up with the first cycle
I finally settled for an off-the-shelf digital delay line fed back to a
logic gate. Enabling the gate launched a logic transition into the
delay line and started a nice oscillation with a good first cycle and
well within the needed frequency tolerance without having to tweak. It
worked nicely. Well, almost nicely. It had a little problem.
While testing the first prototypes, I discovered that disabling the
oscillator gate then re-enabling while the pulse was still rippling
down the delay line would cause additional short pulses to propagate
down the delay line at the same time. The result was sustained
oscillation at the third harmonic. Oops!
Now what were the chances of this happening in real life? A brief noise
hit on any twisted pair port could cause this. So I added a latch to
the oscillator to ensure that only one pulse could travel down the
delay line at one time. This worked nicely and cured the third harmonic
But during my struggles with that ornery oscillator, I noticed
something else that did not seem right. The repeater chip receiving the
faulty 3 MHz signal interpreted this as an uncontrolled
continuous transmission from a faulty remote unit. As long as this
jabber remained active into a port on the hub, every other UTP port on
that hub would self-disable upon receipt of a data packet, until the
only port left enabled was the port receiving the jabber.
Notwithstanding an actual hardware fault, what a neat way for a
malicious hardware hacker mad at his boss to anonymously clobber a
company network with a crystal oscillator and a battery!
Took a long look at the 802.3 repeater specification functional
flowchart. In the top left was an innocuous little block that said
something along the lines of "wait for end of transmission before doing
anything more." Another oops! This function made perfect sense when the
transmission medium was a shared coaxial cable, a jabbering transmitter
wipes out all communications on the one cable anyway. But the move to
individual port UTP cable should have eliminated this problem,
unfortunately the 802.3 repeater spec had not yet caught up.
company management and the repeater chip manufacturer about this
problem, which by the way did not show up on a competitor’s product,
which did not completely follow the 802.3 spec. The repeater chip
manufacturer made the required change on their next spin as an option
to eliminate the problem. My managers told me to keep quiet about this (in other words do not report this to IEEE if you want to keep your job)--they did
not want this glitch in our product to be publicized.
A couple years later the company downsized while on its way to
bankruptcy, I was laid off, and subsequent career positions had nothing
more to do with Ethernet.
A few years ago I did have the opportunity to read a more recent 802.3
repeater spec. That little “wait” block had been removed. I suspect
that the repeater chip manufacturer might have reported the problem and
got the 802.3 repeater spec fixed.
Glen Chenier is a design consultant based in Allen TX.