From LDT to HyperTransport: The API NetWorks Connection
Before it was HyperTransport, AMD's chip-to-chip link was called Lightning Data Transport, and one of the first companies outside AMD to ship silicon for it was the networking offshoot of Alpha Processor, Inc. This is the story of that link and of API NetWorks' short but influential part in it.
The problem LDT set out to solve
By the late 1990s, PC and server boards were stitched together with a collection of buses that had grown up separately. The processor talked to the northbridge over a front-side bus (or, for Athlon and Alpha, the EV6 bus). The northbridge talked to the southbridge over PCI or a proprietary link. Add-in devices sat on 32-bit, 33 MHz PCI, which topped out around 133 MB/s shared among every card on the segment. Gigabit Ethernet, fast SCSI and cluster interconnects were already pressing against that limit.
The industry responses were varied. Intel pushed its own hub interface between north and south bridges. PCI-X widened and sped up the parallel bus. InfiniBand aimed to replace the I/O bus entirely with a switched fabric. AMD took a narrower, more pragmatic approach: a low-pin-count, point-to-point, packet-based link for connecting chips on the same board. Internally and in early public disclosures around 2000, it was called Lightning Data Transport, or LDT.
What LDT actually was
LDT borrowed several ideas that will be familiar to anyone who has read about the EV6 bus: point-to-point links, a clock forwarded alongside the data, and transfers on both clock edges. It then went further by packetising everything. Commands, addresses and data all travelled as packets over the same narrow set of wires, with separate unidirectional links in each direction.
- Scalable width. A link could be 2, 4, 8, 16 or 32 bits wide in each direction, so designers could trade pins for bandwidth device by device.
- Scalable clock. Links came up at a safe low speed and negotiated upward, with the first specification reaching 800 MHz double-pumped.
- Daisy-chaining. A "tunnel" device could pass traffic through to the next device in a chain, so a single host link could serve several peripherals.
- Software transparency. Devices on LDT appeared to the operating system as ordinary PCI devices, so existing drivers and enumeration code kept working.
That last point is easy to overlook but was probably the most important commercially. No one had to rewrite an operating system to use LDT. BIOS and firmware needed to know how to initialise the links, but after that the kernel saw a PCI hierarchy.
| Link width (each direction) | Clock (DDR) | Peak per direction | Typical use |
|---|---|---|---|
| 8 bits | 200 MHz | ~400 MB/s | Early southbridge links |
| 8 bits | 400 MHz | ~800 MB/s | PCI bridges, I/O hubs |
| 16 bits | 800 MHz | ~3.2 GB/s | Opteron-era CPU links |
| 32 bits | 800 MHz | ~6.4 GB/s | Specified, rarely deployed |
Figures are approximate peaks for the 1.x generation and ignore packet overhead.
Enter API NetWorks
By 2000, Alpha Processor, Inc. was looking for a business less dependent on the fate of the Alpha instruction set. In May 2000 it announced a separate API NetWorks unit focused on high-performance networking and interconnect silicon. The logic was sound: API's engineers had spent years designing boards around fast point-to-point buses, dealing with signal integrity at speeds most PC board houses had not yet encountered, and writing firmware to bring up complex chipsets.
AMD, for its part, needed partners. A new interconnect is only useful if there are chips to connect, and AMD was not going to build every bridge and peripheral itself. In early 2001 API and AMD announced a HyperTransport collaboration, by which time LDT had been renamed. The new name was meant to sound less like an internal codename and more like an industry standard, which is what AMD wanted it to become.
The HT-to-PCI bridge
API NetWorks' most visible product was a HyperTransport-to-PCI bridge, announced in April 2001. Conceptually it was simple: an HT link on one side, conventional PCI on the other, so that any existing PCI device could hang off a HyperTransport fabric. In practice, a bridge like that was exactly what the ecosystem needed in 2001. Almost no peripherals spoke HT natively, so a working bridge meant system designers could adopt HT for the backbone of a board while continuing to use the enormous catalogue of PCI network, storage and graphics controllers.
The HyperTransport Consortium and early adopters
In mid-2001 AMD and a group of partners formed the HyperTransport Technology Consortium to own the specification. API NetWorks was among the early participants, alongside names from networking, graphics and embedded computing. The first mass-market HT product arguably came from graphics: NVIDIA's nForce chipset for Athlon used a HyperTransport link between its north and south bridges in 2001. Networking vendors used HT in packet processors, and embedded MIPS and PowerPC designs picked it up as a convenient on-board interconnect.
For API NetWorks specifically, the timing was difficult. The 2001 downturn hit networking silicon hard, and the company's independent run was short. Precise details of how its HT assets and staff were redistributed are hard to pin down from surviving public material; what is clear is that the engineering work fed into an ecosystem that outlived the company.
How HyperTransport lived on with Opteron
The real payoff came in 2003, when AMD launched Opteron and the Athlon 64. Both integrated the memory controller on die and replaced the EV6-derived front-side bus with HyperTransport links. Opteron went further, with up to three links per processor and a coherent variant of HT for connecting processors to one another. A two- or four-socket Opteron server was a small point-to-point network of processors, each with its own memory, talking over coherent HT, with non-coherent HT links out to I/O tunnels and bridges.
That architecture looked remarkably like where Alpha had been heading with the 21364, which integrated memory controllers and an inter-processor router on the processor itself. It is a stretch to credit any one company for the idea, but it is fair to say that people who had worked on Alpha systems, at Digital, Compaq and API, recognised the Opteron design immediately.
HyperTransport also found its way into high-end systems. Cray, which had already partnered with API on Alpha Linux clusters in 2001, later built its XT3 supercomputer around Opteron, attaching its custom network interface directly to a processor's HT link. Add-in "HTX" slots briefly let cluster interconnect cards sit on HT rather than PCI, cutting latency for MPI traffic.
The long tail
Intel answered with QuickPath Interconnect in 2008, and PCI Express steadily absorbed the I/O role. AMD kept HT for processor links through several generations before replacing it with Infinity Fabric. Yet the core ideas that LDT championed are now universal:
- Narrow, fast, point-to-point links rather than wide shared buses.
- Packetised transactions with credit-based flow control.
- Backward compatibility with the PCI software model.
- Integrated memory controllers with processors linked peer to peer.
For anyone collecting hardware from this period, an early HT evaluation board or bridge sample is a far rarer find than any Alpha motherboard, and worth keeping if you come across one.
Further reading on this archive
- How the EV6 bus connected Alpha and the AMD Athlon covers the interconnect HT replaced.
- The CS20 and dense 1U computing looks at API's server hardware from the same period.
- Corporate overview has the archived company background.