Is Pseudo-Sync the same as "asynchronous mode"?

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

In comp.sys.ibm.pc.hardware.chips David Maynard <dNOTmayn@ev1.net> wrote:
> David Wang wrote:
> > In comp.sys.ibm.pc.hardware.chips David Maynard <dNOTmayn@ev1.net> wrote:
> >
> >>http://www.ece.neu.edu/students/dmorano/talks/nucar990528.pdf
> >
> > Mr Morano's presentations do not address the points I had raised
> > about your definitions.

> It addresses *the* point: EDO/FPM asynchronous memory.

That's Mr Morano's presentation to his class. I don't think
that by its presence on the web, it automatically means we
all have to agree with everything that is written on it,
including terminology that he may have used to convey an
idea, but may not have been defined precisely.

When I get around to this aspect of the memory system,
I try to inject more than just the buzzwords of "synchronous"
and "asynchronous" into the discussion, because to me,
the "synchronous" memory system isn't very much so, and
if we had real asynchronous memory busses with built in
hand shaking between the DRAM controller and DRAM devices,
then perhaps we wouldn't need to deal with timing problems.

http://www.ece.umd.edu/courses/enee759h.S2003/lectures/Lecture10.pdf

The problem here is that "SDRAM" is by definition "Synchronous",
and EDO/FPM isn't "synchronous" as SDRAM was defined. So what
is EDO/FPM? So we take the path that says if it's not
synchronous, then it must be asynchronous? Or do we look
deeper?

It's not "asynchronous" as in the classical sense of the word,
much less a "classical asynchronous memory bus". Truth of the
matter is that you can't design a real asynchronous memory
controller to interface with EDO/FPM, because the timing
of those DRAM devices have to be known a priori, and the
controller has to know when to assert those signals. In a
"classical asynchronous interface" that timing has to be
negotiated, and the DRAM device will dictate to the controller
when the data will come.

> > Burst capability != synchronous.

> I didn't mean to suggest it did and sorry if you got that impression.

You spent quite a bit of time to differentiate between SDRAM
and FPM/EDO. I doubt that I received that "impression" on my
own accord.

> > DDRx SDRAM/D RDRAM/SLDRAM use multiple clock/strobe signals for
> > synchronization.

> The key word is "clock."

Which one(s)?

--
davewang202(at)yahoo(dot)com

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

On Sun, 26 Sep 2004 17:04:27 -0500, David Maynard <dNOTmayn@ev1.net> wrote:

>Since your replies have degenerated to gibberish I take it you've finally
>realized that FPM/EDO memory, and the bus it's on, is asynchronous.

What is it that you fail to grasp about being crushed by three different
people?

Rgds, George Macdonald

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

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

George Macdonald wrote:

> On Sun, 26 Sep 2004 17:04:27 -0500, David Maynard <dNOTmayn@ev1.net> wrote:
>
>
>>Since your replies have degenerated to gibberish I take it you've finally
>>realized that FPM/EDO memory, and the bus it's on, is asynchronous.
>
>
> What is it that you fail to grasp about being crushed by three different
> people?

What I 'grasp' are authoritative sources, such as crucial-micron, rather
than vapid 'titters' and bombastic chest thumping.


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

 

[keith]

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

On Mon, 27 Sep 2004 19:29:57 -0400, George Macdonald wrote:

> On Sun, 26 Sep 2004 17:04:27 -0500, David Maynard <dNOTmayn@ev1.net> wrote:
>
>>Since your replies have degenerated to gibberish I take it you've finally
>>realized that FPM/EDO memory, and the bus it's on, is asynchronous.
>
> What is it that you fail to grasp about being crushed by three different
> people?

Reality.

--
Keith

 

[keith]

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

On Mon, 27 Sep 2004 20:27:40 -0500, David Maynard wrote:

> George Macdonald wrote:
>
>> On Sun, 26 Sep 2004 17:04:27 -0500, David Maynard <dNOTmayn@ev1.net> wrote:
>>
>>
>>>Since your replies have degenerated to gibberish I take it you've finally
>>>realized that FPM/EDO memory, and the bus it's on, is asynchronous.
>>
>>
>> What is it that you fail to grasp about being crushed by three different
>> people?
>
> What I 'grasp' are authoritative sources, such as crucial-micron, rather
> than vapid 'titters' and bombastic chest thumping.

You are simply beyonf ignorant, and have indeed fallen off the stupid
cliff. You haven't made sense since you got involved in this thread, way
back when we were discussing the *PCI BRIDGE* characteristics. The simple
*FACT* is that all PC (and all other current systems I know about) memory
*systems* are *SYNCHRONOUS*. Your misunderstanding of what others have to
say doesn't make you any more correct, rather simply more pig-headed;
swilling in your ignorance.

Would you call a wire asynchronous? It's not clocked. The wire from the
chipset to an SDRAM module is then asynchronous, thus SDRAM is asynchrous,
by Maynardian logic. Thus all computer interfaces (inside and outside the
processor) are asynchronous since they all have wires.

As Mr. Wang, Mr. Macdonald, and I have been trying to beat through your
thick skull, the chipset launches the address/command on a clock edge and
gathers the result on a clock edge, the system is by definition
*synchronous*, no matter how may wires are inbetween. SDRAM is no
different, except that the clocked interface is closer to the
asynchronous DRAM cell. It's all *synchronous*.

....again, which has nothing to do with a/pseudo-synchronous PCI bridges.

Got it yet? You know, you are speaking with professionals. Sheesh! Wise
up!

--
Keith

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

keith wrote:

> On Mon, 27 Sep 2004 20:27:40 -0500, David Maynard wrote:
>
>
>>George Macdonald wrote:
>>
>>
>>>On Sun, 26 Sep 2004 17:04:27 -0500, David Maynard <dNOTmayn@ev1.net> wrote:
>>>
>>>
>>>
>>>>Since your replies have degenerated to gibberish I take it you've finally
>>>>realized that FPM/EDO memory, and the bus it's on, is asynchronous.
>>>
>>>
>>>What is it that you fail to grasp about being crushed by three different
>>>people?
>>
>>What I 'grasp' are authoritative sources, such as crucial-micron, rather
>>than vapid 'titters' and bombastic chest thumping.
>
>
> You are simply beyonf ignorant, and have indeed fallen off the stupid
> cliff.

I would have though that by now you'd have gotten the clue that simply
screaming "you're stupid" at someone doesn't constitute a technical
argument nor does it 'crush' one.

<snip of babble>

> As Mr. Wang, Mr. Macdonald, and I have been trying to beat through your
> thick skull, the chipset launches the address/command on a clock edge and
> gathers the result on a clock edge, the system is by definition
> *synchronous*, no matter how may wires are inbetween.

And what I've been explaining to you, by use of authoritative sources, is
that simply because the timing signals occur at the 'right time', which ANY
kind of circuit has to do in order to work, doesn't make it "synchronous"
as the term is defined in the digital electronics world.


> SDRAM is no
> different, except that the clocked interface is closer to the
> asynchronous DRAM cell.

And the fact that there IS a clocked interface there is why it's called
S(ynchronous)DRAM, as opposed asynchronous DRAM that has NO common clock.

> It's all *synchronous*.

Incorrect. And that fact that it isn't is why some types have things like
"synchronous" in the name to distinguish them from those that are NOT
synchronous.

> ...again, which has nothing to do with a/pseudo-synchronous PCI bridges.

According to you, *everything* is 'synchronous'.

>
> Got it yet? You know, you are speaking with professionals. Sheesh! Wise
> up!

Then you should brush up on what synchronous means.

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

keith wrote:

> On Mon, 27 Sep 2004 20:27:40 -0500, David Maynard wrote:
>
>
>>George Macdonald wrote:
>>
>>
>>>On Sun, 26 Sep 2004 17:04:27 -0500, David Maynard <dNOTmayn@ev1.net> wrote:
>>>
>>>
>>>
>>>>Since your replies have degenerated to gibberish I take it you've finally
>>>>realized that FPM/EDO memory, and the bus it's on, is asynchronous.
>>>
>>>
>>>What is it that you fail to grasp about being crushed by three different
>>>people?
>>
>>What I 'grasp' are authoritative sources, such as crucial-micron, rather
>>than vapid 'titters' and bombastic chest thumping.
>
>
> You are simply beyonf ignorant, and have indeed fallen off the stupid
> cliff. You haven't made sense since you got involved in this thread, way
> back when we were discussing the *PCI BRIDGE* characteristics. The simple
> *FACT* is that all PC (and all other current systems I know about) memory
> *systems* are *SYNCHRONOUS*. Your misunderstanding of what others have to
> say doesn't make you any more correct, rather simply more pig-headed;
> swilling in your ignorance.
>
> Would you call a wire asynchronous? It's not clocked. The wire from the
> chipset to an SDRAM module is then asynchronous, thus SDRAM is asynchrous,
> by Maynardian logic. Thus all computer interfaces (inside and outside the
> processor) are asynchronous since they all have wires.
>
> As Mr. Wang, Mr. Macdonald, and I have been trying to beat through your
> thick skull, the chipset launches the address/command on a clock edge and
> gathers the result on a clock edge, the system is by definition
> *synchronous*, no matter how may wires are inbetween. SDRAM is no
> different, except that the clocked interface is closer to the
> asynchronous DRAM cell. It's all *synchronous*.
_____________
synchronous

adj 1: occurring or existing at the same time or having the same period
or phase; "recovery was synchronous with therapy"- Jour.A.M.A.; "a
synchronous set of clocks"; "the synchronous action of a bird's wings in
flight"; "synchronous oscillations" [syn: synchronal, synchronic] [ant:
asynchronous] 2: (digital communication) pertaining to a transmission
technique that requires a common clock signal (a timing reference)
between the communicating devices in order to coordinate their
transmissions [ant: asynchronous]

Source: WordNet ® 2.0, © 2003 Princeton University
_____________

SDRAM and the chipset share a common clock, therefore synchronous by the
above definition 2:

FPM/EDO RAM does not share a clock with the chipset, but the chipset
addresses the memory on clock edges, therefore synchronous by the above
definition 1:

Seems to me you are all arguing, quite acrimoniously, as to whether
syncronicity in a digital interface requires a common clock (Maynard) or
if the same period will do (Wang et al).

Semantics!


>
> ...again, which has nothing to do with a/pseudo-synchronous PCI bridges.
>
> Got it yet? You know, you are speaking with professionals. Sheesh! Wise
> up!
>

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

Triffid wrote:

>
>
> keith wrote:
>
>> On Mon, 27 Sep 2004 20:27:40 -0500, David Maynard wrote:
>>
>>
>>> George Macdonald wrote:
>>>
>>>
>>>> On Sun, 26 Sep 2004 17:04:27 -0500, David Maynard <dNOTmayn@ev1.net>
>>>> wrote:
>>>>
>>>>
>>>>
>>>>> Since your replies have degenerated to gibberish I take it you've
>>>>> finally realized that FPM/EDO memory, and the bus it's on, is
>>>>> asynchronous.
>>>>
>>>>
>>>>
>>>> What is it that you fail to grasp about being crushed by three
>>>> different
>>>> people?
>>>
>>>
>>> What I 'grasp' are authoritative sources, such as crucial-micron,
>>> rather than vapid 'titters' and bombastic chest thumping.
>>
>>
>>
>> You are simply beyonf ignorant, and have indeed fallen off the stupid
>> cliff. You haven't made sense since you got involved in this thread, way
>> back when we were discussing the *PCI BRIDGE* characteristics. The
>> simple
>> *FACT* is that all PC (and all other current systems I know about) memory
>> *systems* are *SYNCHRONOUS*. Your misunderstanding of what others
>> have to
>> say doesn't make you any more correct, rather simply more pig-headed;
>> swilling in your ignorance.
>>
>> Would you call a wire asynchronous? It's not clocked. The wire from the
>> chipset to an SDRAM module is then asynchronous, thus SDRAM is
>> asynchrous,
>> by Maynardian logic. Thus all computer interfaces (inside and outside the
>> processor) are asynchronous since they all have wires.
>>
>> As Mr. Wang, Mr. Macdonald, and I have been trying to beat through your
>> thick skull, the chipset launches the address/command on a clock edge and
>> gathers the result on a clock edge, the system is by definition
>> *synchronous*, no matter how may wires are inbetween. SDRAM is no
>> different, except that the clocked interface is closer to the
>> asynchronous DRAM cell. It's all *synchronous*.
>
> _____________
> synchronous
>
> adj 1: occurring or existing at the same time or having the same period
> or phase; "recovery was synchronous with therapy"- Jour.A.M.A.; "a
> synchronous set of clocks"; "the synchronous action of a bird's wings in
> flight"; "synchronous oscillations" [syn: synchronal, synchronic] [ant:
> asynchronous] 2: (digital communication) pertaining to a transmission
> technique that requires a common clock signal (a timing reference)
> between the communicating devices in order to coordinate their
> transmissions [ant: asynchronous]
>
> Source: WordNet ® 2.0, © 2003 Princeton University
> _____________
>
> SDRAM and the chipset share a common clock, therefore synchronous by the
> above definition 2:
>
> FPM/EDO RAM does not share a clock with the chipset, but the chipset
> addresses the memory on clock edges, therefore synchronous by the above
> definition 1:
>
> Seems to me you are all arguing, quite acrimoniously, as to whether
> syncronicity in a digital interface requires a common clock (Maynard) or
> if the same period will do (Wang et al).
>
> Semantics!

You're correct in that 'synchronous' has different connotations in
different contexts.

When speaking of an electronic bus the electronic context is the proper one.

 

[keith]

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

On Mon, 27 Sep 2004 22:07:03 -0500, David Maynard wrote:

> keith wrote:
>
>> On Mon, 27 Sep 2004 20:27:40 -0500, David Maynard wrote:
>>
>>
>>>George Macdonald wrote:
>>>
>>>
>>>>On Sun, 26 Sep 2004 17:04:27 -0500, David Maynard <dNOTmayn@ev1.net> wrote:
>>>>
>>>>
>>>>
>>>>>Since your replies have degenerated to gibberish I take it you've finally
>>>>>realized that FPM/EDO memory, and the bus it's on, is asynchronous.
>>>>
>>>>
>>>>What is it that you fail to grasp about being crushed by three different
>>>>people?
>>>
>>>What I 'grasp' are authoritative sources, such as crucial-micron, rather
>>>than vapid 'titters' and bombastic chest thumping.
>>
>>
>> You are simply beyonf ignorant, and have indeed fallen off the stupid
>> cliff.
>
> I would have though that by now you'd have gotten the clue that simply
> screaming "you're stupid" at someone doesn't constitute a technical
> argument nor does it 'crush' one.

You've been crushed by the best, yet refuse to listen to the simple facts.
>
> <snip of babble>
>
>> As Mr. Wang, Mr. Macdonald, and I have been trying to beat through your
>> thick skull, the chipset launches the address/command on a clock edge
>> and gathers the result on a clock edge, the system is by definition
>> *synchronous*, no matter how may wires are inbetween.
>
> And what I've been explaining to you, by use of authoritative sources,

You simply don't understand your "authoritative" sources. It's quite
obvious that you're beyond education, so we'll just try to educate the
rest out there who may still be listening; If there is one clock
synchronizing events, it is, by definition, a *synchronous* system. If
thre are clocks that are not synchronized, or if there is an unclocked
ready/acknowledge sort of handshake then it is known as asynchronous.
....end of tune.

> is that simply because the timing signals occur at the 'right time',
> which ANY kind of circuit has to do in order to work, doesn't make it
> "synchronous" as the term is defined in the digital electronics world.

Is anyone really this ignorant, while throwing around random
engineering jargon? There are interfaces that do not rely on clock edges
to transmit data. One can in-gate data on receipt of a "ready" and
signal the sender to transmit new data with an acknowledge. ...no clocks,
it's then "asynchronous". The receiver tells the transmitter when to send
new data (the datarate is independent of a clock). A receiver may receive
data on a different clock than the sender uses to transmit data (your UART
example). These are asynchronous interfaces (not clocked). "asynchronous
memory uses none of these techniques, rather it's used within a single
clocked domain, thus *SYNCHRONOUS*.

....I'm sure you still just don't "get it". Hopefully others will.

--
Keith
>> SDRAM is no
>> different, except that the clocked interface is closer to the
>> asynchronous DRAM cell.
>
> And the fact that there IS a clocked interface there is why it's called
> S(ynchronous)DRAM, as opposed asynchronous DRAM that has NO common
> clock.
>
>> It's all *synchronous*.
>
> Incorrect. And that fact that it isn't is why some types have things
> like "synchronous" in the name to distinguish them from those that are
> NOT synchronous.
>
>> ...again, which has nothing to do with a/pseudo-synchronous PCI
>> bridges.
>
> According to you, *everything* is 'synchronous'.
>
>
>> Got it yet? You know, you are speaking with professionals. Sheesh!
>> Wise up!
>
> Then you should brush up on what synchronous means.

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

keith wrote:

> On Mon, 27 Sep 2004 22:07:03 -0500, David Maynard wrote:
>
>
>>keith wrote:
>>
>>
>>>On Mon, 27 Sep 2004 20:27:40 -0500, David Maynard wrote:
>>>
>>>
>>>
>>>>George Macdonald wrote:
>>>>
>>>>
>>>>
>>>>>On Sun, 26 Sep 2004 17:04:27 -0500, David Maynard <dNOTmayn@ev1.net> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Since your replies have degenerated to gibberish I take it you've finally
>>>>>>realized that FPM/EDO memory, and the bus it's on, is asynchronous.
>>>>>
>>>>>
>>>>>What is it that you fail to grasp about being crushed by three different
>>>>>people?
>>>>
>>>>What I 'grasp' are authoritative sources, such as crucial-micron, rather
>>>>than vapid 'titters' and bombastic chest thumping.
>>>
>>>
>>>You are simply beyonf ignorant, and have indeed fallen off the stupid
>>>cliff.
>>
>>I would have though that by now you'd have gotten the clue that simply
>>screaming "you're stupid" at someone doesn't constitute a technical
>>argument nor does it 'crush' one.
>
>
> You've been crushed by the best, yet refuse to listen to the simple facts.
>
>> <snip of babble>
>>
>>>As Mr. Wang, Mr. Macdonald, and I have been trying to beat through your
>>>thick skull, the chipset launches the address/command on a clock edge
>>>and gathers the result on a clock edge, the system is by definition
>>>*synchronous*, no matter how may wires are inbetween.
>>
>>And what I've been explaining to you, by use of authoritative sources,
>
>
> You simply don't understand your "authoritative" sources. It's quite
> obvious that you're beyond education, so we'll just try to educate the
> rest out there who may still be listening; If there is one clock
> synchronizing events, it is, by definition, a *synchronous* system.

This is what's called a "circular definition." I.E. If it's "synchronizing
events" then it's 'synchronous'.

But as intuitive as that may seem, it is not the definition of a
synchronous bus in the realm of electronics. A synchronous bus is defined
as having a common clock, that the devices are synchronized to, on the bus
and not that, by some means, things happen 'at the right time' (a 'given'
for a properly operating circuit). It defines the means by how that timing
is achieved: synchronizing events to the common bus clock.

> If
> thre are clocks that are not synchronized, or if there is an unclocked
> ready/acknowledge sort of handshake then it is known as asynchronous.

And how would the data be detected at your 'asynchronous' clocked interface
if it was not sensed at the proper time? e.g. when the 'not synchronized'
clock occurred?

The answer, of course, is that the data IS there when the clock occurs,...
and for some time before and some time after: asynchronously, as with
FPM/EDO DRAM.


> ...end of tune.
>
>
>>is that simply because the timing signals occur at the 'right time',
>>which ANY kind of circuit has to do in order to work, doesn't make it
>>"synchronous" as the term is defined in the digital electronics world.
>
>
> Is anyone really this ignorant, while throwing around random
> engineering jargon? There are interfaces that do not rely on clock edges
> to transmit data. One can in-gate data on receipt of a "ready" and
> signal the sender to transmit new data with an acknowledge. ...no clocks,
> it's then "asynchronous". The receiver tells the transmitter when to send
> new data (the datarate is independent of a clock). A receiver may receive
> data on a different clock than the sender uses to transmit data (your UART
> example). These are asynchronous interfaces

That is all true. As you've noted, there's more than 'just one' kind of
asynchronous technique.

> (not clocked).

So "A receiver may receive data on a different clock" is equivalent to "not
clocked?"

The receiver IS, in fact, clocked and the data *must* be valid 'in time
with' that clock or else it does not function properly. Even so, it is, as
you correctly point out, an asynchronous interface because the two ends do
not share a common clock, just as FPM/EDO does not share a common clock
with the memory controller: an intuitively obvious observation since it has
no clock at all, much less a shared one.

> "asynchronous
> memory uses none of these techniques, rather it's used within a single
> clocked domain, thus *SYNCHRONOUS*.

As crucial-micron correctly points out there is no common clock on an
FPM/EDO memory bus.

See, what you've tried to define is that as long as there's a 'clocked'
processor then nothing connected to it could ever be 'asynchronous' because
the data *must* be sensed on the clock. But this is clearly not the case.


>
> ...I'm sure you still just don't "get it". Hopefully others will.
>

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

On Mon, 27 Sep 2004 20:27:40 -0500, David Maynard <dNOTmayn@ev1.net> wrote:

>George Macdonald wrote:
>
>> On Sun, 26 Sep 2004 17:04:27 -0500, David Maynard <dNOTmayn@ev1.net> wrote:
>>
>>
>>>Since your replies have degenerated to gibberish I take it you've finally
>>>realized that FPM/EDO memory, and the bus it's on, is asynchronous.
>>
>>
>> What is it that you fail to grasp about being crushed by three different
>> people?
>
>What I 'grasp' are authoritative sources, such as crucial-micron, rather
>than vapid 'titters' and bombastic chest thumping.

The titters are purely due to your strange assumption that you are somehow
correcting us when in fact the only one who's been quite visibly corrected
here is you... "right in front of God an' everbody"!

Rgds, George Macdonald

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

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

George Macdonald wrote:
> On Mon, 27 Sep 2004 20:27:40 -0500, David Maynard <dNOTmayn@ev1.net> wrote:
>
>
>>George Macdonald wrote:
>>
>>
>>>On Sun, 26 Sep 2004 17:04:27 -0500, David Maynard <dNOTmayn@ev1.net> wrote:
>>>
>>>
>>>
>>>>Since your replies have degenerated to gibberish I take it you've finally
>>>>realized that FPM/EDO memory, and the bus it's on, is asynchronous.
>>>
>>>
>>>What is it that you fail to grasp about being crushed by three different
>>>people?
>>
>>What I 'grasp' are authoritative sources, such as crucial-micron, rather
>>than vapid 'titters' and bombastic chest thumping.
>
>
> The titters are purely due to your strange assumption that you are somehow
> correcting us when in fact the only one who's been quite visibly corrected
> here is you... "right in front of God an' everbody"!

Well, when I read that I was duly impressed but when I checked the
crucial-micron web site it wasn't 'corrected' at all.

I guess they weren't impressed with 'titters' and chest thumping as an
argument either.

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

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

On Tue, 28 Sep 2004 17:23:32 -0500, David Maynard <dNOTmayn@ev1.net> wrote:

>George Macdonald wrote:
>> On Mon, 27 Sep 2004 20:27:40 -0500, David Maynard <dNOTmayn@ev1.net> wrote:
>>
>>
>>>George Macdonald wrote:
>>>
>>>
>>>>On Sun, 26 Sep 2004 17:04:27 -0500, David Maynard <dNOTmayn@ev1.net> wrote:
>>>>
>>>>
>>>>
>>>>>Since your replies have degenerated to gibberish I take it you've finally
>>>>>realized that FPM/EDO memory, and the bus it's on, is asynchronous.
>>>>
>>>>
>>>>What is it that you fail to grasp about being crushed by three different
>>>>people?
>>>
>>>What I 'grasp' are authoritative sources, such as crucial-micron, rather
>>>than vapid 'titters' and bombastic chest thumping.
>>
>>
>> The titters are purely due to your strange assumption that you are somehow
>> correcting us when in fact the only one who's been quite visibly corrected
>> here is you... "right in front of God an' everbody"!
>
>Well, when I read that I was duly impressed but when I checked the
>crucial-micron web site it wasn't 'corrected' at all.

Already answered: I cannot help it nor can I be held responsible when you
read independent info and choose to bend it fit your weird agenda. Your
piteous attempts at countering David Wang's view are truly pathetic - give
up before you embarrass yourself further.

Rgds, George Macdonald

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

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

George Macdonald wrote:

> On Tue, 28 Sep 2004 17:23:32 -0500, David Maynard <dNOTmayn@ev1.net> wrote:
>
>
>>George Macdonald wrote:
>>
>>>On Mon, 27 Sep 2004 20:27:40 -0500, David Maynard <dNOTmayn@ev1.net> wrote:
>>>
>>>
>>>
>>>>George Macdonald wrote:
>>>>
>>>>
>>>>
>>>>>On Sun, 26 Sep 2004 17:04:27 -0500, David Maynard <dNOTmayn@ev1.net> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Since your replies have degenerated to gibberish I take it you've finally
>>>>>>realized that FPM/EDO memory, and the bus it's on, is asynchronous.
>>>>>
>>>>>
>>>>>What is it that you fail to grasp about being crushed by three different
>>>>>people?
>>>>
>>>>What I 'grasp' are authoritative sources, such as crucial-micron, rather
>>>>than vapid 'titters' and bombastic chest thumping.
>>>
>>>
>>>The titters are purely due to your strange assumption that you are somehow
>>>correcting us when in fact the only one who's been quite visibly corrected
>>>here is you... "right in front of God an' everbody"!
>>
>>Well, when I read that I was duly impressed but when I checked the
>>crucial-micron web site it wasn't 'corrected' at all.
>
>
> Already answered: I cannot help it nor can I be held responsible when you
> read independent info and choose to bend it fit your weird agenda. Your
> piteous attempts at countering David Wang's view are truly pathetic - give
> up before you embarrass yourself further.

Thank you the kind concern so characteristic of your genial nature. I will
give it all the consideration it deserves.

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

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

David Maynard wrote:
> Triffid wrote:
>
>>
>>
>> keith wrote:
>>
>>> On Mon, 27 Sep 2004 20:27:40 -0500, David Maynard wrote:
>>>
>>>
>>>> George Macdonald wrote:
>>>>
>>>>
>>>>> On Sun, 26 Sep 2004 17:04:27 -0500, David Maynard
>>>>> <dNOTmayn@ev1.net> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Since your replies have degenerated to gibberish I take it you've
>>>>>> finally realized that FPM/EDO memory, and the bus it's on, is
>>>>>> asynchronous.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> What is it that you fail to grasp about being crushed by three
>>>>> different
>>>>> people?
>>>>
>>>>
>>>>
>>>> What I 'grasp' are authoritative sources, such as crucial-micron,
>>>> rather than vapid 'titters' and bombastic chest thumping.
>>>
>>>
>>>
>>>
>>> You are simply beyonf ignorant, and have indeed fallen off the stupid
>>> cliff. You haven't made sense since you got involved in this thread, way
>>> back when we were discussing the *PCI BRIDGE* characteristics. The
>>> simple
>>> *FACT* is that all PC (and all other current systems I know about)
>>> memory
>>> *systems* are *SYNCHRONOUS*. Your misunderstanding of what others
>>> have to
>>> say doesn't make you any more correct, rather simply more pig-headed;
>>> swilling in your ignorance.
>>>
>>> Would you call a wire asynchronous? It's not clocked. The wire from
>>> the
>>> chipset to an SDRAM module is then asynchronous, thus SDRAM is
>>> asynchrous,
>>> by Maynardian logic. Thus all computer interfaces (inside and outside
>>> the
>>> processor) are asynchronous since they all have wires.
>>>
>>> As Mr. Wang, Mr. Macdonald, and I have been trying to beat through your
>>> thick skull, the chipset launches the address/command on a clock edge
>>> and
>>> gathers the result on a clock edge, the system is by definition
>>> *synchronous*, no matter how may wires are inbetween. SDRAM is no
>>> different, except that the clocked interface is closer to the
>>> asynchronous DRAM cell. It's all *synchronous*.
>>
>>
>> _____________
>> synchronous
>>
>> adj 1: occurring or existing at the same time or having the same
>> period or phase; "recovery was synchronous with therapy"- Jour.A.M.A.;
>> "a synchronous set of clocks"; "the synchronous action of a bird's
>> wings in flight"; "synchronous oscillations" [syn: synchronal,
>> synchronic] [ant: asynchronous] 2: (digital communication) pertaining
>> to a transmission technique that requires a common clock signal (a
>> timing reference) between the communicating devices in order to
>> coordinate their transmissions [ant: asynchronous]
>>
>> Source: WordNet ® 2.0, © 2003 Princeton University
>> _____________
>>
>> SDRAM and the chipset share a common clock, therefore synchronous by
>> the above definition 2:
>>
>> FPM/EDO RAM does not share a clock with the chipset, but the chipset
>> addresses the memory on clock edges, therefore synchronous by the
>> above definition 1:
>>
>> Seems to me you are all arguing, quite acrimoniously, as to whether
>> syncronicity in a digital interface requires a common clock (Maynard)
>> or if the same period will do (Wang et al).
>>
>> Semantics!
>
>
> You're correct in that 'synchronous' has different connotations in
> different contexts.

I didn't say that. I did, however, quote definitions which could be so
interpreted. I deliberately refrained from expressing an opinion,
because the exact point on which you disagree with Wang et al remains
unclear to me.

> When speaking of an electronic bus the electronic context is the proper
> one.

IOW, in your opinion, when the context is memory to chipset
communication, the interface is synchronous if memory and chipset share
a common clock signal, otherwise the interface is asynchronous?

If 'common clock' is the sticking point, let's debate it. Otherwise, I
suppose I'd best butt out and ignore any further 'tittering' and 'chest
thumping'.

Triffid

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

Triffid wrote:

>
>
> David Maynard wrote:
>
>> Triffid wrote:
>>
>>>
>>>
>>> keith wrote:
>>>
>>>> On Mon, 27 Sep 2004 20:27:40 -0500, David Maynard wrote:
>>>>
>>>>
>>>>> George Macdonald wrote:
>>>>>
>>>>>
>>>>>> On Sun, 26 Sep 2004 17:04:27 -0500, David Maynard
>>>>>> <dNOTmayn@ev1.net> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Since your replies have degenerated to gibberish I take it you've
>>>>>>> finally realized that FPM/EDO memory, and the bus it's on, is
>>>>>>> asynchronous.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> What is it that you fail to grasp about being crushed by three
>>>>>> different
>>>>>> people?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> What I 'grasp' are authoritative sources, such as crucial-micron,
>>>>> rather than vapid 'titters' and bombastic chest thumping.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> You are simply beyonf ignorant, and have indeed fallen off the stupid
>>>> cliff. You haven't made sense since you got involved in this thread,
>>>> way
>>>> back when we were discussing the *PCI BRIDGE* characteristics. The
>>>> simple
>>>> *FACT* is that all PC (and all other current systems I know about)
>>>> memory
>>>> *systems* are *SYNCHRONOUS*. Your misunderstanding of what others
>>>> have to
>>>> say doesn't make you any more correct, rather simply more pig-headed;
>>>> swilling in your ignorance.
>>>>
>>>> Would you call a wire asynchronous? It's not clocked. The wire
>>>> from the
>>>> chipset to an SDRAM module is then asynchronous, thus SDRAM is
>>>> asynchrous,
>>>> by Maynardian logic. Thus all computer interfaces (inside and
>>>> outside the
>>>> processor) are asynchronous since they all have wires.
>>>>
>>>> As Mr. Wang, Mr. Macdonald, and I have been trying to beat through your
>>>> thick skull, the chipset launches the address/command on a clock
>>>> edge and
>>>> gathers the result on a clock edge, the system is by definition
>>>> *synchronous*, no matter how may wires are inbetween. SDRAM is no
>>>> different, except that the clocked interface is closer to the
>>>> asynchronous DRAM cell. It's all *synchronous*.
>>>
>>>
>>>
>>> _____________
>>> synchronous
>>>
>>> adj 1: occurring or existing at the same time or having the same
>>> period or phase; "recovery was synchronous with therapy"-
>>> Jour.A.M.A.; "a synchronous set of clocks"; "the synchronous action
>>> of a bird's wings in flight"; "synchronous oscillations" [syn:
>>> synchronal, synchronic] [ant: asynchronous] 2: (digital
>>> communication) pertaining to a transmission technique that requires a
>>> common clock signal (a timing reference) between the communicating
>>> devices in order to coordinate their transmissions [ant: asynchronous]
>>>
>>> Source: WordNet ® 2.0, © 2003 Princeton University
>>> _____________
>>>
>>> SDRAM and the chipset share a common clock, therefore synchronous by
>>> the above definition 2:
>>>
>>> FPM/EDO RAM does not share a clock with the chipset, but the chipset
>>> addresses the memory on clock edges, therefore synchronous by the
>>> above definition 1:
>>>
>>> Seems to me you are all arguing, quite acrimoniously, as to whether
>>> syncronicity in a digital interface requires a common clock (Maynard)
>>> or if the same period will do (Wang et al).
>>>
>>> Semantics!
>>
>>
>>
>> You're correct in that 'synchronous' has different connotations in
>> different contexts.
>
>
> I didn't say that.

No problem. I just meant that's how multiple dictionary entries work:
explaining different meanings and contexts.

> I did, however, quote definitions which could be so
> interpreted. I deliberately refrained from expressing an opinion,
> because the exact point on which you disagree with Wang et al remains
> unclear to me.
>
>> When speaking of an electronic bus the electronic context is the
>> proper one.
>
>
> IOW, in your opinion, when the context is memory to chipset
> communication, the interface is synchronous if memory and chipset share
> a common clock signal, otherwise the interface is asynchronous?
>
> If 'common clock' is the sticking point, let's debate it. Otherwise, I
> suppose I'd best butt out and ignore any further 'tittering' and 'chest
> thumping'.

Hehe. You've got a pretty good handle on it.

>
> Triffid

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

In comp.sys.ibm.pc.hardware.chips Triffid <triffid@nebula.net> wrote:
> David Maynard wrote:

> > You're correct in that 'synchronous' has different connotations in
> > different contexts.

> I didn't say that. I did, however, quote definitions which could be so
> interpreted. I deliberately refrained from expressing an opinion,
> because the exact point on which you disagree with Wang et al remains
> unclear to me.

I don't wish to argue over the semantics of a word, although that's
what we ended up doing. What I started out doing was correcting a
few errors (tRAC), and that led to more errors (burst == synchronized),
and you know how that goes.

I was thinking what I would say if I heard the phrase

"classical asynchronous DRAM bus"

from an old engineer or professor.

I think that given their respective background, and given the proper
context and the ideas they are trying to convey, I would have likely
said nothing.

If I may give an analogy. There's a professor of computer architecture
somewhere that have on his class slides that the Pentium processor is
essentially a RISC processor.

Technically, RISC is a description of the ISA, and Pentium is no more
"RISC" than the 8088.

However, given what he was trying to accomplish in teaching the
microarchitecture of various processors, I understood the context,
and wouldn't nitpick on the sematics of a word.

The problem in this case is that Mr Maynard seems to have latched
onto a word, and taken the word to mean what he think it means,
and utilized incorrect examples to illustrate his understanding of
the issues at hand. (the UART? not correct) IMHO, that's what
got him in trouble with arguing semantics of the word "asynchronous".

If he had illustrated correct understanding of the issues, then
I doubt that anyone would have wrote or said anything regardless of
how he used the word (within reason ofcourse).

> > When speaking of an electronic bus the electronic context is the proper
> > one.

> IOW, in your opinion, when the context is memory to chipset
> communication, the interface is synchronous if memory and chipset share
> a common clock signal, otherwise the interface is asynchronous?

> If 'common clock' is the sticking point, let's debate it. Otherwise, I
> suppose I'd best butt out and ignore any further 'tittering' and 'chest
> thumping'.

I was thinking.. If you send your own reference strobe along with
sending out command and data, and the responding devices send along
their own reference strobe along with sending out the data, but the
controller and device(s) are in differently phase shifted clock
domains, that's still synchronous, I hope.

What if the interfaces were decoupled from the cores? Have different
operating frequencies and not just the phase shifted clock domain...
Is that still "synchronous"? Or is that "Asynchronous" now?

That would be an interesting discussion. 😉

--
davewang202(at)yahoo(dot)com

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

David Wang wrote:

> In comp.sys.ibm.pc.hardware.chips Triffid <triffid@nebula.net> wrote:
>
>>David Maynard wrote:
>
>
>>>You're correct in that 'synchronous' has different connotations in
>>>different contexts.
>
>
>>I didn't say that. I did, however, quote definitions which could be so
>>interpreted. I deliberately refrained from expressing an opinion,
>>because the exact point on which you disagree with Wang et al remains
>>unclear to me.
>
>
> I don't wish to argue over the semantics of a word, although that's
> what we ended up doing. What I started out doing was correcting a
> few errors (tRAC), and that led to more errors (burst == synchronized),
> and you know how that goes.
>
> I was thinking what I would say if I heard the phrase
>
> "classical asynchronous DRAM bus"
>
> from an old engineer or professor.
>
> I think that given their respective background, and given the proper
> context and the ideas they are trying to convey, I would have likely
> said nothing.
>
> If I may give an analogy. There's a professor of computer architecture
> somewhere that have on his class slides that the Pentium processor is
> essentially a RISC processor.
>
> Technically, RISC is a description of the ISA, and Pentium is no more
> "RISC" than the 8088.
>
> However, given what he was trying to accomplish in teaching the
> microarchitecture of various processors, I understood the context,
> and wouldn't nitpick on the sematics of a word.
>
> The problem in this case is that Mr Maynard seems to have latched
> onto a word, and taken the word to mean what he think it means,
> and utilized incorrect examples to illustrate his understanding of
> the issues at hand. (the UART? not correct) IMHO, that's what
> got him in trouble with arguing semantics of the word "asynchronous".
>
> If he had illustrated correct understanding of the issues, then
> I doubt that anyone would have wrote or said anything regardless of
> how he used the word (within reason ofcourse).
>
>
>>>When speaking of an electronic bus the electronic context is the proper
>>>one.
>
>
>>IOW, in your opinion, when the context is memory to chipset
>>communication, the interface is synchronous if memory and chipset share
>>a common clock signal, otherwise the interface is asynchronous?
>
>
>>If 'common clock' is the sticking point, let's debate it. Otherwise, I
>>suppose I'd best butt out and ignore any further 'tittering' and 'chest
>>thumping'.
>
>
> I was thinking.. If you send your own reference strobe along with
> sending out command and data, and the responding devices send along
> their own reference strobe along with sending out the data, but the
> controller and device(s) are in differently phase shifted clock
> domains, that's still synchronous, I hope.

IMHO it is, because the controller and devices share a common timing
reference, albeit not strictly a 'clock'.

> What if the interfaces were decoupled from the cores? Have different
> operating frequencies and not just the phase shifted clock domain...
> Is that still "synchronous"? Or is that "Asynchronous" now?

Sounds asynchronous to me, because it implies the receiver must
independently derive his timing reference from some characteristic of
the data.

> That would be an interesting discussion. 😉

Indeed. Your abstract examples serve to illustrate the subtleties rather
well.

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

In comp.sys.ibm.pc.hardware.chips Triffid <triffid@nebula.net> wrote:
> David Wang wrote:

> > I was thinking.. If you send your own reference strobe along with
> > sending out command and data, and the responding devices send along
> > their own reference strobe along with sending out the data, but the
> > controller and device(s) are in differently phase shifted clock
> > domains, that's still synchronous, I hope.

> IMHO it is, because the controller and devices share a common timing
> reference, albeit not strictly a 'clock'.

> > What if the interfaces were decoupled from the cores? Have different
> > operating frequencies and not just the phase shifted clock domain...
> > Is that still "synchronous"? Or is that "Asynchronous" now?

> Sounds asynchronous to me, because it implies the receiver must
> independently derive his timing reference from some characteristic of
> the data.

I believe I may have just tricked you into agreeing that some
system controllers are asynchronous devices when they have different
operating frequencies on the FSB and the memory system.

We'll have to further narrow that definition down to ". . .different
operating frequencies that do not share a common base frequency..."
(different harmonics of a common base frequency)

BTW, I didn't mean to trick you. I was just reading the reply when
I realized that's what system controllers for Celerons do, and
perhaps related to the title of this thread.

> > That would be an interesting discussion. 😉

> Indeed. Your abstract examples serve to illustrate the subtleties rather
> well.

Very subtle indeed. Tripped myself up for a bit.

--
davewang202(at)yahoo(dot)com

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.chips,alt.comp.hardware.overclocking,alt.comp.hardware,comp.sys.ibm.pc.hardware.systems,alt.comp.periphs.mainboard (More info?)

David Wang wrote:

> In comp.sys.ibm.pc.hardware.chips Triffid <triffid@nebula.net> wrote:
>
>>David Wang wrote:
>
>
>>>I was thinking.. If you send your own reference strobe along with
>>>sending out command and data, and the responding devices send along
>>>their own reference strobe along with sending out the data, but the
>>>controller and device(s) are in differently phase shifted clock
>>>domains, that's still synchronoushronous, I hope.
>
>
>>IMHO it is, because the controller and devices share a common timing
>>reference, albeit not strictly a 'clock'.
>
>
>>>What if the interfaces were decoupled from the cores? Have different
>>>operating frequencies and not just the phase shifted clock domain...
>>>Is that still "synchronoushronous"? Or is that "Asynchronoushronous" now?
>
>
>>Sounds asynchronoushronous to me, because it implies the receiver must
>>independently derive his timing reference from some characteristic of
>>the data.
>
>
> I believe I may have just tricked you into agreeing that some
> system controllers are asynchronoushronous devices when they have different
> operating frequencies on the FSB and the memory system.

I don't feel tricked, because labeling a *device* synchronous or
asynchronous hadn't occurred to me. I had only considered interface
characteristics.

> We'll have to further narrow that definition down to ". . .different
> operating frequencies that do not share a common base frequency..."
> (different harmonics of a common base frequency)

Perhaps it's simpler than that. If my networking background hasn't shown
yet, it will now 🙂

As the recipient of data, how do I determine when to sample it?

If I figure it out for myself, based on a sample of data and/or the
protocol specification, it's an asynchronous interface.

If an external source tells me, it's a synchronous interface.

Terms such as the thread title arise from an idea that variations in the
nature and degree of timing reference coupling can produce interfaces
which are 'semi-synchronous'. I don't buy it, I prefer to keep it simple
;-)

> BTW, I didn't mean to trick you. I was just reading the reply when
> I realized that's what system controllers for Celerons do, and
> perhaps related to the title of this thread.
>
>
>>>That would be an interesting discussion. 😉
>
>
>>Indeed. Your abstract examples serve to illustrate the subtleties rather
>>well.
>
>
> Very subtle indeed. Tripped myself up for a bit.
>