jack@focsys.uucp (Jack Houde) (06/26/90)
In article <2229@mindlink.UUCP> a575@mindlink.UUCP (Michael G. Henders) writes: >I'm curious about how one goes about building a frame buffer for a high-res. >actually work. :) BUT, how does it work with the more common x1 RAM chips?? >In this case, you access 8 chips in parallel, but you only get one pixel out of >it, so the access interval is 14 ns; pretty quick for SRAM, and right out for >DRAM. > > I guess one could bank-interleave, but, using 1 Mb chips, this means you end >up with N times the amount of RAM you actually need, where N is the interleave >factor; I can't see anyone actually doing this. Clearly, I'm missing something >fundamental here; can someone tell me what it is?? Thanks much... > > Mike Henders a575@mindlink.UUCP You might want to look at a 256k by 32 organization. On every clock you latch the output data and then increment to the next address. The data is sent out at the full clock rate (somewhere near 19.69 MHz) in chunks of 8 bits, whereas the address counter is 1/4 of that (5 MHz) which allows for the use of standard 120 nsec DRAMS. Anything faster than 80 nsec DRAMS would probably warrent the use of VRAMS. The great thing about these is that they allow for the simultaneous reading and writing of data (almost! given the horizontal retrace time).
henry@utzoo.uucp (Henry Spencer) (06/26/90)
In article <2229@mindlink.UUCP> a575@mindlink.UUCP (Michael G. Henders) writes: >... BUT, how does it work with the more common x1 RAM chips?? >In this case, you access 8 chips in parallel, but you only get one pixel out of >it, so the access interval is 14 ns; pretty quick for SRAM, and right out for >DRAM. > > I guess one could bank-interleave, but, using 1 Mb chips, this means you end >up with N times the amount of RAM you actually need, where N is the interleave >factor; I can't see anyone actually doing this. Clearly, I'm missing something >fundamental here; can someone tell me what it is?? Thanks much... The fundamental point is that nobody builds such frame buffers with x1 RAMs. You have discovered a basic fact: frame buffers for high-resolution screens with many bits per pixel need LOTS AND LOTS of bandwidth. That demands, in practice, parallelism: many bits coming out of the memory on each access. 32 or 64 is much more typical than 8. That pushes designers very strongly towards RAMs with multi-bit outputs, unless the architecture needs lots of extra memory anyway. In particular it very strongly encourages the use of video RAMs, which have both multi- bit output and a dual-porting scheme which gives *very* wide parallelism on the time-consuming access to the actual memory array. Nobody in his right mind uses anything but VRAMs for frame buffers unless there is some compelling reason why they won't work for the particular application. -- As a user I'll take speed over| Henry Spencer at U of Toronto Zoology features any day. -A.Tanenbaum| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
phil@pepsi.amd.com (Phil Ngai) (06/27/90)
In article <1990Jun26.154640.26941@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: |Nobody in his |right mind uses anything but VRAMs for frame buffers unless there is some |compelling reason why they won't work for the particular application. I wouldn't be quite so strong about that. VRAMs are a lot more expensive than regular DRAMs, and since you can run 50 ns page mode cycles on ordinary DRAMs, you can easily get 20 Mhz * 32 = 640 million bits/sec or 80 million 8-bit pixels/sec out of 1 megabyte of memory (8 x 256K x 4). That's 1.3 million pixels/frame at 60 Hz. The shift register on 64Kx4 VRAMs typically has a minimum access time of 40 ns. The newer 256Kx4 VRAMs push that to 30 or 25 ns. By the way, you can probably get away without refreshing such memories. VRAMs do have an update advantage which may or may not outweigh their cost disadvantage. It depends to a large degree on whether you live in a PC or a workstation world. -- Phil Ngai, phil@amd.com {uunet,decwrl,ucbvax}!amdcad!phil Separate but equal: Bad for blacks, good for women.
davidc@vlsisj.VLSI.COM (David Chapman) (06/27/90)
In article <2229@mindlink.UUCP> a575@mindlink.UUCP (Michael G. Henders) writes: >I'm curious about how one goes about building a frame buffer for a high-res. >graphics board, in terms of the memory arrangement. I understand how VRAMS >work, but I'm having trouble figuring out how one would build the frame buffer >out of DRAMS (or even SRAMS, for that matter). Let's consider SRAMS, to avoid >having to worry about refresh; for a 1024x1024x8 screen, with 60 Hz Actually DRAMs work just fine. Use the memory access as the refresh! You just have to get the address bits connected in the right order. It's been too long since I've designed with DRAMs (16 Kbit DRAMs were new), so I may get RAS and CAS confused in the following discussion. As I recall, selecting a row with RAS automatically refreshes all of the bits in it, even if you then read or write one bit in it with CAS. As a result, if you make your low-order address bits (in the scan line, not the scan line number) be the RAS bits (vs. CAS), then your memory will be refreshed at much more than the minimum rate! >non-interlaced raster update, we need a new pixel every 15.9 ns, neglecting >blanking intervals. Let's say it's 14 ns. > > Now, the obvious (and, I suspect, wrong) way to do this is to use x8 RAM, with >each address representing one pixel. This means 14 ns. access intervals. Less >obvious (but maybe more likely) is to use x8 RAM, with each address >representing one bit of 8 pixels. This means you access 8 chips in parallel, >with a 112 ns access interval. So far, so good; this sounds like it might >actually work. :) BUT, how does it work with the more common x1 RAM chips?? >In this case, you access 8 chips in parallel, but you only get one pixel out of >it, so the access interval is 14 ns; pretty quick for SRAM, and right out for >DRAM. The best way is to read n bits at once into a shift register, then use your dot clock to shift out the bits. This is the way that video DRAMs work. For example, if you had two x8 RAMs (DRAM or SRAM), then you would have a 16-bit shift register and would need to access memory at 1/16 the dot clock rate (14 ns x 16 is 224 ns - no problem with today's DRAMs). If this is faster than your memory cycle time (*not* access time), then simply make the shift register and memory bank wider. You *never* access the RAM bit-by-bit "at speed", only word-by-word. In fact, your graphics controller is probably going to have to manage reads and writes to video RAM for you, to get individual bits and to schedule your access in between display refresh accesses. The key is that you never use the addressing bits at the bottom - the ones that change the fastest. With 16 bits read at once, the lowest 4 bits of the dot address in the row are discarded. You gain access to them implicitly during display via the shift register and explicitly during processor read/ write using masking or special hardware. You lose the ability to access dots directly (at least without special hardware), but as you can see you gain the ability to display your data. How you get the 16 (or 32) bits is up to you: 16 x1, 4 x4, 2 x8, etc. It makes no difference. By the way, 70 MHz dot clock rates (the 14 ns you quote above) are not unheard of. -- David Chapman {known world}!decwrl!vlsisj!fndry!davidc vlsisj!fndry!davidc@decwrl.dec.com
henry@utzoo.uucp (Henry Spencer) (06/27/90)
In article <1990Jun26.200549.792@amd.com> phil@pepsi.amd.com (Phil Ngai) writes: >|Nobody in his >|right mind uses anything but VRAMs for frame buffers unless there is some >|compelling reason why they won't work for the particular application. > >I wouldn't be quite so strong about that. VRAMs are a lot more expensive >than regular DRAMs, and since you can run 50 ns page mode cycles on >ordinary DRAMs, you can easily get 20 Mhz * 32 = 640 million bits/sec >or 80 million 8-bit pixels/sec out of 1 megabyte of memory (8 x 256K x 4). >That's 1.3 million pixels/frame at 60 Hz. At the cost of using the entire DRAM bandwidth, leaving none for updates! I said "in his right mind". :-) Given that modern CPUs can routinely drive a memory system until the bolts fall out, and people complain that the CPU nevertheless can't update the display quickly enough, a well-designed frame buffer needs plenty of update bandwidth too. The nice thing about VRAMs is that they use only a tiny fraction of the memory array's access bandwidth, due to their very wide internal access path. Of course, if you're selling to the PC market and it doesn't *have* to work well, that's another story. I suspect that the PCers will catch on sooner or later, though. -- "Either NFS must be scrapped or NFS | Henry Spencer at U of Toronto Zoology must be changed." -John Osterhout | henry@zoo.toronto.edu utzoo!henry
hoque@huxley.UUCP (Tareq Hoque) (06/28/90)
Before vram came out most frame buffers were created with standard memory devices, but the user would have to interleave (some times called banking) several banks of memory to accomodate the slow access times of the memory devices. If the width of the memory device was not as wide as the pixel data width (as in x1 Drams), then you would have to replicate the memory banks for each data bit and run them in parallel. As you can imagine old fashion framebuffers could get very big. As an example an 8x interleave would mean that a memory device supplies every eigth pixel. The easiest way of accomplishing this would be to take a parallel in - serial out shift register that is 8 bits wide, with a shift clock that is connected to the pixel clock. This circuit would be duplicated eight times to supply each bit of an eight bit pixel. hope that helps. =tareq
jack@focsys.uucp (Jack Houde) (06/29/90)
In article <540@huxley.UUCP> hoque@huxley.UUCP (Tareq Hoque) writes: > > >As an example an 8x interleave would mean that a memory device supplies every >eigth pixel. The easiest way of accomplishing this would be to take a >parallel in - serial out shift register that is 8 bits wide, with a shift >clock that is connected to the pixel clock. This circuit would be >duplicated eight times to supply each bit of an eight bit pixel. > Sounds very much like a VRAM....
jem@cs.hut.fi (Johan Myreen) (07/01/90)
In article <1990Jun26.200549.792@amd.com> phil@pepsi.amd.com (Phil Ngai) writes: >I wouldn't be quite so strong about that. VRAMs are a lot more expensive >than regular DRAMs, and since you can run 50 ns page mode cycles on >ordinary DRAMs, you can easily get 20 Mhz * 32 = 640 million bits/sec >or 80 million 8-bit pixels/sec out of 1 megabyte of memory (8 x 256K x 4). >That's 1.3 million pixels/frame at 60 Hz. Aren't you a little optimistic in saying that you can easily get a bandwidth of 20 MHz * 32 out of regular DRAMs? You will have to write to the chips too, which, in addition to making one cycle unavailable for a read operation, also makes the next read 'out of page'. The calculations should be made for the worst case, not the best case. And even a realistic assumption of 1.3 million pixels per frame doesn't give you a very big margin, if you want a display of say 1024 pixels across. -- Johan Myreen jem@cs.hut.fi
phil@brahms.amd.com (Phil Ngai) (07/10/90)
In article <JEM.90Jun30204859@sauna.hut.fi> jem@cs.hut.fi (Johan Myreen) writes: |Aren't you a little optimistic in saying that you can easily get a |bandwidth of 20 MHz * 32 out of regular DRAMs? You will have to write I was talking about display bandwidth and the part of my article you left out did say that VRAMs have an advantage when it comes to updating the display. |And even a realistic assumption of 1.3 million pixels per frame |doesn't give you a very big margin, if you want a display of say 1024 |pixels across. I also said in the part of the article you cut out that I was mainly talking about the PC world, where 640x480 is considered high-res. -- -- Phil Ngai, phil@amd.com {uunet,decwrl,ucbvax}!amdcad!phil PALASM 90: it's not the same old PALASM any more!