Wow! If you're unsure why Ethernet should be regarded
as a sophisticated bus architecture, maybe I can point
out a few things to change your mind. Not that I am
advocating you use any of these techniques, but I do
find it interesting to see what solutions people have
come up with to solve difficult bus problems. As you contruct
busses which are longer and longer in relation to the
clock period you may find yourself using one or more
of these techniques. (By the way, I can't claim that
Ethernet in particular invented any of these techniques,
only that it is an example of a system that uses them).
These comments apply to the original Ethernet 10BASE-5
"thick coax" system.
[The 10BASE-5 system permits direct connection of over 100
devices to a single, shared coaxial cable. It's a true
multi-drop bus: any device can transmit at any time,
however, only one device can SUCCESSFULLY communicate
at any given time. ]
(1) 10BASE-5 is an extremely well-terminated
bus with first-incident-wave swtiching. Constraints
were implemented on the variations in the coaxial impedance,
the capacitance of the connector technology used to implement
the taps, the capacitance of the transceivers, and the accuracy
and efficacy of the terminations to
guarantee excellent signal quality under worst-case conditions.
Once your bus length exceeds one clock period (or
a suitable fraction of a clock period) the bus is
forced into having to provide first-incident-wave
switching. You no longer have a choice.
(2) The delay through a maximal Ethernet system can exceed
250 bits. Ethernet therefore implements a distributed-control
system that arbitrates for access over the bus. The heart of the
distributed-control system is a carrier-detection circuit which
is capable of detecting any incoming signal. The carrier
detection circuit must be guaranteed to work even in the presence
of a strong local outbound signal. This circuit operates
on the same principle as a hybrid, or near-end-crosstalk
Once your bus lengths exceeds many clock periods,
it becomes worthwhile to invest in sophisticated
bus arbitration schemes to increase the bus efficiency.
10BASE-5 Ethernet chose a distributed control scheme.
The Ethernet control scheme was designed on the assumption
that the system would be fairly lightly loaded, and it
would statistically be better for each device just to blast ahead
without permission, rather than wait for guaranteed access
from some central arbiter. The carrier detect circuit
tells a transceiver when it has made a mistake
(collided with another party), so that both parties can
back off, wait a random interval, and try again. In general,
the control structures used to efficiently arbitrate on any big bus
can become very complex. The amount of circuitry devoted to bus
arbitration seems to grow proportional to the number of bits of data
stored within the transmission channel at any given time.
In 10BASE-5 a DC component was superimposed upon the data signal
that could be stripped off at the receivers for the purpose
of carrier detection. The propagation of this DC signal was
as carefully controlled as any first-incident-wave data
(3) To solve the distributed-clock skew problem, each receiver
incorporates a PLL circuit which acquires frequency and phase
lock on the incoming signal within 64 bits of the beginning
of each data block. The transmitters are not frequency locked
to each other, but free-run.
Once your bus becomes so large that you are contemplating
very large burst transfers anyway, the efficiency losses from
the PLL aquisition and lock delay begin to look reasonable.
In the 10BASE-5 Ethernet system the PLL wastes about 48 bits
acquiring lock during the packet preamble, out of a minimum
burst size of about 512 bits, on a bus with a total round-trip
delay of about 500 bits.
The use of first-incident-wave switching, distributed control,
and PLL-based clock recovery are three good examples of
bus design strategies useful when facing bus
design problems with increasingly high ratios of bus
delay to clock period.
I think that LAN architectures in general are an interesting place
to look for solutions to very fast bus design problems.
Dr. Howard Johnson
At 08:34 AM 4/21/99 -0700, you wrote:
>>What differs between PCI and Ethernet is basically that in ethernet the
>>clock travels with the data, so that sender and receiver have different
>>clocks. Clock periods isn't then the relevant measure on how much time
>>you have to spare. Not so in PCI.
>That's why Ethernet was such a lousy example.
>**** To unsubscribe from si-list: send e-mail to
>firstname.lastname@example.org. In the BODY of message put: UNSUBSCRIBE
>si-list, for more help, put HELP. si-list archives are accessible at
Dr. Howard Johnson, Signal Consulting, Inc.
tel 425.556.0800 fax 425.881.6149 email email@example.com
Upcoming High-Speed Digital Design seminars:
S E E - - - >>> WWW.sigcon.com
**** To unsubscribe from si-list: send e-mail to firstname.lastname@example.org. In the BODY of message put: UNSUBSCRIBE si-list, for more help, put HELP. si-list archives are accessible at http://www.qsl.net/wb6tpu/si-list ****