PowerPC 970 (Desktop power4)
Peter Boyle
http://www-3.ibm.com/chips/news/2002/1014_powerpc.html
Sounds like a 900MHz FSB and off-chip memory controller,
fabbed on .13u (power4 was .18u AFAIK). Claimed 1.8GHz
debut.
Peter
Del Cecchi
--
Del Cecchi
cec...@us.ibm.com
Personal Opinions Only
Anil T Maliyekke
> In article <Pine.GSO.4.33.021014...@holyrood.ed.ac.uk>,
> Peter Boyle <pbo...@holyrood.ed.ac.uk> writes:
> |>
> |>
> |> http://www-3.ibm.com/chips/news/2002/1014_powerpc.html
> |>
> |> Sounds like a 900MHz FSB and off-chip memory controller,
> |> fabbed on .13u (power4 was .18u AFAIK). Claimed 1.8GHz
> |> debut.
> |>
> |> Peter
> |>
> The original Power4 talked to a memory/IO hub chip via this point to point "bus".
But it was clocked at one third CPU speed.
So is the quoted bandwidth the unidirectional bandwidth or the
bidirectional bandwidth.
Anil
Del Cecchi
to 6.4 GB/sec" which would imply unidirectional. If it were 8 Bytes wide, that
would do it, with a little left over. seems reasonable, but I don't know for
sure.
David Wang
> Anil T Maliyekke <ama...@icarus.cc.uic.edu> writes:
> |> Del Cecchi <cec...@signa.rchland.ibm.com> wrote:
> |> > Peter Boyle <pbo...@holyrood.ed.ac.uk> writes:
> |> > |> http://www-3.ibm.com/chips/news/2002/1014_powerpc.html
> |> > |> Sounds like a 900MHz FSB and off-chip memory controller,
> |> > |> fabbed on .13u (power4 was .18u AFAIK). Claimed 1.8GHz
> |> > |> debut.
> |> > The original Power4 talked to a memory/IO hub chip via this point to point "bus".
> |> But it was clocked at one third CPU speed.
> |> So is the quoted bandwidth the unidirectional bandwidth or the
> |> bidirectional bandwidth.
> That's a good question. It says "can deliver information to the processor at up
> to 6.4 GB/sec" which would imply unidirectional. If it were 8 Bytes wide, that
> would do it, with a little left over. seems reasonable, but I don't know for
> sure.
It's two 32 bit links. one from CPU to "companion chip", and one back from
that chip to the CPU. Each link runs at 900 MHz (1.8 GHz CPU core. the interface
link runs at integer fraction of the CPU core, in this case 1/2)
So 4 bytes to, 4 bytes from, at 900 MHz that's 3.6 GB/s raw BW each way.
The link multiplexes command and address info over the same pins, so it's
some sort of packet based protocol. The math gets you 7.2 GB/s of raw
bandwidth, but after subtracting out command and address overhead, raw
peak data bandwidth is supposed to be about 6.4 GB of that 7.2 GB/s.
--
davewangATwamDOTumdDOTedu
Will R
>fabbed on .13u (power4 was .18u AFAIK). Claimed 1.8GHz
>debut.
>
>Peter
>
But, we still don't know anything in particular about that Vector Unit, right?
------------------
Woooogy
I have to go back in time to pretend to be myself when I tell myself to tell
myself, because I don't remember having been told by myself to tell myself. I
love temporal mechanics.
Rob Barris
fork...@aol.com (Will R) wrote:
> >Sounds like a 900MHz FSB and off-chip memory controller,
> >fabbed on .13u (power4 was .18u AFAIK). Claimed 1.8GHz
> >debut.
> >
> >Peter
> >
>
> But, we still don't know anything in particular about that Vector Unit,
> right?
It is VMX / AltiVec / Velocity Engine compatible. David Wang has a
first person writeup from MPF:
http://www.realworldtech.com/page.cfm?AID=RWT101502203725
Rob
Rudi Chiarito
> It is VMX / AltiVec / Velocity Engine compatible. David Wang has a
> first person writeup from MPF:
>
> http://www.realworldtech.com/page.cfm?AID=RWT101502203725
According to that report,
"IBM addressed this point specifically by stating that the PowerPC
970 processor implements the book E extensions of the PowerPC system
architecture, and allows for relatively painless transition between
32 bit mode and 64 bit mode operation."
Book-E, though, is not a mere extension: for all purposes it's
de-facto a separate architecture, which keeps compatibility with
32-bit PowerPC user code, while breaking existing 64-bit programs.
The introduction of the Book-E manual itself mentions only "binary
compatibility for 32-bit PowerPC application programs".
A processor implementing the "Real" 64-bit PowerPC architecture will
be at any time running in either 32-bit mode or 64-bit mode (depending
on the value of bit 0 in the Machine State Register). A Book-E
processor runs always in one mode - some sort of hybrid that happens
to be compatible with the 32-bit portion of the PowerPC architecture.
Did really Sandon state that the 970 is a Book-E processor? Whether he
did or not makes a substantial difference.
--
Perfection is attained not when there is no longer anything to add,
but when there is no longer anything to take away (A. de Saint-Exupery)
Rudi Chiarito ru...@amiga.com
David Wang
> Rob Barris <rba...@mac.com> writes:
>> It is VMX / AltiVec / Velocity Engine compatible. David Wang has a
>> first person writeup from MPF:
>> http://www.realworldtech.com/page.cfm?AID=RWT101502203725
> According to that report,
> "IBM addressed this point specifically by stating that the PowerPC
> 970 processor implements the book E extensions of the PowerPC system
> architecture, and allows for relatively painless transition between
> 32 bit mode and 64 bit mode operation."
> Book-E, though, is not a mere extension: for all purposes it's
> de-facto a separate architecture, which keeps compatibility with
> 32-bit PowerPC user code, while breaking existing 64-bit programs.
> The introduction of the Book-E manual itself mentions only "binary
> compatibility for 32-bit PowerPC application programs".
> A processor implementing the "Real" 64-bit PowerPC architecture will
> be at any time running in either 32-bit mode or 64-bit mode (depending
> on the value of bit 0 in the Machine State Register). A Book-E
> processor runs always in one mode - some sort of hybrid that happens
> to be compatible with the 32-bit portion of the PowerPC architecture.
> Did really Sandon state that the 970 is a Book-E processor? Whether he
> did or not makes a substantial difference.
You are correct. I inferred just a bit too much from the presentation
slides. I'll see if I can talk to Peter Sandon and get the story straight.
Apologies.
--
davewangATwamDOTumdDOTedu
Anil T Maliyekke
> According to that report,
> "IBM addressed this point specifically by stating that the PowerPC
> 970 processor implements the book E extensions of the PowerPC system
> architecture, and allows for relatively painless transition between
> 32 bit mode and 64 bit mode operation."
> Book-E, though, is not a mere extension: for all purposes it's
> de-facto a separate architecture, which keeps compatibility with
> 32-bit PowerPC user code, while breaking existing 64-bit programs.
> The introduction of the Book-E manual itself mentions only "binary
> compatibility for 32-bit PowerPC application programs".
> A processor implementing the "Real" 64-bit PowerPC architecture will
> be at any time running in either 32-bit mode or 64-bit mode (depending
> on the value of bit 0 in the Machine State Register). A Book-E
> processor runs always in one mode - some sort of hybrid that happens
> to be compatible with the 32-bit portion of the PowerPC architecture.
I was wondering about this. POWER4 implements a classic PowerPC MMU,
albeit the 64 bit version. Book E completely departs signficantly from
the classic PowerPC MMU, replacing segments with a process id in the
effective to virtual address translation and adding support for multiple
page sizes. Changing to a Book E MMU would represent a signficant change
to the POWER4 core and would affect compatibility with AIX and Mac OS X
(I think Linux supports Book E MMUs).
There are two other things I'm also wondering about regarding the PPC 970.
The first is what is the coherence block size and thus the block size
affected by dcbz/dcba. POWER4 uses 128 byte blocks, but all other PowerPC
CPUs (at least the ones Apple used) have 32 byte blocks. The second
thing is whether the new PPC 970 supports large pages and whether
it supports address translation via BAT registers. POWER4 supports the
former but not the latter. BAT registers are present in all other
classic MMU PowerPC processors. While I'm sure a lack of BATs can be
worked around, they have been used to map large blocks of memory in most
PowerPC OSes and not having them means more work has to be done.
Anil
David Wang
>>> http://www.realworldtech.com/page.cfm?AID=RWT101502203725
>> A processor implementing the "Real" 64-bit PowerPC architecture will
>> be at any time running in either 32-bit mode or 64-bit mode (depending
>> on the value of bit 0 in the Machine State Register). A Book-E
>> processor runs always in one mode - some sort of hybrid that happens
>> to be compatible with the 32-bit portion of the PowerPC architecture.
> I was wondering about this. POWER4 implements a classic PowerPC MMU,
> albeit the 64 bit version. Book E completely departs signficantly from
> the classic PowerPC MMU, replacing segments with a process id in the
> effective to virtual address translation and adding support for multiple
> page sizes. Changing to a Book E MMU would represent a signficant change
> to the POWER4 core and would affect compatibility with AIX and Mac OS X
> (I think Linux supports Book E MMUs).
Yes, I just spoke ever so briefly with Peter Sandon, and confirmed that I
botched this portion. I was reading off of Peter Glaskowsky's slides,
inferring something that wasn't there, then attributed it to IBM.
The real story is that PowerPC 970 inherits the 32/64 mode switching
mechanism from POWER4, and there's nothing new there. Hopefully the
article will be changed shortly to reflect the correction.
--
davewangATwamDOTumdDOTedu
Rudi Chiarito
> albeit the 64 bit version. Book E completely departs signficantly from
> the classic PowerPC MMU, replacing segments with a process id in the
> effective to virtual address translation and adding support for multiple
> page sizes. Changing to a Book E MMU would represent a signficant change
Yes, but that's in privileged mode. It affects directly only system
code, not user applications. There are more drastic incompatibilities,
which affect user code.
For example, in the PowerPC architecture, opcode 58 corresponds to ld,
ldu and lwa (64-bit instructions only). Book-E uses the same opcode
for another family of instructions: l(b|h|ha|w)z(u?)e and
st(b|h|w)(u?)e. It doesn't look that compatible to me.
> to the POWER4 core and would affect compatibility with AIX and Mac OS X
> (I think Linux supports Book E MMUs).
It does, but to my understanding the code is entirely different.
> The first is what is the coherence block size and thus the block size
> affected by dcbz/dcba. POWER4 uses 128 byte blocks, but all other PowerPC
> CPUs (at least the ones Apple used) have 32 byte blocks. The second
There are also some embedded PowerPCs that actually have 16 byte
lines. IBM's 403 is one such example.
> classic MMU PowerPC processors. While I'm sure a lack of BATs can be
> worked around, they have been used to map large blocks of memory in most
> PowerPC OSes and not having them means more work has to be done.
They can be handy to implement some kinds of optimisations. It would be
(a bit) a pity if they were missing. But I suppose one can't have
everything in life. Not being a Book-E CPU also means none of those
extra nifty registers to play with.
Rudi Chiarito
> Rudi Chiarito <ru...@amiga.com> wrote:
> > Did really Sandon state that the 970 is a Book-E processor? Whether he
> > did or not makes a substantial difference.
I omitted a necessary qualification there: it makes a substantial
difference to some - not to all.
> Apologies.
I also forgot to mention that, beside that little oddity, the report
was very well written. It's surely more informative than what's
publically available at the moment at IBM's PowerPC site (i.e. still
only the press release from Monday - hint, hint). Thank you!
Peter Boyle
On 16 Oct 2002, Rudi Chiarito wrote:
> David Wang <f...@bar.invalid> writes:
> > Rudi Chiarito <ru...@amiga.com> wrote:
> > > Did really Sandon state that the 970 is a Book-E processor? Whether he
> > > did or not makes a substantial difference.
>
> I omitted a necessary qualification there: it makes a substantial
> difference to some - not to all.
>
> > Apologies.
>
> I also forgot to mention that, beside that little oddity, the report
> was very well written. It's surely more informative than what's
> publically available at the moment at IBM's PowerPC site (i.e. still
> only the press release from Monday - hint, hint). Thank you!
Just want second Rudi's thanks to you and the realworldtech crowd.
Peter
del cecchi
"Rudi Chiarito" <ru...@amiga.com> wrote in message
news:m3vg42g...@amiga.com...
I don't know what they actually did, but it seems to me that the Easiest
Thing would have been to take the Power4 design, rip out one processor,
stick in the SIMD thing, maybe rip off the chip to chip ring
communications and bingo.
del cecchi
Rudi Chiarito
> I don't know what they actually did, but it seems to me that the Easiest
> Thing would have been to take the Power4 design, rip out one processor,
> stick in the SIMD thing, maybe rip off the chip to chip ring
> communications and bingo.
That's more than sensible and the reason why Book-E conformance
wasn't (in addition to this little thing called AIX compatibility).
Another question that a minority - two minority groups - might have
liked to see answered is whether the slimming/trimming process
ripped out the PowerPC-AS extensions or not.
Del Cecchi
I don't know. I probably could surmise by going and finding a copy of the system
road map but I couldn't disclose it anyway. It may be apparent next fall, since
i-series usually announces new stuff in the fall, or at least used to.