SI
SI
discoversearch

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 : Intel Corporation (INTC)
INTC 34.50+2.6%Nov 21 9:30 AM EST

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: Tenchusatsu who wrote (83312)6/13/1999 7:21:00 PM
From: grok  Read Replies (1) of 186894
 
RE: <Uh, KZNerd, I'm not certain about this, but I really don't think latency will be affected by slowing DRDRAM down to 600 MHz.>

The latency does increase but I can see that my original statement contained a mistake. Where I said: "latency increases by 33%" I meant to say "the latency increase over sdram increases by 33%." I'll try to explain why.

The reason people complain about drdram latency is that address and control get piped into the drdram over a narrow channel and even though the data rate is high it still takes longer than just sending an address in parallel as is done for sdram. Click here:
rambus.com
and scroll to page 7 and you can see that to send a row address takes 4 of the 400 MHz cycles = 10 nsec. (If you're really interested this is because in those four cycles they have 3 pins that can send 3pins*4cyles*2bitspercycle=24 bits of info. They have to send 5 bits of device address since there could be 32 devices on the channel and 4 bits of bank address since there are 16 banks and 9 bits of row address plus a few bits of misc so it just takes that long.)

Now in going to 300 MHz drdrams this 10 nsec increases by 33%. That's what I meant to say. The internal access time of the dram core can be programmed so that it requires fewer cycles at 300 MHz than at 400 MHz. That part is no problem.
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext