14-05-2019, 03:41 PM
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.
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.
www.borinsky.co.uk Jeffrey Borinsky www.becg.tv
