What is Better I/O, and When?

1. What is Better I/O, and When?

2. Traditional I/O is Limited • Bus Physics requires short and wide • Incompatible with • Closed PC boxes • Cable connections • Most protocols have some weak points • Exposed by Switches and Bridges • Deadlock hazards • Addressability • Exposed by technological evolution • Built-in limitations • Speed/timing assumptions

3. What Does the Customer Want? • Never to open the PC’s box again • Plug and Play • Stackable Accessories • Connected by (at most) 1 small cable • As few Power Bricks as possible! • Cables that are • Cheap • Thin • Reliable • Simple • Few

4. How can we Deliver? • High speed serial point-to-point links • Avoids the bus physics limitations • Keeps cables thin and cheap • Protocols that • Provide bus-like services • Scale with technology • Permit concurrent parallel I/O traffic • Bandwidth increases naturally with system size • Grow bandwidth more by replication, as needed • Have practically no built-in limits • Distribute (some) power on data cables

5. Potential Sources of Technology • Scalable Coherent Interface, ANSI/IEEE 1596–1992 • Serial Bus, IEEE 1394–1995 • Gigabit Ethernet • FibreChannel • Serial Express, IEEE P2100 • Telecom industry

6. Scalable Coherent Interface • ANSI/IEEE 1596–1992, IEC 13961–1999 • Proven, in high-end servers, but too expensive • Protocol supports mixtures of • Switch • Bridge, and • Ring connections

7. Serial Bus • Isochronous protocols • Multimedia • RealTime applications • Mass-market volumes • Thin high-bandwidth cables

8. Gigabit Ethernet • Physical signaling excellent • Huge research base • RJ45/Cat 5 extremely attractive • Protocols designed for networking • Complementary to our needs, different goals • We add new applications, don’t displace existing ones. • We add significant market volume.

9. FibreChannel • Signaling • Cabling • Fiber Optic links • Extensive research base

10. Serial Express • Now revised for broader applications • More robust • More extensible • Easier to connect to Serial Bus

11. What Should We do? • Take the best ideas • Combine them • Leverage past experience • Use Open Process • Open Standards • Support them with industry resources • patent pool • Joint R&D • Joint promotion, marketing • Joint interoperability tests

12. Specifically, Take • Physical Layers from • Gigabit Ethernet • FibreChannel • Telecom • New High-Speed developments • Parallel-link Implementations • Protocols from • SCI • Serial Bus • Serial Express • PCI

13. Why use Memory-Bus Protocols? • What is a Bus? • Read/Write transactions • Easily processed by hardware • Buses are extremely versatile • Efficient even for small transfers • Low latency • Simple familiar addressing • No I/O instruction set support necessary • Packet-switching is easy • DMA emulates channels • Protection easy via usual mechanisms

14. We Choose Bus Architecture • Packet switching enables low cost • Allows mixing a wide range of applications • Versatility allows for unforeseen applications • Can even do clustering efficiently • Easily scales to multiprocessor applications • Security easily implemented via familiar page protection mechanisms • Emulation of buses using point-to-point links avoids physics limits and allows bandwidth to scale indefinitely.

15. What are the Components? • Arbitration from SCI and Serial Express • RealTime/Isochronous from Serial Bus • DMA architecture from IEEE P1285 1212.1, SBP-2 • Signaling, cabling from Gigabit Ethernet • Power distribution similar to Serial Bus • Avoid complications by limiting to 1 hop from Hub • Plug & Play based on IEEE 1212/IEC139xx • Encryption based on IEEE P1363 & Serial Bus

16. How Long Will This Take? • The really hard parts (scalable protocols) are ready for polishing and review • Experience from previous standards available • Detailed draft specs exist now. • Easily extensible, with backward compatibility • Custom applications can use standard infrastructure • All known requirements to date have been met! • Physical Links will need continuing work • RJ45/Cat 5 done now, ready for review • Higher Bandwidth Cables and Connectors TBD

17. Protocol Goals Achieved • Random wiring by untrained customers • Can intermix devices with different speeds • Initialization and addressing are software-friendly • RealTime/Isochronous data supported • Arbitrary topology, arbitrary mix, of • Switches • Hubs • Daisy-chains • Encrypted traffic freely intermixed with unencrypted • Arbitration is efficient and technology independent.

18. Protocol Goals Achieved • Resource allocation guarantees no nodes starved • Cache coherence can be added when needed. • Can be scaled up transparently by using • paralleled serial links or • parallel links • Hubs/switches/routers can range from • cheap and simple to • smart with higher performance • Hub-based wiring is assumed • Leverages open standards work (1596, 1394, P2100, 1212, 1212.1, P1285, P1996, etc.)

19. Author Contact Info David B. Gustavson, IEEE P2100 (LAMP) Chair CFO & Secretary, SLDRAM Inc. Executive Director: SCIzzL, the association of Local Area Memory Port developers, manufacturers and usersSanta Clara University 1946 Fallen Leaf Lane Los Altos, CA 94024-7206 tel: 650-961-0305fax: 650-961-3530 email: dbg@SCIzzL.com