On Fri, Mar 17, 2006 at 05:18:11PM -0700, James Richard Tyrer wrote:
> Timothy Miller wrote:
> >On 3/17/06, Dieter <[EMAIL PROTECTED]> wrote:
> >
> >>>Perhaps we'll have to wait for the next generation product before we
> >>>can do these things. Only then will we be trying to get good game
> >>>performance anyhow, where things like gamma 1 matter, requiring more
> >>>bits per channel.
> >>Games? Graphic artists seem to be the main users demanding color depth
> >>and calibration.
> >>
> >
> >Good point. We would like to support those people. I'm convinced.
> >So now, how do we do it? :)
> >
>
> As I said before, you need all of the data inputs of the DACs connected
> to the FPGA. IIUC, we are short on pins. The problem here seems to be
> the LVDS signals that take 2 pins each. I don't see 0.5 GHz signals
> driving long traces as a good idea. They would have to be strip lines
> terminated at both ends. LVDS drivers would work and we would probably
> gain some advantages compared with using the FPGA to drive the LVDS
> lines, but that is going to be another $30 or so to populate the HiRes
> output for 12 bits.
>
> Now that we have opened the box, I notice that Maxim also makes 14 and
> 16 bit versions of the DAC, so should the Board be able to accept these
> since they are pin compatible?
>
> You need 3x256x16 bits of memory for the palate which can be bypassed.
> Either the data in video memory is used as the addresses to the three
> blocks of memory and the data in the palate memory drives the DACs or
> the memory is bypassed and the date in video memory drives the high 8
> bits of the DACS and the low bits are driven with ones. The board
> should boot up in the bypass mode. Then you need to be able to write to
> the palate memory either as 8 bits per color (the high 8 bits) (and fill
> the low bits with 1s for backward compatibility) or as 16 bits per
> color. I think that the rest is software.
This is starting to sound like the definition of another product to
me, aimed at a higher performance level with a higher cost.
Without knowing all the details of the FPGA interface, a single-
ended to LVDS conversion stage doesn't sound all that crazy to me. It would
add prop delay, but there are at least two ways to cope with that. What it
would take is putting the same delay in all the DAC bits, so they'd all have
to be buffered in the same way. The DACs are registered, right? So if the
buffers are combinatorial, and they add too much delay to meet the DAC
register setup time, just add an equal delay to the register clock.
Otherwise, registered single-ended to LVDS buffers might be used, and they
would add a pipeline delay to the data going to the DACs, but there would be
no problem with setup times.
And, it appears that the conversion would free up some FPGA data
pins for other uses.
But, the extra chips add cost and board area, which probably isn't
justified in the OGD1. So, the idea could be saved for a later, more
specialized board, which perhaps would be a standalone product not intended
to be turned into an ASIC.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
