Hi Gene Parrott; Your system specs are realistic, as far as I can tell, but the conclusion that there is a problem is wrong.
Re: " If that's all there was to analyze you've got some real system problems. For example, assume consecutive reads of last chip, first chip. (N32, N1). Using the above assumptions, looks to me like N32 will appear in reverse order long after N1. <g> The solutions to this problem are probably very interesting and probably need to be known for a thorough analysis of RSL signaling."
If you'll go back and reread my post with the timing diagrams, you will find that I noted that reads from N1 have to be delayed. Since you put a 2.5ns delay between the two ends of the RDRAM sequence, you will have to delay N1 reads by 2.5ns, the delay for my example was 0.7ns. (The number which is programmed into the chips is a bit more complicated because in addition to having N1 send data to the controller with less delay, it is also true that N1 gets its commands from the controller 2.5ns before N32. So the actual amount you have to delay N1's reads by, relative to the reception of the READ command, is by 5.0ns)
In any case, my diagram took the 0.7ns delay into account.
Re: "At any rate, we know the solutions were found and that there can be consecutive data at 800mHz."
Please show this with a link. It's not that I doubt your memory, because, in fact, I remember the same thing. It's just that I cannot find a recent link from Rambus stating that you can switch a read between any two RDRAM chips without a gap in the data presented to the controller. I am beginning to suspect that this particular feature of the RSL bus was eliminated in order to avoid the 3rd step problem. By the way, I love the phrase "solutions were found", it's the typical sort of BS you get from managers and politicians who don't have a clue what is actually going on. Sort of the opposite of the phrase "errors were made", but it still carries the passive sense of lack of control.
It's probably very easy for you to believe that since these things are not obvious to you, they cannot be obvious to anyone else. You should sit in my shoes for a few months. Most of my job is designing and simulating pipelined logic. This is what I do for a living, it is a natural way of thinking for me. All the RSL bus is, as Rambus themselves have said, is a pipelined data bus. These things are simple to me, just like insurance forms are simple to richard surckla. This is my territory.
Re: "So what we have is consecutive 1.25ns wide data at 1.25ns cycles flowing on the bus and into the controller without overlap."
When you're looking at a pipelined system, the first thing you have to get out of your head is the usual human concept of "time". With a pipelined system, distance is a form of time. The conversion between time and distance is, of course, the propagation rate of the transmission line (or the clock rate of pipelined logic). Let me try and explain this, because if you truly appreciate this, you will have a new and more effective way of looking at these things.
The basic idea of a transmission line is that what goes in one end comes out the other unaltered. In fact, what goes in one end goes past each point on the line looking the same way. But it's not the same signal, because what shows up later down the line is a delayed copy of what showed up earlier. The natural way of thinking about these things is to think of the distance on the bus as being a form of time. Let me give an example.
Suppose a write command is sent from the controller. It shows up at N1 2.5ns before it shows up at N32. But the waveform is the same. To remember that the waveform at N1 and the waveform at N32 are different (one is delayed), is too complicated for people, so they think of the two RDRAM chips as getting the same waveform. But they don't, one gets a delayed copy.
The concept of "overlap" is one of the unfortunate ones that involves "time", and consequently is difficult for humans to understand in pipelined systems. On an RSL bus, before you talk about "overlapping", you have to define what point on the bus you are talking about. Read bits do not overlap at the controller. At the driver, a bit overlaps with the reflection of the previous bits. That is an overlap of two bits, the transmitted on and the reflected one. The result is two steps, which we all agree on.
My point is that if the read source is switched from one RDRAM to another in such a way as to assure a continuous transmission of data bits with no overlap and no gaps at the controller, and if the second source (the one being switched to) is farther from the controller than the first source, then it is the case that three bits overlap at the output of that controller, and this leads to the third step. You already lost your virginity on the overlap issue when you realized that there are two steps, stretching yourself to accommodate three shouldn't be that difficult.
Re: "So the question is, if there is no overlap of data flowing on the bus, how can there be overlap at the data source on the bus?" As explained above, this question assumes a false condition. Of course there is overlap on the bus. Bits are travelling in both directions due to the reflection. That's an overlap.
I think that I am slowly explaining this. The basic problem is that you've been thinking "linearly", i.e. in only one dimension, time. The normal condition for a wire is that it has a voltage. As time goes by, the voltage goes up and down, and this is how you are looking at the problem. Words are great for describing linear situations, but they are very hard to use to describe more complicated situations.
You need to look at the whole bus at all times. The picture of a waveform in your mind is accurate for only a single position on the bus. Every other position will have a different waveform. You need to keep track of which bits are travelling on which parts of the bus, in which directions, and what they do when they reach the end (i.e reflect or be absorbed). This is complicated, because the problem no longer fits in a single dimension, but I'll bet you're having fun.
-- Carl |
