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 David Maynard <dNOTmayn@ev1.net> wrote:
>
>>George Macdonald wrote:
>
>
>>The clock rate is irrelevant to asynchronous memory. It's, ahem, asynchronous.
>
>
>>To illustrate the point, how did you come up with 40ns in order to "respond
>>to a 100MHz FSB pass-through rate" that's a 10ns clock period? You see,
>>*synchronous* memory would need a 10ns access rate to keep up. Asynchronous
>>can be anything because it's, ahem, asynchronous.
>
>
> Nothing is truly "asynchronous" in this context. The DRAM is considered
> "asynchronous" because it did not explicitly move from one state to
> another state in response to s clock input, rather, it changed states
> relative to the timing of some control signals, but those control
> signals were generated by a DRAM controller, which is itself
> "synchronous" and operated on a base clock frequency.
The confusion comes from it being 'converted', if you will, from
asynchronous, at the RAM, to synchronous by the chipset.
> "Asynchronous" PB EDO could have a 10ns "cycle rate" in the sense that
> it could burst out the data at the 10ns (100MHz) rate, if you so pushed
> the margins and picked the right parts, but I agree, it would have been
> tough.
>
>
>>And 60ns memory doesn't 'respond to' a 66MHz bus "pass-through rate"
>>either. The effective data rate for 60ns memory would be, at best (ignoring
>>all other delays), 16.7 Mhz. That's why PC66 SDRAM was 'better'.
>
>
> "60ns" memory is 60ns tRAC**, and that has nothing to do with the effective
> datarate,
Yes, I misspoke.
> since the DRAM manufacturers were actually pipelining and
> spitting out data on xEDO parts just as they were on SDRAM parts.
Yes, except that FPM/EDO is simply holding the Row Address so the chipset
'can' do subsequent reads without that delay, if the data is in that range.
The chipset 'can', then, do multiple reads, setting the column address, as
in a 'stream' but it is not required to (by the RAM) nor are the column
addresses required to be in any particular order (beyond the dictates of
practicality). Of course, doing a stream 'makes sense' but the async RAM
doesn't care; it's a function of the chipset design.
With SDRAM, however, the stream (burst mode) is inherent to the RAM itself,
not just good sense, with each subsequent data set in the stream implicit
and internally incremented (synchronous with the clock) by the SDRAM.
The more significant difference, in the context of async vs sync, is that
SDRAM does not look to the edges of multiple 'strobe' signals for timing.
All timing comes from the clock edges. e.g. addresses are not latched, I.E.
'clocked', by CAS and RAS, as with async RAM, they're latched on clock
edges. All timing comes directly from the clock (which does not even exist
on the async RAM bus) and therein lies the 'synchronous' nature of it.
Now, one might argue that all those 'async' strobe signals generated by the
chipset are traceable to the chipset clock and so, in some manner,
'synchronous' with it but that's talking about the nature of the chipset;
not the async RAM. I.E. the async RAM doesn't care if the strobes come from
a 'clocked' chipset or a bank of one-shots, as long as they meet the setup
and hold times, but you aren't going to get squat out of SDRAM without the
clock that all it's internal timing is derived in synchrony with.
>>>Of course that was not the "asynchronous" being discussed here anyway..
>>>which was to do with the FSB😛CI ratio. I guess I fell into the trap the
>>>previous poster set for himself.
>
>
>>The term asynchronous doesn't depend on 'which clocks' or 'which bus' nor
>>is there 'the one here'. Asynchronous is asynchronous.
>
>
> Asynchronous is asynchronous, except when it's not really asynchrnous.
> Even when it's "synchronous", it's not really "synchronous". What does
> "clock" mean when the strobe signals arrive the device interfaces at
> different times? It's all relative... To something... Usually an
> explicit clock or strobe, but could be implicitly relative to the clock.
I'll add that to my list of Zen quotes 😉
>
> ** tRAC is Randomc access latency. Which is basically tRCD + tCAS.
> Micron's data sheet on obsolete FPM and EDO parts are still available
> online at www.micron.com.
>
David Wang wrote:
> In comp.sys.ibm.pc.hardware.chips David Maynard <dNOTmayn@ev1.net> wrote:
>
>>George Macdonald wrote:
>
>
>>The clock rate is irrelevant to asynchronous memory. It's, ahem, asynchronous.
>
>
>>To illustrate the point, how did you come up with 40ns in order to "respond
>>to a 100MHz FSB pass-through rate" that's a 10ns clock period? You see,
>>*synchronous* memory would need a 10ns access rate to keep up. Asynchronous
>>can be anything because it's, ahem, asynchronous.
>
>
> Nothing is truly "asynchronous" in this context. The DRAM is considered
> "asynchronous" because it did not explicitly move from one state to
> another state in response to s clock input, rather, it changed states
> relative to the timing of some control signals, but those control
> signals were generated by a DRAM controller, which is itself
> "synchronous" and operated on a base clock frequency.
The confusion comes from it being 'converted', if you will, from
asynchronous, at the RAM, to synchronous by the chipset.
> "Asynchronous" PB EDO could have a 10ns "cycle rate" in the sense that
> it could burst out the data at the 10ns (100MHz) rate, if you so pushed
> the margins and picked the right parts, but I agree, it would have been
> tough.
>
>
>>And 60ns memory doesn't 'respond to' a 66MHz bus "pass-through rate"
>>either. The effective data rate for 60ns memory would be, at best (ignoring
>>all other delays), 16.7 Mhz. That's why PC66 SDRAM was 'better'.
>
>
> "60ns" memory is 60ns tRAC**, and that has nothing to do with the effective
> datarate,
Yes, I misspoke.
> since the DRAM manufacturers were actually pipelining and
> spitting out data on xEDO parts just as they were on SDRAM parts.
Yes, except that FPM/EDO is simply holding the Row Address so the chipset
'can' do subsequent reads without that delay, if the data is in that range.
The chipset 'can', then, do multiple reads, setting the column address, as
in a 'stream' but it is not required to (by the RAM) nor are the column
addresses required to be in any particular order (beyond the dictates of
practicality). Of course, doing a stream 'makes sense' but the async RAM
doesn't care; it's a function of the chipset design.
With SDRAM, however, the stream (burst mode) is inherent to the RAM itself,
not just good sense, with each subsequent data set in the stream implicit
and internally incremented (synchronous with the clock) by the SDRAM.
The more significant difference, in the context of async vs sync, is that
SDRAM does not look to the edges of multiple 'strobe' signals for timing.
All timing comes from the clock edges. e.g. addresses are not latched, I.E.
'clocked', by CAS and RAS, as with async RAM, they're latched on clock
edges. All timing comes directly from the clock (which does not even exist
on the async RAM bus) and therein lies the 'synchronous' nature of it.
Now, one might argue that all those 'async' strobe signals generated by the
chipset are traceable to the chipset clock and so, in some manner,
'synchronous' with it but that's talking about the nature of the chipset;
not the async RAM. I.E. the async RAM doesn't care if the strobes come from
a 'clocked' chipset or a bank of one-shots, as long as they meet the setup
and hold times, but you aren't going to get squat out of SDRAM without the
clock that all it's internal timing is derived in synchrony with.
>>>Of course that was not the "asynchronous" being discussed here anyway..
>>>which was to do with the FSB😛CI ratio. I guess I fell into the trap the
>>>previous poster set for himself.
>
>
>>The term asynchronous doesn't depend on 'which clocks' or 'which bus' nor
>>is there 'the one here'. Asynchronous is asynchronous.
>
>
> Asynchronous is asynchronous, except when it's not really asynchrnous.
> Even when it's "synchronous", it's not really "synchronous". What does
> "clock" mean when the strobe signals arrive the device interfaces at
> different times? It's all relative... To something... Usually an
> explicit clock or strobe, but could be implicitly relative to the clock.
I'll add that to my list of Zen quotes 😉
>
> ** tRAC is Randomc access latency. Which is basically tRCD + tCAS.
> Micron's data sheet on obsolete FPM and EDO parts are still available
> online at www.micron.com.
>
Facebook
Twitter
Instagram