As far the Burr Brown OPA695 is concerned, this was the first amp I considered. However, TI (who own Burr Brown) have some free spice simulation software that I used to design this circuit. The free software did not have a model for the OPA695, so I chose best part for which a model existed, namely THS3201.
Regards, Howard. On 3/16/06, James Richard Tyrer <[EMAIL PROTECTED]> wrote: > Timothy Miller wrote: > > 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? > > Oh I see we have two analog outputs. Perhaps a block diagram added to > the schematic would help. The video buffers are for the higher > resolution head on page 13 which doesn't seem to have a title. So, yes > if that is for resolutions over 1600 x 1200 you do need amps that fast > although I would also consider the Burr Brown OPA695 which is better on > some specs than the THS3201 and is slightly less money. > > >>> 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? > > Yes video signals -- horizontal resolution can be specified in pixels or > in lines. A line being one white pixel and one black pixel. I am > always confused by this if I don't stop to think about it. > > >>> 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. :) > > No, if you are trying to display square pixels, the rise time is important. > > >>> 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. :) > > OK. A square wave = 1*f1 + 1/3*f3 + 1/5 f5 + ... > > So for a good square wave, you need to have the bandwidth extend to the > third harmonic -- 3 times the frequency of the square wave. > > >>>> 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. > > The ones on page 13 are 12 bit and color correction might be a needed > feature for such high end applications. > > > 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. > > Yes, I see now. I was only looking at the individual pages. > > -- > JRT > _______________________________________________ > Open-graphics mailing list > [email protected] > http://lists.duskglow.com/mailman/listinfo/open-graphics > List service provided by Duskglow Consulting, LLC (www.duskglow.com) > _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
