User Programmable Standards Converter

[`FRANK.C]

For a while now I have been thinking of building a user programmable standards converter.
What I mean by "user programmable standards converter" is a converter that can be programmed to produce an arbitrary output standard.

I am thinking along the lines of the user would be able to select the following
Number of active lines. (between 576 and say 60)
Number of blanking lines.
Number of broad pulses.
Size of front porch, sync pulse, and back porch.
Height of sync.
Progressive or interlaced.
Frame rate will be confined to 25Hz for a start, at least.

The hardware would be along the lines of
Decoder, FPGA and framestore to do the heavy lifting. Microcontroller, LCD, rotor encoder and/or switch(es) to take care of the user interface.
This is just a rough outline and will most lightly change as things progress.

I have done a little work and to date I have produced active lines from 500 to 96. I am viewing them windowed on a 625 monitor.
The interpolater needs a bit of work in order for it to track the number of output lines correctly.

Some photos below. The number of lines in the photos are 96i, 216i and 220p.
To view the 220p I interpolate one input field and repeat it on the two output fields this eliminates the flicker that would be seen if only shown on one output field.

Frank

[ppppenguin]

Interesting idea. This is picking up where Darryl's World Converter left off. Your outline hardware sounds right. Need to think carefully about how to implement the framestore. My experiments have synthsised multiple video ports on to standard SDRAM. A little bit complex at first but very flexible. It allows you to implement a 4 line interpolator entirely on the output side of the framestore.

Entirely correct to take progressive outputs from 1 input field only. Any other approach will look horrible without some very complex processing.

[`FRANK.C]

Hi Jeffrey
For the moment I am using a board with the good old AL422 on it. But at some stage I expect I will change to SRAM or SDRAM.
The FPGA will be a  EP4CE6E22 as used in Hedghog II as I believe its is the largest no of pins available in a QFP package. I don't fancy trying to solder BGA's!
There isn't an abundance of IO pins on the EP4CE6E22 but the switches that are on Hedghog II wont be needed and also the microcontroller will be able to program the video decoder (and modulators if there will be any) which should free up more than enough pins to accommodate a frame store and interface with the microcontroller.

Frank

[Jac Janssen]

Hi Frank,

A very interesting project!
I'm looking forward to your progress.

Please keep us informed of your goings.

All the best,
Jac

[ppppenguin]

If using AL422 class serial framestores you can frig multiple ports to some extent. Let's say you want a 4 line interpolator. Use 4 framestores, each fed by the input delayed by 1,2,3 lines. Or you can interpolate before the framestore. The fun comes if you want to go flexibly both up and down in line number. Either you have to move the interpolator between input and output, use multiple framestores or use mutliple access like I did.

Because I'd synthesised multiport access on SDRAM for a number of professional projects I took that approach. It took a lot of work to develop the ideas and get them to work reliably, especially if I was pushing the memory bandwidth right up to the limit. My experimental 625 to 405 converter was actually a very easy memory job compared to some I've done.

My multiport stuff uses fixed round robin sequencing of ports, along with request/grant logic for each slot in the sequence. You always need some form of request/grant but in theory you can get slightly more bandwidth by granting slots as soon as possible rather than in round robin fashion. However it's more complex and not 100% deterministic. I wasn't prepard to get into a design that had statistical failure modes that might happen once in a blue moon.

Frank, you're very welcome to all my VHDL for this. It's for original SDRAM and would need a fair bit of modification for later memory such as DDR3. The basic concepts don't change but there's a lot of detail. Xilinx now offer cores for multiport DRAM access. Altera may do likewise. I havn't looked at them seriously.

[`FRANK.C]

Hi Jac
I will keep this thread updated but it could be a slow burning one.

Hi Jeffrey
I haven't given much thought to the framestore yet but I will have to. The temptation is to stick with what you are familiar with. The AL422 is easy to use and with the addition of a few line stores can do all I currently want to do. But as you have said SRAM/SDRAM would offer more flexibility. SDRAM is cheap but enough SRAM to hold a frame or two isn't expensive either.

I would be interested to see your SDRAM controller. The principles of how it works is what most interests me. Juggling reading and writing to the same memory port in different time domains don't sound too easy.

Frank

[ppppenguin]

Care is needed when crossing between clock domains. The SDRAM and its controller runs at 108MHz in my converter. Not critical, it just had to be high enough to give enough memory bandwidth, and below the 133MHz limit of the SDRAM I was using. All the request/grant is done with standard duall flipflop pulse synchronisers. One critical factor is the length of block that you read or write with each request. Each block read or write has an overhead when setting it up. Up to a point, longer blocks give greater BW but less flexibility. There are subtle ways of overlapping block operations slightly but I've avoided doing that as it's a bit hairy.

If you use SRAM rather than DRAM the multiplex principles are the same. You still need a request/grant system. But there's less overhead when switching between ports and no need for refresh. Also no startup sequence. I'll send you the VHDL (though I think you've already got it) and the spreadsheet that I use to analyse the timing.

[jjl]

Would a more modern FPGA with plenty of block RAM help here? In that case there will be no need for external DRAM with all of its issues of high pin count, complexity and slow (ish) clock speed.
I appreciate that such devices will come in BGA packages, but I know of a relatively low cost development board that features a Xilinx Kintex-7 device and I'd imagine that similar boards are available with Intel / Altera devices.

John

[ppppenguin]

I hadn't thought about FPGAs with enough memory for a framestore. A frame of video, 720x576, is 414720 pixels. For monochrome that would be the same number of bytes or 3317760 bits.

In theory it would help, but a FPGA with enough block RAM for a framestore may not come cheap. For example the largest Spartan 7 device (lowest cost range from Xilinx) you would need the largest in the series, the XC7S100:
https://www.xilinx.com/support/documenta...ide.pdf#S7

In the Artix 7 (next lowest cost) the XC7A75T would have enough BRAM. The Arty development board is available with the 7A100 device at $250: https://store.digilentinc.com/arty-a7-ar...hobbyists/

I haven't looked up similar for Altera. Which is the Kintex development board you're looking at? I though that Kintex and low cost were mutually exclusive.

[ppppenguin]

Obviously internal RAM is fast and it's also dual port but you still need to create multiple ports. If they are mutually synchronous, as they would be for 4 reads on different lines, the there is no need for a request/grant system at all. There is also no overhead for port switching so by running the BRAM at 4x pixel frequency (trivially easy) you can read all ports with ease.

The other trick with RAM to increase speed is word width. Read or write 2 or more pixels at a time. I have used up to 4x width, for example 32 bit RAM with 8 bit pixels.

On reflection, an Arty board (or Altera equivalent if available) with 7A100, would be a great development platform for this project.