🚀 go-pugleaf

In article <4dsjiay00ioC49V0Zf@andrew.cmu.edu> Marissa Gonzalez <mg4s+@andrew.
cmu.edu> writes:


Marissa,

  You went in a little deeper than my backround on the machine. I forwarded
your inquiry to a friend of mine who did the design of the MB chip. I've
marked his reponses with  >>  so you'll be able to pick them out.


>>>> Original Inquiry Starts Here <<<<

   In reviewing the Technical Overview document for the DECstation
   5000/240, I found several memory read latencies that were troublesome.  

	   - 690 ns : single memory read from noncached address
	   - 840 ns : eight word cache load (I calculated from the
				   information given)
	   - 320 ns : processor memory read latency
	   - 440 ns : TURBOchannel memory read latency

   These numbers imply that any memory access requires a 320 ns latency
   probably due to a page-mode read latency.  Is this the case?  


>> Combination of page mode read startup and synchronization latencies.



   If not, why are the latencies so large?  

>> See above.

   If so, why is it that all reads are done using page-mode read?  

>> The penalty for page-mode startup is not any worse than a non
>> page-mode access.

   Why is the page-mode read latency 8-cycle? 

>> I haven't seen the document you are referring to, so I'm not sure
>> what the numbers actually represent.  My guess is that the 8 cycle
>> page-mode read latency is basically:
>>	Function			Cycles
>>	--------			------
>>	pipeline address input		1
>>	drive row address		2
>>	drive col address		1
>>	clock data into mem card reg.	1
>>	drive data on shared array bus	1
>>	check ECC and correct SBE	1
>>	pipeline data for output	1
>>					--
>>					8

    Finally, why is the TURBOchannel latency 440 ns as opposed to 320 ns? 
   (the only explaination for the 440 ns I could come up with is that this
   included TURBOchannel signalling overhead, specifically cycles t1, t2,
   t3(320 ns), and t4 as specified in the TURBOchannel Hardware
   Specification document for DMA reads).

>> This seems reasonable.

   Too many questions?


>> The large access latencies are primarily a result of the basic
>> design of the system.  Rather than redesign a new synchronous memory
>> system for a faster R3000A (40Mhz+), the decision was made to preserve
>> the 3max (previous generation) memory control logic in its entirety.
>> As a result, a new memory buffer ASIC was required to provide the
>> asynchronous interface between the high frequency R3000A and the 25Mhz
>> memory system.  A by-product of this new ASIC was that the system could
>> now support processor systems (R3000A and cache) in the 25Mhz to 55Mhz
>> range, and the customers could protect their investment in the 3max
>> memory array cards.  This was basically a case where time-to-market,
>> flexibility, and investment protection took precedence over performance.



>>>> This is AJ again, I just wanted to let you know that we'll do the
     best we can in answering your questions. I am still trying to get
     the functional specifications for these systems published (which 
     I think will help folks a lot). In the meantime, I'll just ask that
     you be patient about the response times. We're facing a move to 
     another building here in Palo Alto and DECworld starting at the end
     of this month in Boston (which is going to soak up a lot of resources
     for several weeks). I expect life to be back to normal (you call this
     normal??) sometime around the last week of May. We'll keep up as
     best we can. Bear with us.

				Thanx,
				  AJ


      **********************************************************************
      * AJ Casamento			"The question is not whether or    *
      * Digital's TRI/ADD Program	 not the opinions are mine; but    *
      * 100 Hamilton Ave. UCO1-B	 rather, which of my personalities *
      * Palo Alto, CA 94301-1616	 do they belong to?"		   *
      * 415.853.6744							   *
      * ajc@decwrl.dec.com						   *
      **********************************************************************