Hi again, KZNerd; Re Rambus channel interface being designed by RMBS. I think you're right, but I don't know enough about the details. I suppose I could go look up the standard cell RDRAM interface specifications...
But even then, RMBS can avoid the blame. The real problem that schemes that try to balance delays have (and the Rambus channel is the king of all propagation delay cancellation schemes), is that they rely on assumptions about the relative properties of different transistors on the same chip.
This is a subtle point, so I should clarify it. The three typical factors that alter propagation delays in chips is the power supply, the temperature, and the process. Sometimes the edge rate of the incoming signal, too, but lets ignore that.
For a given piece of silicon, the temperature is very similar all over the chip. The power voltage is also very similar, assuming that the process guys didn't really make a big mistake. And of course the process is very close to the same all over the chip. (Process is, in fact, pretty similar all over a whole wafer.) Because of this, it has been traditional in chip design, to run simulations that assume all the various parts are running at the same "speed." This is a great simplification from what must be done in board design.
In board design, the parts are not at the same temperature, may not even have the same nominal supply voltages, and are definitely not from the same process. Because of this, worst case design of boards has always been a much more rigorous thing than design of chips.
In a board design, you basically have to prove that the design works regardless of what sort of chips are used, (assuming that they meet their "bin" requirements). This makes race conditions a lot more likely than on a single chip. Engineers use a variety of techniques to simplify this process, the basic idea is that you have to prove that each flip-flop in the design has data applied to it that always meets the setup and hold requirements of that particular flip-flop. (Or, if this is impossible to achieve, (as it always is with certain flip-flops,) that the resulting metastable states of the flip-flop are sufficiently rare as to not cause a bug over some natural time scale.)
This difference between board and chip design isn't mentioned much in the industry, at least it wasn't the last time I designed a chip, which admittedly has been a while. (I've been doing field programmable gate arrays exclusively for nearly three years.) If you guys have any links to more modern chip design techniques, I'd love to read them.
Anyway, it is very simple to design a chip that will work perfectly in all the simulations provided by the chip house, both before and after routing, but will fail 100% at test. (That is, no dice will show themselves as good. Doing this would really p:$$ off the foundry, as they traditionally have to eat bad dice.) Any designer who wants to sabotage a chip design can put these kinds of circuits in. What you do is to put in a circuit that produces a result depending on a long race condition, but with the race through large numbers of parts, and make those parts as different as you can. For instance, make one leg of the race be a bunch of 3-input NAND gates, and make the other be transmission gates. Suppose you set it so that the NAND gate track always wins. Now add just enough more NAND gates to make the other track always win. By doing this, you have two races set up, with a different winner in each. Now base some logic on the outcomes of those two races. Set it up so that if the NAND gates win both races, or the transmission gates win both races, then your part does something different (on the pins) than if the races are split (as the simulation expects). This may not be particularly easy to do, you may have to tweak it a while before you get the timing simulator to say that the races always get split, whether the part is running slow, medium or fast. It is important that you get the simulation to give the same result in all three speeds, because the test vectors will be tested at all three of them.
When they put the part out to fab, the prop delays through the transmission gates will inevitably fail to exactly scale with the prop delays through the NAND gates, (in the way predicted by the simulator) and the resulting parts will fail their test vectors. Voila! P:$$ed off foundry!
This failing to scale is because of the gross simplification that is involved in going from all the possible parameters on a chip to just one, speed, and only three points on that parameter, slow, medium and fast. In actual parts, the speed will depend on a dozen or so parameters (like actual line widths, thickness of metal layer(s), I'm not a process guy, but you can imagine the list.) The basic problem is that we, as mortals, do not have sufficient time to completely test our designs over all possible conditions.
The basic Rambus problem is that they, too, are relying on a bunch of prop delays being equal (that is cancellable). If the process tends to produce the occassional slightly large or slightly small transistor (relative to its neighbors), the result will be a race result that was not what was desired.
This sort of problem could be what is causing the Camino problem, it wouldn't surprise me a bit.
-- Carl |
