What is Hypertransport?
By Nils Dahl
Date: July 22, 2002
Hypertransport began as the RapidI/O bus concept at API. Originally, it was a method of converting Intel processor I/O instructions, signal line activity, and data packets into a composite packet of commands, instructions, and data, transmitting those packets to a receiving bus interface, and converting everything back into standard Intel format. With very low overhead, of course. This restored combination is then fed to some I/O port logic design or to Intel's PCI bus format for further distribution. Let's not forget the AGP variant of PCI, which is also supported.
Hypertransport is defined as a pair of unidirectional paths, each starting with a sending port and ending with a receiving port. Tunnels are drops added to the transmission path itself. Think MIDI interfaces for a very old technology of similar design. Each MIDI IN port goes directly to an optocoupler that feeds the local drop and drives a new current source that feeds the local OUT port of the unit. Lots of people used to connect IN to IN and wonder why things didn't work.
Now Hypertransport, by design, bears a remarkable resemblance to classic Intel interface design ideas. The Intel processors write data to 'somewhere' by first presenting address information at the interface (and diddling with control lines) and then presenting data at the interface (more diddling) so that the multiplexed interface lines' contents are turned into separate address and data blocks inside the latched buffer connected there-to. In most cases, I/O ports - including the video card interface - work exactly like the Hypertransport bus also. For video, the 1, 2, 4, or whatever byte-wide memory block that represents the buffer interface to the video subsystem is fed commands, addresses, and data in order. Thus Hypertransport can be said to be a generalized form of the classic Intel interface as used for processor-to-everything functionality. You can see why a carefully designed bus that mimics the Intel logic behavior would be a very efficient interconnect bus. Generating the packet can be done while each step in the process is occurring.
"Now stop that." - Jack Benny, usually to some comic who was laughing hard or otherwise abusing our sad sack star.
Yes, folks, the way video is coupled to processor in Intel/IBM designs - all of them - is incredibly inefficient (but low cost, of course) and does slow things down compared with slightly more sophisticated alternatives. But then 8085 CP/M legacy designs tend to be like that. Perhaps a bit faster though.
Hypertransport today is growing and evolving. You should query The Hypertransport Consortium for current details and plans for the future.
Thus Hypertransport is invisible to the code executing in the processor and to active logic destination ports that return data or commands/interrupts - subsystems such as udma controllers in IDE and SCSI hard drive controllers, for example. Heck, almost every subsystem works this way - with the noteworthy exception of the famous IBM EGA display adapter.
Now Intel has a very specific set of definitions of I/O ports that it supports, but nobody can stop others from adding to the set of concepts. And there are simple methods of linking two independent intelligent subsystems, as we already see with RISC-based video cards. With just a bit of imagination, one can easily design a 'port' that consists of a block of shared memory - which can be used to store outgoing data and buffer incoming command sequences. That's just one of my favorite old ideas. Even the simple serial I/O port chips of the 8550 and 16550 series use a bit of memory as a buffer for data moving in either direction.
Hypertransport circuitry uses proven bus design technology - low voltage differential signaling into low impedance physical lines. The bus interface could be converted into a fiber optic line quite easily by simple logic assemblies, allowing movement of data through very noisy or unshielded sections of a large cage or even to separate boxes. While this might seem to be superfluous at first, the attractiveness of Hypertransport is that it is a generalized, low cost solution, is not patented by Intel and thus cannot be defined as having narrow limits of functionality by Intel.
One weakness of the entire 'pc' market has always been that it follows IBM's or Intel's design rules just because such a behavior permits easy access to high volumes of relatively low cost prefabricated logic products that 'mostly work'. Bryan Smith is one of few who have discussed in detail an alternative - eliminating the AGP interface part of the connection between processor and video subsystem. Visit Bryan at his weblog - www.smithdot.net. Word of warning. Bryan gets down and dirty with details that have always given me headaches. Things have gotten quite complex since the days when Don Lancaster wrote his classic cookbooks on TTL logic and CMOS logic.
Yes, you can design in caches of various sorts to accumulate quantities of data in non-critical interface types. The Intel software and hardware interrupt schemes are supported and still will work just fine. Just don't forget to 'check the keyboard buffer' regularly. An old, old joke, folks. Only those who write code at low levels would fully appreciate it.
In Opteron systems, each processor works independently. Local memory will contain the code being executed. Each processor can, in 64-bit mode, address all other processors' local memory as well - transparently via Hypertransport. This does introduce a bit of a software design challenge. If there are 8 processors and all of them happen to want access to one processor's local memory, things could get messy. Thus I have been suggesting distributed processing schemes that should minimize or eliminate contention for memory. Of course a back end SQL database can feed results directly to the local memory of the processor running the SQL client and driving the video subsystem. Such a scheme works just like a server/client network (separate boxes) would but eliminates all the overhead of converting data into packets, sending those packets over a network, converting packets back into data, and feeding the data to a client app. Basically, that is.
The market for new interface ideas is now wide open. You can design a multiple port Firewire chip that talks to the processor via Hypertransport and hang banks of Firewire hard drives off that interface for modest movie projects or as non-critical database contents or whatever. You can design a multiple port SerialATA chip just as easily. Or you could replace the AGP interface of your video card with a fiber optic Hypertransport interface and just use the card slot for power. Where would the Hypertransport feed come from? Add a tunneling Hypertransport chip to the mainboard and let that feed the fiber optic conversion chip - which can run at Hypertransport speeds with no delays.
Imagine a motherboard that has NO elaborate, messy layered sets of physical bus lines at all. Imagine the Opteron and its local memory on a small card, linking via a fiber optic line to a tunneling Hypertransport chip that has connections to a video subsystem on another small card. Forget PCI bus completely. Save a bit of royalty money. Get much faster data transfers. Innovate.
Now if I catch anyone trying to link color laserprinters to systems via Hypertransport fiber optics, well ...... At least think of me fondly. Or not.
Hypertransport is the future, IF and only if all of you abandon the safe harbors of Intel concepts and venture into new realms of design. nVidia has actually done this already in its nForce designs and will take another step when it announces its nForce for that single clawhammer (32-bit clawhammer has only a Hypertransport interface and lines to its local memory block). That is the baby I want to see out and tested.
Or, to quote from the new, improved opening song of the world famous Tenchi Muyo animated series by Pioneer of Japan, "You can't be a hero hiding underneath your bed....." I favor Ryoko as the gal with the most - of everything. But then who wouldn't like a half human, half alien energy being of immense and mostly unknown powers - custom engineered by her very own mom?
Now just imagine an expansion case that is fed by a fiber optic Hypertransport link and can take PCI bus cards or, maybe, cards that also have a fiber optic Hypertransport interface. A really fast Hypertransport interface instead of a very slowly clocked PCI expansion mode interface. That would make one person happy (and Dave seems to be a nice guy). Well, if you could plug in 8 ethernet cards or 8 ADSL modems or something like that, it might make lots of people happy. Or you could use special lighting, effects, and other sorts of interface cards that would drive a Britney Spears concert show. Or whatever.
No, you can't just add a wireless interface to Hypertransport. Sorry.
nils dahl
just an old man
===================================
Pssst! We've updated our Shopping Page.
===================================