On 5/14/06, Richard Smith <[EMAIL PROTECTED]> wrote:
> I have no problem with the idea of trying to cram a simple 2D design
> into a cheap FPGA and selling that as a complete solution. That was
> my ORIGINAL plan, in fact. We can use OGD1 as the basis for fleshing
> out those ideas.
>
> Imagine fitting everything into the XP6 part on OGD1. I don't know if
> that's possible, really, but it would be interesting to try.
>
> Minimum of what we need:
>
> - Video controller
> - Memory controller
> - Host interface
>
How big and what features are in the video contoller? I have what I
think is the above + a NIOS II and an I2C controller in a cheap
Altera. (I think its an EPC2 but I'll have to look) Like I said
earlier our "video controller" is basically a fifo and some logic that
writes the data into the DDR while not interrupting the frames clocked
out to the DVI chip.
Even a relatively sophisticated video controller that supports
interlacing is just a handful of counters and some fifos. For OGA, I
had some ideas about making a simple programmable controller that
could do essentially anything, but we don't need to do that.
We clock the NIOS at 66Mhz and using this I can throw up a 1024x768
image pretty fast. You can see the redraw but its on par with a lot
of VESA screens I see. I double buffer so its not much of an issue.
All the slowness is in the NIOS II. If it was an 200Mhz ARM it would
be really fast.
Our "Host" interface is nothing more than about 10 32-bit registers
that show up in the NIOS IO space. What kind of host interface were
you thinking?
Well, I was thinking more along the lines of a PCI controller. But
you're right, there needs to be a register set to control things, plus
access to the graphics memory.
How big is the XP6?
I don't remember. We'll figure out what we can fit in it, though...
When doing high res video stuff >= 800x600 I think there may be an
opportunity for a simple video controller to go with the various
embedded cpus.
Well, if all you needed was something to sequence addresses and send
data to video encoder, that's a rather small piece of logic.
The sharp ARM and the XScale we have tested both fall
down at the higher video resolutions. They use host memory for the
framebuffers so at the refresh of say 1024x768x60 large ammounts of
the memory bandwith is spent doing video. And if you go off and make
the cpu do something invovled you can get glitches in your video
output.
I think it's probably better for us to have our own RAM. We just need
to make sure there's enough bandwidth for the max video mode we want
plus some for drawing.
What I don't know is how big the market for something like this really
is or if the next round of ARMs from various mfgs will fix the memory
bandwith problem. Perhpas it only an issue with Sharp and XScale? I
know that Atmel just released a newer ARM that claims 2048x2048 as its
max resolution. I can't imagine that they use host memory for that
but maybe.
I doubt it. Work out the numbers. It's a lot of data to move.
I do know that if I had such a chip and it was cheap (<=$10) it whould
have had a _really_ good chance of ending up in our current display
product.
Well, you've given us something interesting to think about. Of
course, of the FPGA alone costs more than that, we can't quite hit
that market, but perhaps we could get that cheap with some low-end
ASIC technology.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
