AMD has the answer for Intel

chrisv wrote:
On Fri, 3 Oct 2003 17:33:14 +0100, "Ben Pope"
wrote:

I would quite happily say to somebody "I have a 56K modem". I wouldn't
give the units.

Please try again. "I have a 56k modem" does not effectively
communicate to someone that you have a 2400bps modem.

Thats correct. But I don't have a 2400bps modem. I was drawing parallels
with factual information - something I actually recall saying. The idea
would be that you'd imply what I might say. Well here it is in all the gory
details for those acting stupid and requiring the full working spelt out in
detail:

When talking to a friend about a 9600bps RS232 (EIA/TIA 232 what are we up
to know, about -h?) serial connection I usually said "ninety six hundred"
without the units. So I guess I would say "twenty four hundred".

Ben
--
I'm not just a number. To many, I'm known as a String...

On Tue, 7 Oct 2003 19:04:37 +0100, "Ben Pope"
wrote:

chrisv wrote:

On Fri, 3 Oct 2003 17:33:14 +0100, "Ben Pope wrote:

chrisv wrote:

Tell us, how exactly would you say that to a lay person? Would you
say "2400 bee pee ess", or "2400 bits per second"? You see, there's a
reason "2400 baud" become nomenclature - it's quick, easy, and it
works, despite not being "technically correct".

I would quite happily say to somebody "I have a 56K modem". I wouldn't
give the units.

Please try again. "I have a 56k modem" does not effectively
communicate to someone that you have a 2400bps modem.

Thats correct. But I don't have a 2400bps modem.

But the subject was 2400bps modems, and I asked you a direct question
regarding the description of such. You claimed "2400bps" would work
"fine" as a description, and I wanted to know how you'd communicate
"2400bps" verbally. What are you afraid of?

Your continued evasion proves my point, that there's a reason why
"2400 baud" became common nomenclature. It's much easier to say than
"2400bps", and it served quite adequately as a descriptor of the
modem's data-transfer speed.

chrisv wrote:
On Tue, 7 Oct 2003 19:04:37 +0100, "Ben Pope"
wrote:

chrisv wrote:

On Fri, 3 Oct 2003 17:33:14 +0100, "Ben Pope wrote:

chrisv wrote:

Tell us, how exactly would you say that to a lay person? Would you
say "2400 bee pee ess", or "2400 bits per second"? You see, there's a
reason "2400 baud" become nomenclature - it's quick, easy, and it
works, despite not being "technically correct".

I would quite happily say to somebody "I have a 56K modem". I wouldn't
give the units.

Please try again. "I have a 56k modem" does not effectively
communicate to someone that you have a 2400bps modem.

Thats correct. But I don't have a 2400bps modem.

But the subject was 2400bps modems, and I asked you a direct question
regarding the description of such.

The crux of the argument was the units. I answered the question regarding
the crux of the argument.

You claimed "2400bps" would work
"fine" as a description, and I wanted to know how you'd communicate
"2400bps" verbally. What are you afraid of?

I'm not afriad of anything. You've snipped the bits where this is already
answered.

I said 2400bps is fine in response to you arguing against "600 baud modem
with quadrature amplitude modulation"

I said I probably wouldn't communicate the units verbally.

Which bits don't you understand?

Your continued evasion proves my point, that there's a reason why
"2400 baud" became common nomenclature. It's much easier to say than
"2400bps", and it served quite adequately as a descriptor of the
modem's data-transfer speed.


If I had to specify the units, I'd specify bps as it's correct. I'd
pronounce it "bee pee ess".

"It's much easier" is a pathetic excuse for using incorrect units, is that
really the best you can come up with?

Ben
--
I'm not just a number. To many, I'm known as a String...

In article ,
lid says...
On Sun, 5 Oct 2003 12:23:46 -0400, Keith R. Williams
wrote:

I'm also curious as to what, exactly, you would say to a lay person
regarding the "800MHz FSB"?
Because if you have a way to describe it,
that effectively communicates what's going, without being too
technical for anyone but a computer hardware geek, I may use your
suggestion.

Then why use a technical term like "baud" or "MHz" at all?
You're simply propagating ignorance that will have to be cleaned
up later. Words have meanings.

I get your point. However in the back of my mind is the short
attention span that people I know have for such details. Before I
ever got out the sentence "it means four data transfers per clock,
giving it the effective data throughput of an 800MHz bus", I'd be
interrupted or ignored.

Then why don't you just say 800bps (whatever that translates into
B/s), or better; *effectively* 800bps (or whatever units).
Perhaps you could use even; 200MHz, with an "effective...".
They're all stretches of the truth, but not out-and-out lies.

When my (not so techie friends) try to discuss these things I
stop them immediately. I don't wish to lie to friends. RAther
it's: "What do you want to do?"

--
Keith

Above is a signal. A is rising edge of the clock. B is falling edge of
the
clock. To me it is a cyclic event, when edge either rises or falls,

No, since a cycle defines something that repeats, over time. Rise !=
Fall.

Rise != Fall, that doesn't need to be specificly mentioned. But if a cycle
is *defined* with change of potential instead of specific type of change of
potential, herz apply. Each change of potential triggers event: arriving
data bit, which is a new cycle for this definition.

IF we were measuring the cyclic rate of the clock this is synchronized to, a
cycle would be period between same offset of the clock signal to the next,
say, from a rising edge to the next rising edge for example.

Clearly it is cyclic that a change of potential follows one another, at even
and steadily repeating intervals. Clearly it is cyclic that a data bit
follows one another, at even and steadily repeating intervals.

wogston wrote:
Above is a signal. A is rising edge of the clock. B is falling edge of
the clock. To me it is a cyclic event, when edge either rises or falls,

No, since a cycle defines something that repeats, over time. Rise !=
Fall.

Rise != Fall, that doesn't need to be specificly mentioned. But if a cycle
is *defined* with change of potential instead of specific type of change
of potential, herz apply. Each change of potential triggers event:
arriving data bit, which is a new cycle for this definition.

If I define black as white then the world changes, but that doesn't make it
true, does it?

IF we were measuring the cyclic rate of the clock this is synchronized
to, a cycle would be period between same offset of the clock signal to
the next, say, from a rising edge to the next rising edge for example.

Clearly it is cyclic that a change of potential follows one another, at
even and steadily repeating intervals. Clearly it is cyclic that a data
bit follows one another, at even and steadily repeating intervals.

As a programmer I can see where you're coming from, it's natural that you
abstract away the details and then completely ignore them. I just don't
agree with you here.

Ben
--
I'm not just a number. To many, I'm known as a String...

"wogston" writes:

Rise != Fall, that doesn't need to be specificly mentioned. But if a cycle
is *defined* with change of potential instead of specific type of change of
potential, herz apply. Each change of potential triggers event: arriving
data bit, which is a new cycle for this definition.

(wogston -- That's such a simple explanation it's hard to believe some
people can't understand it. It's the interval that's fixed, not the
phenomenon occuring within the interval.)

I've discovered that there's no need to resort to unpopular
definitions of cycle, at least in the case of the Pentium 4 CPU. I
was looking for some high-temp reliability info ("CPU life decreases
by X for every Y degrees below Z" -- anybody have a URL?) that I had
recently seen and found myself scrolling by some P4 FSB description in
http://www.intel.com/design/Pentium4...s/29864310.pdf, with pages
20 and 54 being the most interesting. Sadly, the document has almost
no timing diagrams and the descriptions leave a lot to be desired, but
I'm fairly sure that the FSB actually has clock signals (called
"strobes") that run at 800 MHz (i.e., they repeat their waveform at
800 million times per second). There are actually four such signals
(one for each block of 16 data lines) and they are differential
signals (like the 200 MHz clock lines, but not like the address
strobes) so they have two complementary lines. The data on 16 data
lines is latched in (at 800 MHz by the falling edge of each data
strobe signal. (I.e., as DSTRBP and DSTRBN logic values go from 1 to
0, the DSTRBP-DSTRBN voltage difference goes from positive to
negative, and the data is latched in. (I might have the senses wrong,
but you should get the idea.)) There is strict control of bus line
lengths for each set of 16 bits so that the sampling is done about
halfway between data line (800 MHz) changes. Each set of 16 and it's
strobe can be a bit different from each other and from an imaginary
800 MHz FSB clock synced to the real 200 MHz FSB clock. One set of
circuitry generates the strobes and associated data at the source
(based on the 200 MHz clock), but by the time it makes it to the
destination, the 4 sets can be a bit different. While some things are
timed relative to the 200 MHz FSB clock at the destination, the data
latching is timed relative to the slightly different strobes, which is
apparently why they prefer to not think of them as clocks, even though
the actually are, IMO.

I found a better explanation of the "source synchronous" scheme as
it's implemented for AGP 4X, and it works the same way, only slower.

I'll also note that on page 30 they say that the "system bus
frequency" is 800 MHz and that the "processor input clock" (or "bus
clock") is 200 HMz. AFAIK, they're not lying or even stretching the
truth. (If the AMD case isn't similar, I'd be happy to resort to the
cycle definition justification, but I have no plans to investigate.)

The address lines are handled more simply and are clocked off the
the rising and falling edges of non-differential 200 MHz strobes (for
400 Mbps).

Note: Most P4 FSB signals are defined one of two ways (again, I might
have the senses wrong; it's too easy to get it wrong so I don't bother
trying when it doesn't matter):

For non-differential signals: Using two supplied voltages, V and about
0.66 * V, a signal is "zero" when it's single line is 0.0 to 0.9 *
0.66 * V and "one" is 1.1 * 0.66 * V to V.

For differential signals: The signal's two lines are simply
differenced and sign changes (pos, neg, or both) signal events.


As you can tell, I'm no CPU or EE guru, so if somebody can show me
some evidence for a different opinion, I'd welcome it.

Ben Pope wrote:
Gary W. Swearingen wrote:
There are actually four such signals
(one for each block of 16 data lines) and they are differential
signals (like the 200 MHz clock lines, but not like the address
strobes) so they have two complementary lines. The data on 16 data
lines is latched in (at 800 MHz

So now it's 800MHz * 4? I don't think so. This is getting rediculous.
There are four clocks for each group of 16 bits (64 bits, the data bus
width), each running at 200MHz.

Ignore that - this is so annoying.

It's clearly 64 bits (8 bytes) * 800Million transfer/s since there's 6.4GB/s
total transfer rate.

So I don't know how they get their "quad pumping".

I can't find it in that document, which is supposedly the data sheet and I
can;t find any documents that would be better.

by the falling edge of each data
strobe signal. (I.e., as DSTRBP and DSTRBN logic values go from 1 to
0, the DSTRBP-DSTRBN voltage difference goes from positive to
negative, and the data is latched in. (I might have the senses wrong,
but you should get the idea.))

Yeah. To me that looks like all 64 bits of the data bus D[63:0] are
latched on the falling edge of 4 200MHz signals across the differential
pairs DSTBP[3:0] and DSTBN[3:0].

Ignore that too.

Ben
--
I'm not just a number. To many, I'm known as a String...

On Wed, 08 Oct 2003 18:20:27 GMT, (Gary W. Swearingen)
wrote:

"wogston" writes:

Rise != Fall, that doesn't need to be specificly mentioned. But if a cycle
is *defined* with change of potential instead of specific type of change of
potential, herz apply. Each change of potential triggers event: arriving
data bit, which is a new cycle for this definition.

(wogston -- That's such a simple explanation it's hard to believe some
people can't understand it. It's the interval that's fixed, not the
phenomenon occuring within the interval.)

I've discovered that there's no need to resort to unpopular
definitions of cycle, at least in the case of the Pentium 4 CPU.

Nope.

I
was looking for some high-temp reliability info ("CPU life decreases
by X for every Y degrees below Z" -- anybody have a URL?) that I had
recently seen and found myself scrolling by some P4 FSB description in
http://www.intel.com/design/Pentium4...s/29864310.pdf, with pages
20 and 54 being the most interesting.

Try 24988703.pdf, Note 12 on page 27.

Sadly, the document has almost
no timing diagrams and the descriptions leave a lot to be desired, but
I'm fairly sure that the FSB actually has clock signals (called
"strobes") that run at 800 MHz (i.e., they repeat their waveform at
800 million times per second).

Nope - you're misreading or extrapolating to get the desired result... and
it doesn't make sense anyway. As I've already pointed out twice, the two
clocks run at 400MHz, 180° out of phase.

There are actually four such signals
(one for each block of 16 data lines) and they are differential
signals (like the 200 MHz clock lines, but not like the address
strobes) so they have two complementary lines. The data on 16 data
lines is latched in (at 800 MHz by the falling edge of each data
strobe signal. (I.e., as DSTRBP and DSTRBN logic values go from 1 to
0, the DSTRBP-DSTRBN voltage difference goes from positive to
negative, and the data is latched in. (I might have the senses wrong,
but you should get the idea.))

Obviously you didn't... "get the idea". 800MHz clocks do not fit your
assumption.

I found a better explanation of the "source synchronous" scheme as
it's implemented for AGP 4X, and it works the same way, only slower.

Like I pointed out several days ago, if you want timing diagrams... yes,
the AGP 4x describes quad pumping similar to the P4 FSB.

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??

On Wed, 8 Oct 2003 20:34:23 +0100, "Ben Pope" wrote:

Gary W. Swearingen wrote:

Sadly, the document has almost
no timing diagrams and the descriptions leave a lot to be desired, but
I'm fairly sure that the FSB actually has clock signals (called
"strobes") that run at 800 MHz (i.e., they repeat their waveform at
800 million times per second).

I can't find any reference to repeating waveform at 800MHz in any text
surrounding "strobe".

It is *not* there.

There are actually four such signals
(one for each block of 16 data lines) and they are differential
signals (like the 200 MHz clock lines, but not like the address
strobes) so they have two complementary lines. The data on 16 data
lines is latched in (at 800 MHz

So now it's 800MHz * 4? I don't think so. This is getting rediculous.
There are four clocks for each group of 16 bits (64 bits, the data bus
width), each running at 200MHz.

If you read the details, especially in the previous 24988703.pdf, the data
bus strobe clocks are running at 400MHz. Nothing else fits the
descriptions.

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??