Yet another video proposal
kwinn
Posts: 8,697
@Leon, You seem to be the most knowledgeable person on the forums when it comes to FPGA's and CPLD's. Any thoughts on the best chip to do what I have outlined below?
After reviewing the prop video documentation and looking at several approaches to producing higher resolution and greater color depth video I have to agree with Leon that a small FPGA or CPLD is the way to go. Yes, it could be done with counters, latches, and the memory chip, but that would involve more chips, cost more, and be less flexible.
A single cog to produces the horizontal and vertical sync signals along with a dot (pixel) clock. That leaves the other 7 cogs free for communications and updating the video RAM. Having the prop generate those signals also makes synchronizing the video and memory writes simpler.
The dot clock increments the Scan counter (20-24 bits?) in the FPGA/CPLD that is output to the RAM address pins during the video scan time.
The Scan counter DotClk is gated by the Horizontal and Vertical sync signals so that video data is stored sequentially in RAM. There are no gaps in the video data.
The Address counter and R/W signal is output to the RAM address pins during the Horizontal and Vertical sync times so the propeller can write new data during that time.
The Address register high and low 12 bits can be loaded from the data bus.
The 12 bit value on the Propeller to FPGA/CPLD data bus can be added to the Address register in order to get to the next line of video data.
A 12 bit data bus and 3 control lines (A0, A1, R/W) control the FPGA/CPLD and write through to the RAM.
After reviewing the prop video documentation and looking at several approaches to producing higher resolution and greater color depth video I have to agree with Leon that a small FPGA or CPLD is the way to go. Yes, it could be done with counters, latches, and the memory chip, but that would involve more chips, cost more, and be less flexible.
A single cog to produces the horizontal and vertical sync signals along with a dot (pixel) clock. That leaves the other 7 cogs free for communications and updating the video RAM. Having the prop generate those signals also makes synchronizing the video and memory writes simpler.
The dot clock increments the Scan counter (20-24 bits?) in the FPGA/CPLD that is output to the RAM address pins during the video scan time.
The Scan counter DotClk is gated by the Horizontal and Vertical sync signals so that video data is stored sequentially in RAM. There are no gaps in the video data.
The Address counter and R/W signal is output to the RAM address pins during the Horizontal and Vertical sync times so the propeller can write new data during that time.
The Address register high and low 12 bits can be loaded from the data bus.
The 12 bit value on the Propeller to FPGA/CPLD data bus can be added to the Address register in order to get to the next line of video data.
A 12 bit data bus and 3 control lines (A0, A1, R/W) control the FPGA/CPLD and write through to the RAM.
Comments
I am very interested to see the end result, especially if it can be done at a lower cost (of which I am quite skeptical at this point).
Being a video generation circuit it is in some ways similar to yours. It was inspired by the design of a terminal that used a Z80 (I think) or similar microprocessor as a smart counter to generate the address scan for an 80x24 character terminal. It only had to scan through memory and present 80 characters per scan line to a latch so even an early 8 bitter could do that.
In pure parts cost I am sure the FPGA/CPLD is more expensive than four latches, 2 buffers, and a resistor dac. No reason this design couldn't use a resistive dac., and with a small FPGA/CPLD (around $10.00) I can interface that prop to the memory with a single chip (less PCB real estate and fewer parts to mount).The FPGA/CPLD also provides additional functionality and reduces the load on the prop to the point that 1920 x 1080 might (stress on the might) be possible.
PS - As for being more complicated, programming the chip certainly is more work initially, but less in the long run.
Back of an envelope, if you had 640x480 and went for 5 bits per color, that is 15 bits. 640x480 is 307k so that would fit in two 512k x8 chips, or (if available) one 512k x16 bit chip. If it works you could then go for more bits per color. But 5 would look pretty good though and it would also be well within the accuracy of a R 2R network so no clever DAC chips would be needed.
I researched this a few months back and where I got stuck was finding a suitable ram chip. I think it needs to run at 25Mhz for VGA? So ?30ns, ?25ns or 10ns to be sure?? Price vs speed is a factor.
And then there are delays within any support chips. eg if you used 74xx counter chips, are they ripple binary count or are the outputs synchronous? Or could the propeller do the counting fast enough - eg use a latch for each row but have enough lower bits to do one row directly from propeller pins.
This is a fascinating topic!
Some notes:
. Altera version: a monolithic video DAC was used, no R2R needed. It has 512kx16 SRAM and works
. Xilinx versions:
I used a XC9572 + a XC9536 with 512kx8 SRAM. The code can only produce an image as there are not enough macrocells for the propeller interface
The second prototype has the same limitations but I used a XC95144.
Btw, I used a similar approach with these two prototypes
I also did a FPGA version
http://forums.parallax.com/showthread.php?119689-A-new-dimension-in-Propeller-marriages-pPropFPGA&highlight=pPropFPGA
Notes: You need a latch for the video data. unless you only write to RAM during blanking. (a '573 will do)
Edit: What I wanted to say was: prototype the code first and simulate it ! (I use Icarus Verilog+GTKWave), then grab the tools from your preferred vendor and (fix the code) and see which device you need... Xilinx CPLD are incredibly small
Nutson did something like this (along with a Propeller COG execution unit!) in an FPGA. That man is brilliant - words I don't use often.
I also wanted to code a COG into a FPGA... and thus learned Verilog... I coded several processor cores... they are a lot of fun, not very prop related, though. A COG needs loads of logic...
David, you are probably right about my idea having problems with the FPGA at the higher data rates. I spent some time looking at low priced chips and could not find much that was faster than 10ns. The only workaround I can see is outputting 2 pixels to latches and displaying them in sequence. How ironic.
As for the cost difference, I am not too concerned about having the board cost a few dollars more if it gives me some flexibility with regards to resolution, communications, and on board software. In any case replacing one of the two props, the latches, and the buffer chips with an FPGA for a few dollars more seems like a reasonable tradeoff.
For my own use I have two goals to meet with this board if I can make it work.
The first is as a standalone graphical data display driver at the end of an RS485 line, which requires the prop to have enough processing power left over for serial communications, to format the received data for display, and to run a touch screen or keyboard.
The second is to have it attached locally as the graphical display and control console for an automation system.
Dr_Acula, after hunting down various CPLD's, FPGA's, SRAM's, SDRAM's, and other such goodies I can see that any design is severely constrained by the chips that are available.
First and foremost, none of the reasonably priced CPLD's or FPGA's seem to be fast enough for 1080P (1920x1080 @ 60Hz). I would love to be proven wrong on that point, so if anyone can do so please, please, please, do so.
Second, RAM seems to come in multiples of 8 bit widths while video out is in multiples of 3. Yes, I know there are some 9, 18, and 36 bit wide chips but they are either too slow, too expensive, or impractical to use. That leaves a Look Up Table (an additional chip), wasting a bit, or giving an extra bit to some color.
Currently I am proposing 1280x1024 the max resolution for 4x3 ratio displays, and 1280x720 (720P) the max for 16x9 ratio (wide screen) displays. All these resolutions would have 256 colors per pixel available with a resistor dac of 3, 3, 2 bits. I am wondering if it is possible to provide 1080P (1920x1080@60HZ) at a reduced color palette (16 colors) by treating each 8 bit pixel as 2 4 bit pixels.
Ale, any information you can PM to me would be greatly appreciated. Although the requirements in this case seem to be fairly simple, FPGA and CPLD programming is uncharted territory for me. The last chips I dealt with were the 16-something PAL chips way back when. At this point I have no desire to climb another learning curve so any help you (or any one else) can provide would be greatly appreciated. I would like to make this an open source/open hardware project for the benefit of everyone.
http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,400,836&Prod=ATLYS
For basic graphics a much cheaper device could be used, with less RAM.
In my own experiments I have found that the most expensive component is the SRAM, and the cheapest CPLDs that I can find that would fill the job are 2 to 3 times the price of all 4 SRAM chips combined.
For a Spartan-6 that would fit the bill, you are talking about at least $18.00 (USD), and probably closer to $30.00 (USD), not to mention of the cost in correctly soldering BGA, not so 'low-cost'.
True in production quantities, not so true for one off home built devices. I often have to remove, and replace BGA devices on the boards I make because one or more balls are not attached.
Leon:
Maybe so, though to do this at home by most hobbyist is more difficult, buying the blank two sided board easy (and cost almost nothing) masking, and etching the board, quick and easy, drilling vias and holes for through hole devices, easy, and soldering QFP and QFN components (in an oven) easy. Having to check BGA components not so easy.