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)
