Loading learning content...
Throughout this module, we've encountered a recurring theme: every line coding scheme involves trade-offs. NRZ offers excellent bandwidth efficiency but fails at synchronization. Manchester guarantees transitions but doubles bandwidth requirements. Block codes like 8B/10B provide both synchronization and DC balance but add overhead.
The natural question is: How do we quantify these trade-offs? How can we compare one line code against another in a rigorous, principled way? What metrics capture the essence of a good line code?
This page introduces the analytical framework for evaluating line code efficiency. You'll learn to calculate spectral efficiency, compare coding overhead, and understand the fundamental limits that govern what any line code can achieve. This knowledge transforms line code selection from guesswork into engineering discipline.
By the end of this page, you will master the key efficiency metrics for line codes: bit rate to baud rate ratio, bandwidth efficiency, overhead calculation, and figure of merit analysis. You'll be able to make quantitative comparisons between encoding schemes and select the optimal code for given requirements.
Before diving into specific metrics, let's establish the fundamental concepts that underpin efficiency analysis.
Key Definitions:
| Term | Definition | Unit | Example |
|---|---|---|---|
| Bit Rate (R_b) | Number of data bits transmitted per second | bps | 1 Gbps |
| Baud Rate (R_s) | Number of signal changes (symbols) per second | Baud or symbols/s | 500 MBaud |
| Symbol | One discrete signal element (can represent 1+ bits) | — | Voltage level, phase state |
| Signaling Rate | Same as baud rate; rate of symbol changes | Baud | — |
| Bandwidth (B) | Frequency range occupied by the signal | Hz | 125 MHz |
| Overhead | Extra bits added by encoding (beyond data bits) | % or ratio | 25% for 8B/10B |
The Critical Distinction: Bits vs. Symbols:
In NRZ, 1 symbol = 1 bit (bit rate = baud rate). In multilevel signaling, 1 symbol can represent multiple bits. In block codes like 8B/10B, we send 10 symbols per 8 data bits.
The Efficiency Question:
How many data bits can we transmit per unit bandwidth? This captures the essence of spectral efficiency:
$$\eta = \frac{R_b}{B}\ \text{(bits/second per Hz)}$$
Higher η means more data through the same bandwidth—crucial when bandwidth is scarce or expensive.
Baud rate determines the signal's bandwidth requirements, while bit rate determines data throughput. A clever encoding scheme might achieve high bit rate at modest baud rate (through multilevel signaling), or it might sacrifice efficiency for other goals (synchronization, error detection). Understanding both is essential.
The bit rate to baud rate ratio (R_b/R_s) indicates how many data bits each symbol conveys—a fundamental measure of coding efficiency.
Formula:
$$\frac{R_b}{R_s} = \log_2(L)$$
Where L is the number of distinct signal levels (for multilevel signaling).
For binary signaling (L = 2): $$\frac{R_b}{R_s} = \log_2(2) = 1$$
For 4-level signaling (L = 4): $$\frac{R_b}{R_s} = \log_2(4) = 2\text{ bits per symbol}$$
But Wait—Encoding Overhead Matters:
The above formula assumes each symbol represents pure data. Block codes add overhead:
$$\frac{R_b}{R_s} = \frac{k}{n} \times \log_2(L)$$
Where k = data bits, n = total bits (including overhead), L = signal levels.
| Line Code | Signal Levels | k/n Ratio | R_b/R_s | Notes |
|---|---|---|---|---|
| NRZ-L | 2 | 1/1 | 1.0 | No overhead, baseline efficiency |
| NRZ-I | 2 | 1/1 | 1.0 | Same efficiency as NRZ-L |
| Manchester | 2 | 1/2 | 0.5 | 50% efficiency (guaranteed transitions) |
| AMI | 3 (but binary info) | 1/1 | 1.0 | Bipolar; DC balance for free |
| 4B/5B | 2 | 4/5 | 0.8 | 20% overhead for run-length limiting |
| 8B/10B | 2 | 8/10 | 0.8 | 25% overhead (for DC balance + sync) |
| PAM-4 | 4 | 1/1 | 2.0 | 2 bits per symbol, used in 100GbE |
| 64B/66B | 2 | 64/66 | 0.97 | 3% overhead (modern high-speed) |
Interpretation:
Example Calculations:
Manchester Encoding at 10 Mbps:
8B/10B at 1 Gbps:
Manchester's R_b/R_s = 0.5 might seem like 50% efficiency, but it's actually paying for something valuable: guaranteed transitions for clock recovery. The 'lost' 50% is the price of synchronization. Whether this is acceptable depends on whether synchronization could be achieved more cheaply by other means.
Bandwidth efficiency (also called spectral efficiency) measures how effectively a line code uses the available frequency spectrum.
Definition:
$$\eta_B = \frac{R_b}{B}\text{ (bits/s/Hz)}$$
Where R_b is data rate and B is the bandwidth required.
Theoretical Limits:
The Nyquist theorem states that for a channel with bandwidth B, the maximum symbol rate is:
$$R_s^{max} = 2B\text{ symbols/second (for baseband)}$$
Combining with multilevel signaling:
$$\eta_B^{max} = 2\log_2(L)\text{ bits/s/Hz}$$
This is the Nyquist limit for ideal (noiseless) channels. Real channels with noise are constrained by the Shannon-Hartley theorem, but for line coding analysis, Nyquist provides the relevant bound.
| Line Code | Bandwidth (approx.) | η_B (bits/s/Hz) | Nyquist Efficiency (%) |
|---|---|---|---|
| NRZ-L/I | R_b / 2 | 2.0 | 100% (theoretical ideal) |
| Manchester | R_b | 1.0 | 50% |
| AMI | R_b / 2 | 2.0 | 100% (for line rate) |
| 4B/5B + NRZ-I | ~0.625 × R_b | 1.6 | 80% |
| 8B/10B | ~0.625 × R_b | 1.6 | 80% |
| MLT-3 | R_b / 4 | 4.0 | 200% (3-level, clever transitions) |
| PAM-4 | R_b / 4 | 4.0 | 200% (4-level) |
1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889
import math class LineCodingScheme: """Model a line coding scheme for efficiency analysis.""" def __init__(self, name: str, signal_levels: int, data_bits: int, code_bits: int, bandwidth_factor: float): """ Args: name: Name of the encoding scheme signal_levels: Number of distinct signal levels (L) data_bits: Data bits per block (k) code_bits: Total bits per block (n) bandwidth_factor: Bandwidth as fraction of symbol rate """ self.name = name self.L = signal_levels self.k = data_bits self.n = code_bits self.bw_factor = bandwidth_factor @property def bits_per_symbol(self) -> float: """Bits per symbol (considering multilevel).""" return math.log2(self.L) @property def code_rate(self) -> float: """k/n ratio (data bits per code bits).""" return self.k / self.n @property def bit_to_baud(self) -> float: """Data bit rate to baud rate ratio.""" return self.code_rate * self.bits_per_symbol def symbol_rate(self, data_rate: float) -> float: """Symbol rate required for given data rate.""" return data_rate / self.bit_to_baud def bandwidth(self, data_rate: float) -> float: """Bandwidth required for given data rate.""" return self.symbol_rate(data_rate) * self.bw_factor def spectral_efficiency(self, data_rate: float) -> float: """Spectral efficiency in bits/s/Hz.""" return data_rate / self.bandwidth(data_rate) def overhead_percent(self) -> float: """Encoding overhead as percentage.""" return (1 - self.code_rate) * 100 def __str__(self): return (f"{self.name}: {self.L}-level, {self.k}:{self.n} rate, " f"η={self.spectral_efficiency(1e6):.2f} bits/s/Hz, " f"overhead={self.overhead_percent():.1f}%") # Define common line coding schemesschemes = [ LineCodingScheme("NRZ-L", signal_levels=2, data_bits=1, code_bits=1, bandwidth_factor=0.5), LineCodingScheme("Manchester", signal_levels=2, data_bits=1, code_bits=2, bandwidth_factor=0.5), LineCodingScheme("4B/5B", signal_levels=2, data_bits=4, code_bits=5, bandwidth_factor=0.5), LineCodingScheme("8B/10B", signal_levels=2, data_bits=8, code_bits=10, bandwidth_factor=0.5), LineCodingScheme("64B/66B", signal_levels=2, data_bits=64, code_bits=66, bandwidth_factor=0.5), LineCodingScheme("PAM-4", signal_levels=4, data_bits=2, code_bits=2, bandwidth_factor=0.5),] print("Line Code Efficiency Analysis")print("=" * 60)print(f"Target Data Rate: 10 Gbps") data_rate = 10e9 # 10 Gbps print(f"{'Scheme':<12} {'Symbol Rate':<14} {'Bandwidth':<12} {'η (b/s/Hz)':<12}")print("-" * 60) for scheme in schemes: sr = scheme.symbol_rate(data_rate) bw = scheme.bandwidth(data_rate) eta = scheme.spectral_efficiency(data_rate) print(f"{scheme.name:<12} {sr/1e9:.2f} GBaud {bw/1e9:.2f} GHz {eta:.2f}")Theoretical Nyquist bandwidth is the 'first null' of the signal spectrum. Practical systems need more bandwidth to preserve signal integrity. A common rule: practical bandwidth ≈ 0.5 to 1.0 × symbol rate for NRZ-like codes. The exact factor depends on filtering, pulse shaping, and tolerable inter-symbol interference.
Coding overhead quantifies the extra bandwidth consumed by encoding beyond the bare minimum required for data transmission.
Definition:
$$Overhead\ (%) = \left(1 - \frac{k}{n}\right) \times 100$$
Where k = data bits per block, n = total transmitted bits per block.
Alternatively expressed as efficiency:
$$Efficiency\ (%) = \frac{k}{n} \times 100$$
Overhead + Efficiency = 100%
| Code | Data Bits (k) | Code Bits (n) | Overhead (%) | What Overhead Buys |
|---|---|---|---|---|
| NRZ-L/I | 1 | 1 | 0% | Nothing—no synchronization, no DC balance |
| Manchester | 1 | 2 | 100% | Guaranteed mid-bit transition, DC balance |
| 4B/5B | 4 | 5 | 25% | Max 3 consecutive zeros, improved sync |
| 8B/10B | 8 | 10 | 25% | Bounded run length, DC balance, error detection (via violations) |
| 64B/66B | 64 | 66 | 3.125% | Sync header, low overhead (with scrambling) |
| 128B/130B | 128 | 130 | 1.56% | Ultra-low overhead, sync header |
The Evolution of Overhead:
Notice the historical trend:
Manchester (1980s Ethernet) → 100% overhead
8B/10B (1990s Gigabit Ethernet) → 25% overhead
64B/66B (2000s 10GbE) → 3.125% overhead
128B/130B (PCIe Gen3+) → 1.56% overhead
As data rates increased, the overhead 'tax' became increasingly expensive. At 100 Gbps, 25% overhead from 8B/10B would cost 31.25 GHz of extra bandwidth. Engineers developed more efficient codes to reduce this burden.
The Scrambling Revolution:
64B/66B achieves low overhead by using scrambling instead of carefully-designed code words:
Frame overhead as 'buying features' rather than 'wasting bandwidth.' 8B/10B's 25% overhead purchases: (1) guaranteed run length ≤5, (2) guaranteed DC balance, (3) error detection via code violations, (4) special control characters. Whether this purchase is worthwhile depends on the application.
No single metric captures all aspects of line code performance. Engineers use multiple figures of merit (FOM) to compare codes across different dimensions.
Common Figures of Merit:
| Code | η_B | Transitions | Max Run | DC Free | Error Det. | Complexity |
|---|---|---|---|---|---|---|
| NRZ-L | 2.0 | 0-1.0 | Unlimited | No | None | Trivial |
| NRZ-I | 2.0 | 0-1.0 | Unlimited | No | None | Simple |
| Manchester | 1.0 | 1.0-2.0 | 1 bit | Yes | Via edge | Simple |
| Diff Manchester | 1.0 | 1.0-2.0 | 1 bit | Yes | Via edge | Simple |
| AMI | 2.0 | ~0.5 | Unlimited | Long-term | Bipolar violation | Simple |
| B8ZS | 2.0 | ~0.5 | 8 bits | Yes | Multiple | Moderate |
| HDB3 | 2.0 | ~0.5 | 4 bits | Yes | Multiple | Moderate |
| 4B/5B | 1.6 | ~0.8 | 3 bits | No (needs NRZ-I) | Code violation | Lookup table |
| 8B/10B | 1.6 | 0.3-0.8 | 5 bits | Yes | Code violation | Lookup table |
| 64B/66B | 1.94 | ~0.5 | ~66 bits | Stat. | CRC/frame | Scrambler + header |
Weighted Scoring Approach:
When selecting a line code, assign weights based on application priorities:
FOM = w1×(Spectral Efficiency) + w2×(Sync Capability) + w3×(DC Balance)
- w4×(Complexity) - w5×(Overhead)
Where w1 + w2 + w3 + w4 + w5 = 1 (normalized weights)
Example: Gigabit Ethernet Link
Priorities:
Result: 8B/10B scores well—excellent sync and DC balance, acceptable overhead, reasonable complexity.
Every line code wins for some applications and loses for others. NRZ-L is perfect for short PCB traces with separate clock. Manchester is ideal for 10 Mbps Ethernet. 8B/10B suits Gigabit links. 64B/66B dominates at 10Gb+. There's no 'best' code—only best-for-this-application.
Understanding how line code properties trade against each other helps engineers make informed decisions. Let's formalize these trade-offs.
Bandwidth Efficiency vs. Synchronization Trade-off:
Guaranteeing transitions requires 'spending' signal changes that could otherwise carry data.
The Spectrum:
Mathematical Relationship:
Let T = guaranteed transitions per bit. Then approximately:
$$\eta_B \approx \frac{2}{1 + T}$$
More transitions → lower efficiency. This is fundamental—you can't get both for free.
When to Favor Synchronization:
When to Favor Bandwidth:
Line code selection is constrained optimization: maximize efficiency subject to minimum synchronization, maximum run length, DC balance requirement, and complexity budget. Different applications have different constraints, leading to different optimal codes.
Let's apply the efficiency framework to real engineering decisions, examining how actual standards selected their line codes.
| Standard | Line Code | Why Selected | Key Trade-offs Made |
|---|---|---|---|
| 10BASE-T Ethernet | Manchester | Reliable sync over cat3 cable, transformer coupling | Accepted 50% efficiency for guaranteed transitions |
| 100BASE-TX | 4B/5B + MLT-3 | Higher efficiency than Manchester, adequate sync | 3-level signaling for reduced bandwidth |
| 1000BASE-T | PAM-5 (4D) | 4 pairs × 5 levels = massive parallelism | Extreme complexity for 1Gbps on cat5 |
| 10GBASE-R | 64B/66B | Low overhead critical at 10Gbps | Scrambling instead of mapping for DC balance |
| USB 2.0 FS | NRZI + bit stuffing | Simple, adequate for 12 Mbps | Bit stuffing limits run length without lookup tables |
| USB 3.0 | 8B/10B | DC balance required for AC coupling | 25% overhead acceptable; proven technology |
| PCIe Gen3 | 128B/130B | Ultra-low overhead at 8 GT/s | Scrambling for spectral properties, CRC for errors |
| SATA | 8B/10B | Reliable operation over cables | Same as Fibre Channel origin |
Case Study: Evolution of Ethernet Coding:
10BASE-T (1990): Manchester @ 10 Mbps
- Required: 20 MBaud → 10 MHz bandwidth
- 50% efficiency acceptable for 10 Mbps
100BASE-TX (1995): 4B/5B + MLT-3 @ 100 Mbps
- 125 MBaud → ~31.25 MHz bandwidth
- MLT-3 reduces bandwidth vs. binary
- Efficiency: ~80% (vs. 50% for Manchester)
1000BASE-X (1998): 8B/10B @ 1.25 Gbps
- Fiber: 1.25 GBaud → ~625 MHz bandwidth
- 8B/10B provides DC balance for fiber optics
- Efficiency: 80%
10GBASE-R (2002): 64B/66B @ 10.3125 Gbps
- ~5.15 GHz bandwidth requirements
- 25% overhead would add 2.5 Gbps
- 64B/66B saves ~2.2 Gbps
25/40/100GBASE-R: 64B/66B + RS-FEC
- Forward Error Correction added at physical layer
- Overhead: 3% encoding + ~7% FEC = ~10% total
Key Insight: As data rates increased 10,000× (10 Mbps → 100 Gbps), overhead tolerance dropped from 100% to <5%. The technology evolved to meet these constraints.
Many line code choices reflect historical constraints that no longer apply. 8B/10B was designed when lookup tables were expensive; today, scrambling is cheaper. But backwards compatibility often locks in older choices. SATA uses 8B/10B because it inherited Fibre Channel's physical layer—not because 8B/10B is optimal for disk drives.
Coding efficiency provides the quantitative foundation for line code selection. With these metrics, you can make principled decisions rather than relying on intuition or tradition.
Module Completion:
This completes our deep dive into Line Coding - Basics. You now have a comprehensive understanding of:
With this foundation, you're prepared to study more advanced line coding schemes—Manchester encoding, bipolar codes (AMI, B8ZS, HDB3), and modern block codes (8B/10B, 64B/66B)—understanding not just how they work, but why they were designed as they were.
Congratulations! You've mastered the fundamentals of line coding. You can now analyze any encoding scheme using the metrics and frameworks introduced here. The next modules will build on this foundation with Manchester encoding, bipolar schemes, and multilevel coding—each addressing the limitations of basic NRZ in different ways.