Building a Standards Converter

[Jac Janssen]

Thanks Frank,

At the moment I have it at 563 and that works fine, so I'll just leave it as it is for now. I'll experiment later with it, once I've got the rest up and running.
Worth investigating further at a later stage though.

Jac

[`FRANK.C]

Hi Jac
I think that 563 is about right. I cant think of any reason to change it.

Frank

[ppppenguin]

This part of a design is often a bit tricky. Deciding on exact vertical timings, on when to start refilling buffer memory, ensuring that there isn't any "dead" data left in the memory.

My gut feeling is that reading the time redistribution (TR) memory can be done continuously. Though I could be wrong. Some of the data during the vertical blanking interval (VBI) will be rubbish but that can be blanked.

TR memory can actually be done in various ways. You can have a single dual port memory, several lines long, with read and write pointers which you manage in your own logic. The pointers must never pass each other, except possibly in VBI.

Or you can run it as a FIFO. You must never allow the FIFO to run full or empty. Again possibly except during VBI. I reckon this is more of a hassle than manging your own pointers.

Both of the above have the possible disadvantage of storing whole lines, including H blanking interval, unless you have some clever logic. You probably also need H sync markers stored. A reserved value such as 00 or FF would work, provided the video is limited to ensure the value can't occur elsewhere.

Or you can have multiple memories (minimum 3 for this application) each of which is either being written, read or idle. This is how the BBC CO6/509 digital 625>405 converter works. Since the memories in the FPGA are true dual port and fully addressable (those in the CO6/509 are not) you might get away with only 2 lines.

If anyone is thinking of trying 819 line output, you'll find that the TR has to be done before the interpolator. For down conversion the interpolator comes before TR.

In my experimental fieldstore converter all of these problems go away. I configure the fieldstore so it looks like it can be written at one address and read from up to 4 addresses simultaneously. There is no TR memory as such, the interpolator simply selects the lines it needs (up to 4) and reads them.

Since the output iof my framestore converter is not sync'ed to the input in any way a field will be dropped or repeated every now and then. Not normally noticeable. There is the possibility of the read and write field pusles being very close in time, causing frequent drops and repeats. This requires hysteresis in the way the read and write pointers can pass each other. In my design this is inherent in the way the fieldstore is managed.

[`FRANK.C]

Just to explain where Hedghog fits into the various ways TR memory can be done, that Jeffrey has outlined.

Hedghog uses a FIFO for TR memory. A FIFO was chosen simply because it was easy to implement using the Quartus tools.
It is 8 bits X 4096 words. (Hedghog II will use 9 bits X 4096 words)

Just the active part of each line is stored. When aspect ratio conversion is done the line is cropped before being wrote to the TR memory. It is cropped over sized to allow for tweaking to be done on the 405 side to centre it. The unused portion of the over sized lines lies in the H blanking period so wont be seen.
The SAV(Start of Active Video) signal in the embedded syncs is used to reset the counter that determines the length of each stored line.
There are no H sync markers stored, hence the need for only to read or write full lines.

Frank.

[`FRANK.C]

I have finalised Hedghog II. I have made some small changed from the last version.  The Quartus tools were whinging because I was not using a dedicated PLL output pin for the 14.31818 clock and because of that, the jitter on that clock may be increased. To be honest I think it was fine as it was but to be sure I have now used the dedicated pin.
To facilitate that I had to move the 50 MHz clock to the opposite side of the FPGA so I could use the PLL input pins on that side. With the PLL input pins that I was using the design would not fit in the FPGA. I have changed the position of the 5V reg and also slightly changed the position of the video out socket to give a little more clearance from the F connector.
When I have the files required to build it uploaded to my website. I will post a link here.

Frank

[Jac Janssen]

Fantastic work Frank!

Jac

[`FRANK.C]

Thanks Jac

[`FRANK.C]

I have uploaded the files for Hedghog II they can be found here.
Any errors please let me know.

Frank.

[Freya]

It may be worth Starting a new topic for the Hedghog II, easier to find for newbies rather than trawling though 349 posts.

[Terry]

Excellent idea - with a link from this thread to the new one for continuity.