Slashdot Mirror
AMD Delays Hammer
TeJarz writes "C|Net reports that their next processor (Hammer) has been rescheduled from its original Q4 release to Q1 2003. To quote C|Net: 'The delays are occurring to accommodate the release of a new version of Athlon with a 333MHz bus, said Crank. Current Athlons come with a 200MHz bus and 256KB of secondary cache.' Let's hope this doesn't get moved again."
Q: Can Linux, FreeBSD or another open source OS run on "Palladium" hardware?
A: Virtually anything that runs on a Windows-based machine today will still run on a "Palladium" machine (there are some esoteric exceptions[1]). If you currently have a machine that runs both Linux and Windows, you would be able to have that same functionality on a "Palladium" machine.
The exceptions are here
[1] These exceptions include the following:
1.)Some debuggers may need to be updated to work in the "Palladium" environment, but they can still work.
2.)Some special performance tools may need to be updated.
3.)Software that writes directly to TCPA hardware will need to be updated.
4.)Memory scrub routines (at the hardware level) will need attention.
5.)Third-party crash dump software may need to be updated.
6.)BIOS mode hibernation features will need to be updated to work with "Palladium."
Its these 6 reasons why palladium is still beta and why AMD is probably waiting before releasing Hammer.
http://saveie6.com/
Latency.
With single data rate a new address can be sent every clock for all memory requests.
With double data rate a new address can be send with every other "clock", but while data transmission rate stays the same. Effectively this means transferring double data for each request, while the amount of requests doesn't change.
This isn't very serious problem, since single bytes/bus wide data aren't usually transferred, but whole cachelines of 32/64 bytes. They will generate 4/8 sequential burst requests nullifying much of the "halfclocked" address generation potential latency problems.
Ok, so why can't the addresses be sent like the data is another question which someone else with more knowledge might explain.. Maybe it would complicate things too much since the request-answer mechanism should be pipelined to accept new requests until previous requests are served. Or maybe the physical bus has some limitations, like using the same pins for address/data, which would simply make it impossible to send new addresses simultaneously (on falling edge of clock) while receiving data.