On 3/15/06, James Richard Tyrer <[EMAIL PROTECTED]> wrote: > Timothy Miller wrote: > > On 3/15/06, James Richard Tyrer <[EMAIL PROTECTED]> wrote: > >> I am looking at the analog parts of the schematic and haven't found > >> anything yet. > >> > >> I had some questions about the design. I have answered some by > >> downloading some data sheets. But still have some remaining > >> questions about the video DACs. > >> > >> It seems that we have a very expensive solution for this so I was > >> wondering about the required specs. > >> > >> 1. What is our max clock rate for the DACs? > > > > 330MHz for the one being populated. > > > >> 2. What is the bandwidth required for the video out buffers. > > > > Can you explain what you mean by "video output buffer"? > > That is the ths3201 (analog) amplifier between the DAC and the VGA socket.
Which head is this for? The 330 or the 500? > > > The total memory bandwidth is 1.6*10**9 pixels per second, while the > > max video for one head is only 330*10**6. > > > >> Note that in theory if we use shunt peaked video out buffers that > >> #2 would be twice #1 for analog video but it would be normal to > >> have an additional frequency margin. > > NO, that is wrong pixel resolution is twice line resolution so it would > theoretically be 1/2. I am always confusing that. I'm really not sure what you mean here. Are you talking about a TV signal? > > > > We're going to have no trouble at all with getting pixels out of > > memory onto the screen. With both heads at 330 megapixel/sec digital > > (which requires a bit more bandwidth than analog due to reduced > > blanking), that's less than 660 million pixels per second. That's > > 40% of our bandwidth, but you won't even notice that until you start > > using the more advanced 3D features that suck bandwidth. > > > >> There is digital so you would probably want the video out signal to > >> have the 3rd harmonic for good rise time. If so, you need 6x +/- > >> and TV video buffers wouldn't do the job. > > So this would be 3x which would be 990 MHz. You must be talking about some kind of LRC filter, to filter out high-freq noise but allow rise/fall times to be fast. This is analog black magic to me. I'm glad you're on it, and Howard will make sense of it. :) > > > > It now occurs to me that when you say "bandwidth", you're talking > > about an analog thing, in terms of signal line transmissions and all > > that. > > Yes the bandwidth of the analog video amplifiers. So, if we are going > to have a max pixel clock rate of 330 MHz, do we really do need the > 1.8GHz video amp for maximum sharpness. Also, we should consider the > specs of available monitors since there isn't much point in having a > bandwidth significantly wider than the monitor. Unfortunately, most > companies don't seem to give out the bandwidth of the monitor's video > amps. Monitor specs seem to include: "Maximum Input Video Bandwidth" > and I don't know if they mean digital (dot clock) or analog (video amp). > I think that they mean dot clock which tells us nothing. The unpopulated high-res head is designed for 500 megapixels/sec. > > > That's Howard's thing, I'm afraid, so I really can't talk much about > > it. I'm not even sure what you mean when you say "3rd harmonic". > > :) > > > > > Do you know Fourier series? Just barely. :) > >> I couldn't find a video SRAM in the design? I would want this as a > >> feature in the final board and would prefer 12 bit per color. > > > > The video framebuffer is stored in graphics memory (Those DDR ram > > chips on there) and read out as we're scanning the display. And > > you're going to get 8 bits per color. Remember that OGA is somewhat > > of a minimalist design, targeted at performing well for desktops. > > Neato stuff like programmable shaders and higher RGB color depth is > > reserved for later generations, when we can AFFORD it. > > A standard video board uses the 8 bit data from the video memory as the > address to a 256 x 10, or 256 x 12 bit SRAM (3 of them since there is > one for each color). The output of these small SRAMs drive the DACs. > This is commonly called the (hardware) Palate. It used to be common to > have all this (3 DACS the SRAM and [sometimes] three video amps) in one > chip (called a RAMDAC), but I don't know if they are available anymore. Yeah. That'll be inside of the big FPGA. > > I could possibly provide a drawing mode where green is 12 bits, > > reducing red and blue to 6 bits, but you won't get this for video > > output. > > > > A design decision was made VERY early on where pixels are fixed at > > 32-bit ARGB. Even 8-bit pseudocolor mode is just a trick of the host > > interface. > > The Alpha channel doesn't go to the output, it is just used internally > so you have 24 bits of color video but this is usually converted into 30 > or 36 bits before it drives the DACs. Not to add more colors but so > that you can tweak the colors. Unfortunately, our DACs don't take more than 8 bits per channel. Also, we'll allow the alpha channel to do double-duty as things like an 8-bit overlay, if anyone finds that useful. > IAC, if 10 bits per color is sufficient, we could use the ADV7123 which > has video buffers built in at a considerable cost savings -- it is also > 3.3 v single supply. However, it does not have 1.8 GHz analog bandwidth > like the design with 3 DACs and 3 video buffers. The spec sheet lists a > rise time of 1 ns (about 1150 V/us). The TI amp is rated at an > unbelievable 10500 V/us. Keep in mind that the high-res head is only intended to be populated for special applications. Almost no one will order it installed. We do want to get it right, though, but expense is not an issue here, since the pads will generally be unpopulated. > But, we don't want to make this too good as it will cost too much. The > joke about engineers and bridges: Anyone can make a bridge that won't > fall down, the trick is to make one that won't fall down at the lowest > cost. :-) Yeah, but think about what Howard, Andy, and I are used to designing for. Pico second rise and fall times. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
