Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Politics : Formerly About Advanced Micro Devices -- Ignore unavailable to you. Want to Upgrade?

To: Tenchusatsu who wrote (125094)	10/1/2000 10:19:52 AM
From: TechieGuy-alt	Read Replies (1) \| Respond to of 1571039

Tenchusatsu, there is a very good (technical) article in the Aug 21, 2000 print issue of Electronic design. I'll post a few points that it makes that I have not seen posted here before: * Packets sent over the [LDT] interface use the standard plug&play headers. The system works with old, present and potential [future] operating systems. * data send over LDT are sent using an async clock forwarding scheme, with one clock signal for every 8 bits of data in every direction. [My comment: This is actually very smart, as one needs to keep the length of all the data lines (2 lines/bit) and clock for those lines matched to within 50-100mills at 800MHz. This would become very difficult to do with one clock per 32 bits (64 lines), just from a routable standpoint on the board. This way, only 18 lines need to be length matched on the board. Someone had their thinking cap on.] * Even interrupts are handled via packets, rather than hardwired signals. [My comment: Again very smart, as the design can never run out of interrrupts, and can support as many interrupts as a future remote LDT chip needs. You do of course pay a penality in terms of latency, especially if the LDT link is being bridged over multiple bridges.] * For short distance CPU-CPU connections a dual 32bit (800MHz) clocked LDT interface can deliver an aggregate bandwidth of 12.8 GB/s which is 96 times 32bit/33MHz PCI. TG [Edit: I found a web link for the artcile. It seems to be missing 2 figures, but most of the text seems to be there. elecdesign.com ]

To: Tenchusatsu who wrote (125094)	10/1/2000 10:36:59 AM
From: combjelly	Read Replies (1) \| Respond to of 1571039

Tenchusatsu, RE:LDT I gather from reading the progress of the press releases, that LDT started as a scheme for connecting a north and south bridge together since a PCI interconnect is running out of steam. The idea being that each PCI, AGP and other bus would hook into a 4 to 32 bit LDT port. Once the design process got underway, they realized that it could do a lot more, like NUMA. And then it occurred to them that it could even be used as a PCI replacement. Heck, if they were so inclined, it could even be used as a memory bus, and solve a lot of the Rambus problems, to boot. According to what has been released, Sledgehammer will have an integrated DDR memory controller and LDT bus(ses). At least a LDT and likely a cLDT also. LDT, and it's derivatives, is a real exciting way to handle I/O, the only question is how will the actual silicon work? AMD had a good presentation at the Platform2000 conference, I'll try to dig up the link.

To: Tenchusatsu who wrote (125094)	10/1/2000 12:43:28 PM
From: Charles R	Read Replies (2) \| Respond to of 1571039

Tenchusatsu, <"Coherent LDT." Guess this is the new name of the scalable interconnect I was referring to earlier.> I don't remember what you posted about scalable interconnect but if you were talking about SCI (aka IEEE 1596) you would be on the right track. LDT based on what I have heard/seen so far seems to be a variant of that spec. There also seems to be elements of IEEE1394 and Compaq's defunct ANET. <Sounds like grand plans for LDT, much grander than I originally thought> I am surprised! I didn't realize you just focussed on the server aspects. I thought you were the only Intel long who saw the importance of LDT. Why in the world did you think Transmeta would license LDT if it was limited for multiprocessor applications? AMD seems to have learned from Intel's mistakes and doing the right kind of integration for its future chips. An integrated processor with DDR/LDT coming out of it would be a killer chip (leave the graphics outside). AMD has all the pieces now except graphics (Athlon core, 760 core, southbridge). And graphics is probably better left outside for everything except the ultra low-end ($299 PCs) AMD so far has been doing everything perfectly except chipsets and that problem will go away with integrated northbridge. Intel has only one thing going for it for 2001 - MHz. The only question is when these things will happen and if Intel can recover from its mis-steps before AMD executes. Thanks to OT discussions and the rah-rah crowd, lately there has rarely been a meaningful technical dialog on either of the AMD threads. Thanks for bringingup something good. Chuck

To: Tenchusatsu who wrote (125094)	10/4/2000 12:22:22 PM
From: Joe NYC	Read Replies (1) \| Respond to of 1571039

Tenchusatsu, Neat. EV6 will be replaced with LDT, an interconnect w/ much better bandwidth per pin. I wonder if Sledgehammer will also include an integrated memory controller. That should be one serious design of a processor. EV6 connects CPU to Northbridge. It will stay in the sledgehammer (or will be relplaced with something a lot simpler). The northbridge to CPU connection will be internal to the die (package?) so the bus will become internal rather than external. LDT is the connection between Northbridge and the Southbridge (or south bridge components). In case of Sledgehammer, which is has Northbridge integrated, it is a connection between the entire Sledgehammer package and the outside world. I don't know what kind of interface will there be for AGP. I would hope that the convoluted AGP design would be replaced with a more streamlined LDT connection. I think the bandwidth is good enough, and the bus can be made wider. I guess there may be some problems with latency, which can't be much worse than present AGP anyway. Joe