More Nv-30 speculation !!

[Fred]

'The definition for Barns is the probability of an interaction at the atomic level. '

MMMMM, To be picky, thats not *quite* the case albeit very close. But, it would be nitpicking to give the actual formal defintion for crossections. (Actually the history of the unit itself is kinda interesting and amusing, but thats OT)

Which is pretty much the point of the the thread.

Everyone knows what we're talking about. The fact that in this context hz and data/pin/sec matches in a completely linear (with proportianlity constant 1 -2 depending on how we phrase things) way, is merely a matter of convention.

As a scientist, I would naturally be inclined to use the data/pin/sec value (although again, thats not quite the case, b/c 'data' here is a little bit nebulous)

In the physical/statistical scale that we are talking about, its linear. Obviously at different scales of interest, it might be different (and in fact completely nonlinear).

 

[demalion]

Broadside of a barn is the term that comes to mind when I think back to my introduction to the unit. The point of the example was to illustrate the fallacy of equating the standard units expression with being equivalent with the concept behind the unit, or else we'd go around measuring any really small area with barns. I'd be interested in a definition you have in mind that isn't what I stated with "expressed as a cross sectional area" tacked on...perhaps it will stick with me.

 

[arjan de lumens]

The discussion started about whether DDR should be referred to by its clock rate, or its effective clock rate compared to "SDR".

Whatever has been made popular, and I think due to marketing, I would say:

1) I'm under the impression that it actually isn't exactly twice the data rate.

A DDR SDRAM tends to spend relatively more time doing nothing (due to page-breaks, bus turnaround, etc) than an SDR SDRAM, resulting in lower protocol efficiency. When it does transfer data, it does so at exactly twice the data rate.

2) We have all sorts of things we can put before "per second", like bits, bytes, and other things that are actually meaningful and useful.

OK, then I will suggest Million Transfers Per Second => MTps. Now, the next step is to get people (including myself) to actually use this new unit

Therefore, your use of this reasoning as a justification for the use of "Hz" as a unit for this does not make sense because:

What is this "cycle" you refer to in regards to this? You're either ignoring the use of the word "cycle" in your definition as if it is not there, or failing to provide a clear link to the term "cycle" and the way in which DDR achieves its data transfer. I say again, isn't DDR specifically because it can achieve data transfer twice per clock cycle? If so, doesn't it make sense that the proper unit of measurement including a unit of data in it? The amount of data transferred does not change the clock cycle, and that is what the Hz in the specific case of memory makes sense for.

The idea was: 1 data transfer = 1 cycle. Quite possibly overstretching the definition of a 'cycle' though.

Again, if you have examples counter to this, please provide, but what it looks like to me is you're working backwards from the fact that people (when I say that, I really think "marketing") have used "Hz" to refer to this, and attempting to justify it, and therefore the logical support so far (to me) looks bass ackwards.

Examples beyond what originates in marketing? Not really aware of any

Note that the vigorous attack of your position is just my own personal values in action and not related to my personal opinion of you, a disclaimer that might be important with some of the atmosphere that has been present here in the past few months.

Point taken. No offense taken or intended.

 

[demalion]

Heh, I'm not arguing over what will get used, but what more properly "should" be used, and why I think so. I have no illusions about my ability to sway marketing departments in the name of "correct usage".

The way you make DDR operation sound, it sounds like it should be measured in "becquerels", but I don't see me selling the industry on that.

Perhaps QBM and future standards will cause the "Hz" to be dropped moving forward. This would be more likely if competing "Quad" technologies or improved "Double" technologies are introduced, but we'll just have to see I guess.

 

[arjan de lumens]

The way you make DDR operation sound, it sounds like it should be measured in "becquerels", but I don't see me selling the industry on that.

Hmmm ... ATI? "Radeon" always did sound like some sort of radioactive element. Given that the Radeon9700 has 4 buses, each 64 bits wide, running at 620 MTps, were looking at nearly 2500 Mega-becquerels here. That's one hell of a "Radeonactive" card (geez, that pun was stoopid).

 

[nAo]

If it's the same, has it really changed?
If it has changed, how come it's still the same?

Cause we're speaking of two different things.
Meanwhile the logic level on the pin hasn't changed the data
the memory put on the pin HAS changed cause is taken from a different memory cell. It's quite simple, the data rate (the rate/frequency on which different memory cells are output on the bus) is well represented by that MHz figure many dislikes.

Anyway, if we start to use the real definitions as such "bla bla / second" then one could equally much argue we should count the bus width too.

No, we're dealing with memories data rates per pin.

If it's changing on 128 places, why count that as one? It'll still be 1 / s.
In computer hardware Hz has always referred to the clock, I can't see why DDR memory should be treated differently, except that it looks better on marketing slides.

Instead I see why it is treated as a different thing cause in fact data changes on the pin every half clock, where the clock is the interface clock.
Or is it the clock of the memory cell?? Oops..then DDRII are clocked at half the interface clock. Would u like to quote a 250 MHz memory for it?

ciao,
Marco

 

[Basic]

demalion:
Wouldn't you agree that a CD is recorded with a sampling frequency of 44.1kHz?

That means 44100 'events' happening each second at a regular pace. There is no waveform repeated 44100 times per second. And it does not refer to a physical clock running at 44.1kHz driving the sampling unit. It refers to the sampling 'event'.

This is very much like the case with DDR, the only difference being that the data you sample is sent in sync with your sampling, not completely decoupled as in the audio sampling case.

The only place where I remember seeing time domain sampling rates given by a different unit than Hz is with oscilloscopes, where you often can se the unit S/s - samples per second.

But I can agree that it would be nice to have a unit that would work even with multilevel signaling (like the interface Rambus was working on earlier which used 4-level signaling, transfering 2 bits per symbol). The unit bit per second and pin would do the job.

But then we have another possible oddness. An engineer (that isn't a programmer) would write it bit/s*pin, while a programming influenced person would write it bit/s/pin. (Or maybe even bit/sec/pin.)

 

[Humus]

Cause we're speaking of two different things.
Meanwhile the logic level on the pin hasn't changed the data
the memory put on the pin HAS changed cause is taken from a different memory cell. It's quite simple, the data rate (the rate/frequency on which different memory cells are output on the bus) is well represented by that MHz figure many dislikes.

So what if a pointer internally in the memory chip has changed, it's completely transparent to the device it's interfacing and competely irrelevant. A P4 running at 2GHz, would you call it 4GHz due to the dualpumped ALU? Or should we start to count every time a latch toggles internally?

 

[RussSchultz]

Ah, but the clock that drives the Pentium4 is only 133Mhz. (or 166 now.) Should we refer to it as a 133Mhz device?

 

[demalion]

demalion:
Wouldn't you agree that a CD is recorded with a sampling frequency of 44.1kHz?

Yep. That is the digital sample clock.

That means 44100 'events' happening each second at a regular pace. There is no waveform repeated 44100 times per second. And it does not refer to a physical clock running at 44.1kHz driving the sampling unit.

Thre isn't? It doesn't? Actually, it does seem to reference the clock rate the sampling is driven by.

It refers to the sampling 'event'.

The sampling event is driven by a clock, and this clock is what is being referred to for "sampling" (A/D or D/A conversion). The reference to this clock is carried out throughout the use of the terminology, e.g. "sampled at".

Let's, for example, discuss this table and the use it makes of Hz for sound. To me it seems to make a clear and proper distinction to the use of Hz, and the "Hz" is always in reference to a cycle (though not necessarily the same cycle each time). The image of a flip flop being driven at the sample frequency at the end of the circuit comes to mind.

This is very much like the case with DDR, the only difference being that the data you sample is sent in sync with your sampling, not completely decoupled as in the audio sampling case.

What are you talking about "completely decoupled"? Perhaps that phrase is the gap in understanding I have for where you are coming from, because that phrase doesn't strike me as accurate.

It is possible, for example, to have a 300 MHz clocked unit reading from a 150 MHz clocked DDR unit. The 300 MHz clocked unit is running at 300 MHz. The DDR is running at 150 MHz, and data is being sampled at 300 MHz (the clock cycle of the 300 MHz unit). To me, this description has the Hertz labels in the right places, and is different than saying the DDR is running at 300 MHz.

The only place where I remember seeing time domain sampling rates given by a different unit than Hz is with oscilloscopes, where you often can se the unit S/s - samples per second.

That's because the signal you are sampling might have a specific Hertz value and it wouldn't necessarily map to the samples per second....you'd need a sufficient multiple of the Hz as the sampling frequency to determine the Hz (the cycle distinction is pretty clear there too).

I mention this because you didn't, not because I assume you wouldn't know.

You could refer to the clock driving the sampling in Hertz, though.

But I can agree that it would be nice to have a unit that would work even with multilevel signaling (like the interface Rambus was working on earlier which used 4-level signaling, transfering 2 bits per symbol). The unit bit per second and pin would do the job.

But then we have another possible oddness. An engineer (that isn't a programmer) would write it bit/s*pin, while a programming influenced person would write it bit/s/pin. (Or maybe even bit/sec/pin.)

Or you could call it transfers per second, tps or xps or some such much shorter label. I hope I'm getting across the distinction I see here.

 

[demalion]

Ah, but the clock that drives the Pentium4 is only 133Mhz. (or 166 now.) Should we refer to it as a 133Mhz device?

More than one clock rate can be associated with a device.

Or, are you saying that the clock rate you quote here is the only one there is on the chip? If you are, please enlighten me further...if not, why did you arbitrarily pick this one?

 

[nAo]

Blah..I hate when someone can't admit he/she's wrong and he/she start to nitpick...IMHO the points made by me and other were pretty clear and there isn't much to dicuss anymore. See you on a more interesting topic..

ciao,
Marco

 

[RussSchultz]

Ah, but the clock that drives the Pentium4 is only 133Mhz. (or 166 now.) Should we refer to it as a 133Mhz device?

More than one clock rate can be associated with a device.

Or, are you saying that the clock rate you quote here is the only one there is on the chip? If you are, please enlighten me further...if not, why did you arbitrarily pick this one?

I didn't arbitrarily pick this one.

Nobody calls the pentiums or athlons by their FSB frequency because they don't run at that frequency. Their internal clock is derived from the FSB clock, which is the same clock which the ddr devices derive their 2x clocks from to provide valid data at the rising and falling edge of the clock.

The only problem with using the 2x rate for referring to memory is that you don't necessarily know if its the 1x or 2x rate.

But anyways, as Marco says, on to other topics...

 

[demalion]

Ah, but the clock that drives the Pentium4 is only 133Mhz. (or 166 now.) Should we refer to it as a 133Mhz device?

More than one clock rate can be associated with a device.

Or, are you saying that the clock rate you quote here is the only one there is on the chip? If you are, please enlighten me further...if not, why did you arbitrarily pick this one?

I didn't arbitrarily pick this one.

Nobody calls the pentiums or athlons by their FSB frequency because they don't run at that frequency.

It seems my example fits in here, but you didn't address it.

Their internal clock is derived from the FSB clock, which is the same clock which the ddr devices derive their 2x clocks from to provide valid data at the rising and falling edge of the clock.

Hmm, so there is an internal clock that is a multiple (2) of the interface clock for DDR, and this value does not vary between, for example, DDRII, DDRIII(?) and GDDR3, and directly maps to the way QBM would work, for example?

My current impression is that the relationship of internal clocks to interface clocks is not that simple for the memory standards, and that the methods for data transfer for these standards are not restricted to such a "internal" clock signal relationship, but if you can illustrate that it is I will have to agree that there is a valid "Hertz" rating that is applicable to the frequency of that clock.

Prompted by your comments, I've located some documents on DDR and DDR-II operation. The way I read them, they lend support to my conclusions and even labelling distinctions (to my surprise). Perhaps you can use them to illustrate something I am misunderstanding to further illustrate your point, or provide an alternate explanation that clearly illustrates what you are saying.

Here is one pdf

Here is another pdf

Here is a last pdf

These are actually the ones I looked at, I did not pick and choose among a larger set and only present those that supported my viewpoint. I actually would have expected these to be marketing speak that referenced using "MHz" for the data rate, and perhaps you will be able find such to illustrate your comments.

The only problem with using the 2x rate for referring to memory is that you don't necessarily know if its the 1x or 2x rate.

Hmm...you have not clarified how this is distinct from my example usage concerning DDR in my post, and the associated comments I've made there.

But anyways, as Marco says, on to other topics...

Hmm...I'll try not to be paranoid about your ellipsis usage and insinuations.

EDIT: fixed link and quoting

 

[Basic]

Sampling frequency, with the unit Hz is used even in theoretical situations where you don't even have a hardware doing any sampling. It does relate to the number of samples per second, and you don't care if someone would implement it later with some hardware that takes one sample on each edge of a clock, or every N clocks. It's still the sample rate.

You linked to one interesting situation. There's loads of different resamplings mentioned there. From what I read there it sounded like it was about some software. This means that they had some sample frequency to begin with (and there could have been a clock related to the sampling). Then they do a resampling to some different sampling frequency - suprise - you don't have a clock at the target frequency. It's just software doing the conversion. The resampling might be done just to save space, and it could be resampled again when it is replayed.

So you could have the situation 44.1kHz => 9.6kHz => 44.1kHz. You still say that the intermediate data has a sampling frequency of 9.6kHz even if there never ever were any clock that had that frequency. It's called 9.6kHz because the samples belongs to events happening at a rate of 9.6 kHz.

If you say that you'd think of it as 9.6kHz because the samples could have been recored/played at 9.6kHz, then so what. It's just the same as saying that a DDR1000 interface could have a 1000MHz clock to sample the data.


"completely decoupled"

No biggie, and not likely the source of misunderstanding.
I just pointed out that while the datarate on a DDR bus (and most other buses), are strictly locked to the sampling clock (be it a multiple or fraction of it). There's no such thing when you sample an audio stream. You don't tell a singer to generate samples that fits the A/D-converters sampling times.


"...saying the DDR is running at 300 MHz. "

Just so you don't argue with me for the wrong reason, I agree that that's not a good way to say it. My point is that it's not technicaly wrong to say that it's running at 300MHz datarate. Notice explicit reference to datarate.
When there is a clock in the system and you mention a MHz-number, then yes, it's most likely that you intuitively connect those two. That doesn't mean that it's wrong to use a MHz-number for something else as long as you make clear what it refers to.


Oscilloscopes:

Or another way to say what you said. When using an oscilloscope, you generally want to detect frequencies a lot higher than you think.

"You could refer to the clock driving the sampling in Hertz, though. "

I have a "toy oscilloscope" here right next to me, it has a 1GS/s sampling rate. (True, not multisampling.) But I have serious doubt that there is a 1GHz clock in there somewhere. My guess is that it were cheaper to make a few slower units and run them with a phase difference.


And I wouldn't complain if people started to use the term transfers per second. Still, would it be the best term if interfaces like the one I mentioned appears?

 

[demalion]

Sampling frequency, with the unit Hz is used even in theoretical situations where you don't even have a hardware doing any sampling.

It would be helpful to mentions those cases to clarify this to me. In my mind currently, these cases would be related to cycles clocks, as the examples that come to mind from my experience with sampling circuits are, and I'd appreciate counter-example(s) for this.

It does relate to the number of samples per second, and you don't care if someone would implement it later with some hardware that takes one sample on each edge of a clock, or every N clocks. It's still the sample rate.

Is the Hertz in this discussion related to the sample data resulting, or the process of sampling? In other words, if you have data sampled at 44.1kHz, is it 44.1kHz data, or data that was sampled at a rate of 44.1kHz? Obviously, the way I phrased it in the first place illustrates the way I see it...again, I point out that it seems to me the distinction between these two phrasings is related to the concept of a "cycle". If you have a counter example, please provide.

You linked to one interesting situation. There's loads of different resamplings mentioned there. From what I read there it sounded like it was about some software. This means that they had some sample frequency to begin with (and there could have been a clock related to the sampling). Then they do a resampling to some different sampling frequency - suprise - you don't have a clock at the target frequency.

Actually, you do, the cycle is the D/A conversion step for that sample, and the clock is the rate of that conversion. Sound playback hardware can vary this clock as the software requests.

It's just software doing the conversion. The resampling might be done just to save space, and it could be resampled again when it is replayed.

I think it is telling that they use bitrate notation for the outputs of these resamplings, and that the playback clock is mentioned distinctly.

So you could have the situation 44.1kHz => 9.6kHz => 44.1kHz. You still say that the intermediate data has a sampling frequency of 9.6kHz even if there never ever were any clock that had that frequency.

A CPU, and a DSP for that matter, is a programmable processor, being able to simulate clock rate by dropping/substituting samples is part of its function, and represents a programmable way of doing what a circuit designed to lower clock rate would do. See my prior post for how I would refer to the DDR situation differently than this and why.

It's called 9.6kHz because the samples belongs to events happening at a rate of 9.6 kHz.

Hmm...it looks to me as if in all cases you mention, samples are defined and derived from, and refer to, clock rates. Here is where I see your analogy make a slip: you say the number goes from 44.1kHz -> 9.6kHz, and you ignore that there is unique, clocked, cycle occuring at 9.6kHz for that to happen. By ignoring that cycle at 9.6kHz, you are presenting at as proof that the cycle concept is unimportant.

If you say that you'd think of it as 9.6kHz because the samples could have been recored/played at 9.6kHz, then so what. It's just the same as saying that a DDR1000 interface could have a 1000MHz clock to sample the data.

Perhaps this is the cause of my misunderstanding then?

As I'm seeing things, a"sample" is a time discrete function, i.e., the concept of an audio sample is spaced in the time domain. This is not equivalent to DDR "samples", or you would end up just as validly multiplying the MHz by the number of pins.

The 9.6kHz sample does have a 9.6kHz time domain clock in order to generate the signal sampled at 9.6kHz.

The "1000 MHz" DDR does not...it was not sampled at 1000 MHz, it was sampled at 500 MHz (again, unless you'd feel free to multiply by the number of pins as well) and transferred data 1000 times per second.

Russ still hast the opportunity to show it is "sampled" at "1000 MHz", and this is meaningful throughout "x datarate" ram standards, but the pdfs I've found so far seem to indicate that this terminology is not proper.

"completely decoupled"

No biggie, and not likely the source of misunderstanding.
I just pointed out that while the datarate on a DDR bus (and most other buses), are strictly locked to the sampling clock (be it a multiple or fraction of it). There's no such thing when you sample an audio stream. You don't tell a singer to generate samples that fits the A/D-converters sampling times.

? Again, you lose me. There is such a thing when you sample audio streams. The sampling rate is driven by a clock, and it is not decoupled from it at all.

Re datarate: I'm simply saying there are already units for "datarate", and MHz used in this context seems improper (to me) for the above reasons.

"You could refer to the clock driving the sampling in Hertz, though. "

I have a "toy oscilloscope" here right next to me, it has a 1GS/s sampling rate. (True, not multisampling.) But I have serious doubt that there is a 1GHz clock in there somewhere. My guess is that it were cheaper to make a few slower units and run them with a phase difference.

Actually, I was referring to an input signal to the Oscilliscope, not an "internal clock". Heh, wait, are you trying to prove my point?

And I wouldn't complain if people started to use the term transfers per second. Still, would it be the best term if interfaces like the one I mentioned appears?

Take a look at the pdf links...to my surprise, it already seems they are using such terms. It appears that the MHz usage for DDR, et al, that we are discussing is unique to marketing right now. Maybe marketing will get tired of it as more varieties in RAM technologies causes even convenient multiplication to be disadvantageous.

 

[Basic]

Again, you lose me.

Sorry for the rudenes, but it seem rather easy to loose you. I don't know whether it's intentional or not from your side, but there's no use to keep this on.

 

[Nagorak]

Again, you lose me.

Sorry for the rudenes, but it seem rather easy to loose you. I don't know whether it's intentional or not from your side, but there's no use to keep this on.

Ouch.

 

[Humus]

Blah..I hate when someone can't admit he/she's wrong and he/she start to nitpick...IMHO the points made by me and other were pretty clear and there isn't much to dicuss anymore. See you on a more interesting topic..

ciao,
Marco

I agree that the definition of Hz etc is a quite uninteresting topic for spending multiple pages on and isn't especially important as long as we all know what we're talking about. How "clear" your and others points have been is another question though.

 

[demalion]

Again, you lose me.

Sorry for the rudenes, but it seem rather easy to loose you. I don't know whether it's intentional or not from your side, but there's no use to keep this on.

Wow Basic, I wouldn't have expected that from you. To quote where "you lose me"again...you said:

"completely decoupled"

No biggie, and not likely the source of misunderstanding.
I just pointed out that while the datarate on a DDR bus (and most other buses), are strictly locked to the sampling clock (be it a multiple or fraction of it). There's no such thing when you sample an audio stream. You don't tell a singer to generate samples that fits the A/D-converters sampling times.

Ok, that flat out doesn't make sense to me. In fact, it appears to be totally incorrect. "You lose me" is a phrase indicating an opportunity for you try again with other phrasing, or further clarify existing phrasing, to get your point across.

Let me be more precise in my quoting "I just pointed out that while the datarate on a DDR bus (and most other buses), are strictly locked to the sampling clock (be it a multiple or fraction of it). There's no such thing when you sample an audio stream." That statement makes absolutely no sense to me, and in fact it is directly contrary to the sampling circuits I'm familiar with.

Further, "There's no such thing when you sample an audio stream. You don't tell a singer to generate samples that fits the A/D-converters sampling times" is a statement that appears to be completely nonsensical in any context of the discussion, since quite simply the sampling rate being locked to a clock has absolutely and totally nothing to do with the misconceptions present in it.

If "You lose me here" is cause to take a (cheap) dig at me, would "You seem to be flat out wrong" have been better? I'm open to the possibility that the sampling circuits (in which sampling is directly tied to the clock of the circuit) I'm directly familiar with are not what you have in mind, I'm not open to that type of cheap dig as a subsitute for an example of such.