From: Bob Drzyzgula <bob@drzyzgula.org>
To: ultralinux@vger.kernel.org
Subject: Re: Ultra AXmp
Date: Sun, 26 Jul 1998 12:29:06 +0000 [thread overview]
Message-ID: <marc-linux-ultrasparc-90222358531087@msgid-missing> (raw)
In-Reply-To: <marc-linux-ultrasparc-90222358531013@msgid-missing>
On Sat, Jul 25, 1998 at 10:29:46PM -0600, Ward Deng wrote:
>
> On my datasheets, AXi (Panther) has 144-bit memory path while Pentium II
> is only 64-bit. AX (Photon) has 288-bit full-scale UPA. AXmp (Chrico)
> has two UPAs with 576-bit memory path. In our tests, even AXi has much
> better scalability than PII.
We have four of the AXi boards and have similarly
been very happy with them. Nonetheless, the
UltraSPARC IIi chip only has a 72-bit (64/8) window
on the memory subsystem. If you'll take a look at
http://www.sun.com/microelectronics/UltraSPARC-IIi/specs.html,
you'll see that the data lines feeding back to the
processor from the XCVR chip is only 72 bits wide.
On the AXi the path from the memory to the XCVR is 144
bits so that they can assure a full bandwidth feed to the
processor using commodity 60ns buffered EDO or FPM DIMMs.
I think that this is one reason why the AXi does so much
better than the PII on memory access; while both chips
have an 8-byte path to memory, the AXi is designed to keep
it filled. Note that, for example, you can usually run a
PII board with a single DIMM, while the AXi needs them in
multiples of two.
[The specs on the AXi claim only 400MBps for memory
throughput with a 300MHz processor. Since the path is
8 bytes wide, I concluded that the memory interface on
the 300MHz module runs at 50MHz, meaning that the 300MHz
processor is clock-sextupled. Does anyone know if this is
wrong? The block diagram shows the memory interface as
being runnable at 83MHz, I'd guess that the 333MHz chip
is clock-quadrupled?]
In the AXmp, the 576-bit channel is multiplexed down
to 144 bits into the processor; you can see this on
page 3-3 of the OEM manual:
http://www.sun.com/microelectronics/SPARCengineUltraAXmp/805-5865.pdf
(the block diagram on the Web is almost illegible).
Still, the AXmp has two such 144-bit channels,
each channel shared between up to two processors.
When these 16-byte busses are set to run at 100MHz,
they result in a 1.6GBps memory channel. Running
flat out with four processors, this thing should
be able to pump upward of 3GBps out of memory, which
is to me just an amazing number for something selling
at this price. [Does anyone know if the 360MHz
processor will be running at 120MHz tripled on
the AXmp as it does on the Ultra 60? If so, this
would crank the memory channels up to 1.9GBps]
We have four four-processor AXmps on order. I'm
looking forward to them...
You can see from this that the AXi and the AXmp are
designed with the same kind of proportions. The
AXi processor has a 8-byte-wide channel, so that the
the memory is accessed in 16-byte chunks to assure
a steady feed from commodity memory. In the AXmp,
there are two 16-byte-wide channels, requiring
a full-speed 32-byte-wide feed. Thus the commodity
memory is accessed in 64-byte chunks and multiplexed
down.
> Maybe SME should provide a version similar to
> Intel Celeron (joke) just for marketing purpose.
I suppose that, comparing the the UltraSPARC II
to the UltraSPARC IIi, it could be argued that
the IIi is SME's Celeron-equivalent. It just
happens to be a whole lot less embarrasing. :-)
--Bob
--
==============================
Bob Drzyzgula It's not a problem
bob@drzyzgula.org until something bad happens
==============================
next prev parent reply other threads:[~1998-07-26 12:29 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-07-11 18:36 Ultra AXmp Bob Drzyzgula
1998-07-12 1:56 ` David S. Miller
1998-07-12 2:21 ` Matthew Jacob
1998-07-12 2:29 ` David S. Miller
1998-07-12 5:02 ` Matthew Jacob
1998-07-12 12:54 ` Douglas Eadline
1998-07-12 23:59 ` Bob Drzyzgula
1998-07-13 6:27 ` Qiru Zhou
1998-07-13 6:38 ` David S. Miller
1998-07-13 10:40 ` Bob Drzyzgula
1998-07-13 12:09 ` Xavier Beaudouin
1998-07-13 13:59 ` Robert G. Brown
1998-07-13 14:29 ` Robert HYATT
1998-07-13 14:54 ` Matthew Jacob
1998-07-13 14:56 ` Matthew Jacob
1998-07-13 14:59 ` Matti Aarnio
1998-07-13 15:24 ` Robert HYATT
1998-07-13 15:38 ` Robert HYATT
1998-07-13 16:56 ` Robert G. Brown
1998-07-13 17:04 ` Robert G. Brown
1998-07-13 17:13 ` Lawrence D. Lopez
1998-07-13 17:26 ` Mike
1998-07-14 1:44 ` Shannon
1998-07-14 7:00 ` David S. Miller
1998-07-14 18:07 ` Douglas Eadline
1998-07-14 23:23 ` Bob Drzyzgula
1998-07-15 3:31 ` Dave Wreski
1998-07-15 8:07 ` Ward Deng
1998-07-15 11:14 ` Bob Drzyzgula
1998-07-15 11:27 ` David S. Miller
1998-07-15 15:54 ` Robert G. Brown
1998-07-15 17:11 ` Robert G. Brown
1998-07-15 23:22 ` Luis Ponce de Leao
1998-07-21 23:29 ` Ward Deng
1998-07-25 23:34 ` Ward Deng
1998-07-26 0:02 ` Ward Fenton
1998-07-26 0:45 ` Rich Martin
1998-07-26 3:34 ` Bob Drzyzgula
1998-07-26 4:00 ` Ward Deng
1998-07-26 4:29 ` Ward Deng
1998-07-26 12:29 ` Bob Drzyzgula [this message]
1998-07-26 13:57 ` Douglas Eadline
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-linux-ultrasparc-90222358531087@msgid-missing \
--to=bob@drzyzgula.org \
--cc=ultralinux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.