Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Rambus (RMBS) - Eagle or Penguin -- Ignore unavailable to you. Want to Upgrade?

To: John Walliker who wrote (34247)	11/11/1999 8:31:00 AM
From: wily	Read Replies (2) \| Respond to of 93625

John, I sent your objection to the author -- I'll let you know if I hear back. Regards, wily

To: John Walliker who wrote (34247)	11/11/1999 8:54:00 AM
From: Glenn Norman	Read Replies (1) \| Respond to of 93625

Yo_John Walliker.................I want to thank you for your technical FUDD (Fear,Uncertainty,Do-Do)busting for the last couple of months. I believe that because of your post you have probably kept many, many holders of RAMBUS from selling their stock in the 50's, 60's, and 70's, and I believe that those that held because of your efforts and due diligence are grateful to you beyond words. Most of those on this thread have no technical knowledge in regards to being able to know if the crap posted by a bunch of AMD zealots with an agenda to smear RAMBUS was true or not without your wonderful vigilance---so again JOHN WALLIKER THANK YOU!!! SALUDE TO YOU JOHN! Glenn Norman. L R for a V L T!

To: John Walliker who wrote (34247)	11/12/1999 11:53:00 AM
From: Ali Chen	Read Replies (2) \| Respond to of 93625

<If the authors had wanted to be accurate they would have noted that the traces are narrowed in the vicinity of memory chip connections so as to compensate for this by reducing the trace capacitance by an amount equal to the device input capacitance.> You have no remote idea what are you talking about, "trace capacitance". I strongly suggest you to read on the own RAMBUS design guides before expressing your illiterate opinions. The article precisely captured the main problem of the RAMBUS: "This is like merging your car onto a busy highway when there is only a single car length gap in the traffic to exploit - your timing is critical." I would add that the article does not address another even more important problem of how to deal with "on-going traffic" for write packets. It would be like trying to get into the left access road through small gaps in dense on-going traffic travelling at about the speed of light. You would not try this on the road, do you? Yet the RAMBUS designers are forcing you to do this on the RAMBUS "highway"...

To: John Walliker who wrote (34247)	11/12/1999 1:29:00 PM
From: wily	Read Replies (1) \| Respond to of 93625

. Reply from Paul DeMone (emailed to me): ---------------------------------------------------------------------- First of all, let me make this perfectly clear. I am not privy to any Rambus technical material under NDA, only what is in the public domain. Secondly, for a PWB microstrip trace with characteristic impedance of 28 Ohms, the specific capacitance is around 5 pF per inch. Thus complete compensation for 2.0 to 2.4 pF of device input capacitance from the trace being "narrowed in the vicinity of memory chip connections" is hard to believe. If my critic is willing to back up this claim with a digitized hardcopy from a time domain reflectometry tests of a bare and a populated RIMM I will be happy to examine it. This approach also risks introducing non-uniformities in the channel impedance and causing signal degradation and reflections. Perhaps this might be contributing to the well publicized problems with Camino motherboards. The question of 50 Ohms vs 28 Ohms Z0 affects the specific capacitance of signal traces, and therefore the degree to which device loading will slow down the signal wavefront propagation velocity. But the basic underlying maximum speed is set by the PWB dielectric constant, not the characteristic impedance and calling time-of-flight delays "non-existent" is utter nonsense. Regardless of the degree of waveform velocity degradation from device loading the physical aspect of DRDRAM with up to 28 inches or more of difference in round trip path length between the chipset and a near device and far device causes significant addition to the read latency seen by the chipset. This is openly demonstrated by the capability of increasing tCAS in near devices by 2.5, 5.0, 7.5 and 10.0 ns under firmware/chipset control. Don't take my word for it, here's a quote from the description of the TCDLY0 and TCDLY1 control register fields from page 43 of the NEC datasheet for the uPD488448: "This adds a programmable delay to Q(read data) packets, permitting round trip read delay to all devices to be equalized" I don't know about rambus guys, but I never have the design time or silicon area to waste adding control registers and their associated functional logic to my chips to address "non-existent" system effects.