home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 6790 < prev    next >
Encoding:
Text File  |  1996-08-05  |  4.9 KB  |  104 lines

  1. Newsgroups: comp.sys.amiga.programmer
  2. Path: netnews.upenn.edu!dsinc!scala!news
  3. From: dave.haynie@scala.com (Dave Haynie)
  4. Subject: Re: CHIP RAM speed test resul
  5. Sender: news@scala.scala.com (Usenet administrator)
  6. Message-ID: <1996Apr2.234528.8971@scala.scala.com>
  7. Date: Tue, 2 Apr 1996 23:45:28 GMT
  8. Reply-To: dave.haynie@scala.com (Dave Haynie)
  9. References: <4j6jv0$1im@serpens.rhein.de> <5827.6659T112T770@mbox.vol.it>
  10. Nntp-Posting-Host: gator
  11. Organization: Scala Computer Television, US Research Center
  12.  
  13. In <5827.6659T112T770@mbox.vol.it>, bizzetti@mbox.vol.it (Fabio Bizzetti) writes:
  14.  
  15. >As far as I recall my A1200 chipram is 80ns; while it's exploited as if it was
  16. >only 140ns. The rest of ns is wasted because Alice holds control of everything,
  17. >and Alice is slower than the CPU.
  18.  
  19. You don't understand dynamic RAM. The 80ns rating on a DRAM is the row
  20. address access time. That's usually (depending on the part and the
  21. memory controller), the fastest that data can be accessed from that
  22. part. However, DRAM also has a row address precharge time, which is
  23. usually about 60-80% of the access time. So while you can access a
  24. word in 80ns from the start of the memory cycle, you can't
  25. continuously run random access cycles any faster than around 140ns,
  26. for an 80ns part. 
  27.  
  28. >Since you didn't get what I meant last time, I'll try to explain my thought
  29. >better: if you put 10ns ram in your 68030 board, it doesn't mean that it will
  30. >be exploited as 10ns. It will be exploited as your ram controller allows, 60ns
  31. >or 70ns commonly. 
  32.  
  33. Which is 100ns-120ns cycle times, commonly, for those memory speeds.
  34.  
  35. >Well, the chips inside my A1200 ("chipram") are much faster than
  36. >they're supposed to be, but Alice brakes the CPU to gain from this
  37. >speed because in fact Alice is chipram's controller.
  38.  
  39. Not at all. The 80ns parts on the chip bus are exactly as fast as
  40. they're supposed to be. The constraint on speed is not the normal
  41. access time, but the timing for Alice's burst cycles. For video fetch,
  42. Alice runs 64-bits to Lisa every 280ns. The burst cycle timing is
  43. fairly critical, so 100ns parts would not work here.
  44.  
  45. >>It is clear that you can do better than current 7MHz chip RAM but
  46. >>that's because RAM is faster nowadays.
  47.  
  48. >It would be sufficient to modify the interface   CPU <->chipram<-> Alice.
  49.  
  50. If Alice were designed in a modern process, and you ran the actual
  51. chip bus timing from a 28MHz or 56MHz basis, rather than the 14MHz at
  52. present, you could probably run four cycle bursts to Chip RAM in the
  53. 280ns window. Maybe CPU bursts too, though there's another problem
  54. with memory access, and that's one of matching the cycle to the
  55. CPU. It does you no good if you have data ready when the CPU can't
  56. take it. The chip bus is a synchronous bus, and if you were to burst
  57. four words out of it for a CPU cycle, you would either need a CPU that
  58. perfectly aligned with the chip bus timing, or you would need a FIFO
  59. device to store the fetched data for when CPU could take it. 
  60.  
  61. >Maybe the "ram controller" that you wish (to multiplex data) would be more
  62. >expensive than 2Mb of real dual access ram, this is to be examinated.
  63.  
  64. Real dual-ported random access memory is exotic. You usually get it in
  65. hundred-byte chips, generally used for contention-free mailboxes in
  66. high performance multiprocessing systems. Video RAM (VRAM) is a
  67. special purpose dual ported RAM, and it's commonly used in graphics
  68. systems to get the video fetch activity decoupled from the "chip
  69. bus". The AAA system supported VRAM, but it's a rather tricky thing to
  70. support, since the video access portion is serial, not random
  71. access. The AAA chips used a double line-buffer scheme to get around
  72. this, but it's not a real cheap solution. More primitive graphics
  73. systems can limit where displays live in order to simplify the
  74. requirements for VRAM. 
  75.  
  76. However, VRAM is expensive, since it's roughly 50% larger per cell
  77. than DRAM. There's no inherent advantage to dual porting over other
  78. methods. The main goal in making a faster graphics system is to speed
  79. up the aggregrate bandwidth of the system. Dual porting can double (or
  80. more like triple) a memory's bandwidth. But if I speed memory access
  81. other ways, like increasing the bus size, I can get the same
  82. advantages by time multiplexing the bus. There's nothing inherently
  83. wrong with the way the Amiga does it, it's just dealing with
  84. technology that began life in the mid 80s.
  85.  
  86. >> We already have "dual port RAM", just the multiplexing is done outside the
  87. >> chip.
  88. >
  89. >This is the problem: it's performed by the 7Mhz (bus clock) of Alice.
  90.  
  91. Alice has a 14MHz bus clock.
  92.  
  93. >Just think, 24Mb/sec
  94.  
  95. Oh by the way, "24Mb/sec" means "24 megabits per second". I think you
  96. mean 24MB/s in all your talk here...
  97.  
  98. Dave Haynie          | ex-Commodore Engineering |   for DiskSalv 3 &
  99. Sr. Systems Engineer |  Hardwired Media Company | "The Deathbed Vigil"
  100. Scala Inc., US R&D   |    Ki No Kawa Aikido     |     info@iam.com
  101.  
  102.          "Feeling ... Pretty ... Psyched" -R.E.M.
  103.  
  104.