28-06-2020, 02:09 PM
One of the things I wanted to do after moving to the new PCB was sync the output to the input at frame rate. It was difficult to do on the old set up on account of how the clocks were arranged.
As the old setup was not synced it would drop a frame every so often. This would not be noticed on a test card but on a moving picture it had a horrible effect of the picture been split horizontally. The split been where the frame is skipped. I found it incredible how far even slow moving objects travel in just one frame.
As the output clock is derived from the input clock it should be a simple job to sync them. I took a frame reset pulse from the input side put it through a 2 flipflop synchroniser and chose a suitable place on the output to sync to. It just took a couple of minutes to do.
But it could be easily seen it wasn't syncing properly as there was hooking at the top of the picture. The degree of hooking varied depending on the settings of front porch, sync, back porch, number of lines etc. At some settings it even appeared to sync properly.
The output clock is calculated as
Frequency in Hz = (front porch + sync + back porch + active line) * no. of lines * frame rate
Frequency in Hz is then multiplied by a coefficient. The result is used as the DTO coefficient.
I was suspicious of the coefficient that gets multiplied as it was of a relatively low number of bits and may be the cause of an inaccurate clock frequency.
I recalculated it to be sure it was correct and increased the number of bits but that made little if any difference.
To narrow things down I displayed the calculated frequency on the LCD and monitored the actual clock frequency and they tracked perfectly.
I then removed the frame sync and monitored the output side frame frequency. The frame frequency should remain constant but it wandered all over the place as the settings were changed even though the clock frequency was tracking correctly.
This would suggest that the problem lay with the counters in the FPGA.
But the counters are the same as what is used in all the Hedghogs and I never had a problem with them.
To get from clock frequency to frame frequency there are only 2 counters. The half line counter and the vertical counter.
It then dawned on me what was happening. As the half line counter reset value is got from (number of cycles in a full line / 2) if the number of cycles in a full line is odd the half line counter cant reset at the correct time so the line frequency will be off which in turn will put the frame frequency off.
The solution is to ensure that the number of cycles in a full line is even.
This I have done within the microcontroller. Before the clock frequency is sent to the FPGA. The full line value is checked to see if it is even. If it is not a cycle it added to or subtracted from the number of cycles in the sync pulse. This will then make the full line value even. A note is kept of whether a cycle has been added to or subtracted from so that the next time an adjustment is made the opposite can be done. This keeps the number of cycles in the sync hovering around the desired value.
Frank
As the old setup was not synced it would drop a frame every so often. This would not be noticed on a test card but on a moving picture it had a horrible effect of the picture been split horizontally. The split been where the frame is skipped. I found it incredible how far even slow moving objects travel in just one frame.
As the output clock is derived from the input clock it should be a simple job to sync them. I took a frame reset pulse from the input side put it through a 2 flipflop synchroniser and chose a suitable place on the output to sync to. It just took a couple of minutes to do.
But it could be easily seen it wasn't syncing properly as there was hooking at the top of the picture. The degree of hooking varied depending on the settings of front porch, sync, back porch, number of lines etc. At some settings it even appeared to sync properly.
The output clock is calculated as
Frequency in Hz = (front porch + sync + back porch + active line) * no. of lines * frame rate
Frequency in Hz is then multiplied by a coefficient. The result is used as the DTO coefficient.
I was suspicious of the coefficient that gets multiplied as it was of a relatively low number of bits and may be the cause of an inaccurate clock frequency.
I recalculated it to be sure it was correct and increased the number of bits but that made little if any difference.
To narrow things down I displayed the calculated frequency on the LCD and monitored the actual clock frequency and they tracked perfectly.
I then removed the frame sync and monitored the output side frame frequency. The frame frequency should remain constant but it wandered all over the place as the settings were changed even though the clock frequency was tracking correctly.
This would suggest that the problem lay with the counters in the FPGA.
But the counters are the same as what is used in all the Hedghogs and I never had a problem with them.
To get from clock frequency to frame frequency there are only 2 counters. The half line counter and the vertical counter.
It then dawned on me what was happening. As the half line counter reset value is got from (number of cycles in a full line / 2) if the number of cycles in a full line is odd the half line counter cant reset at the correct time so the line frequency will be off which in turn will put the frame frequency off.
The solution is to ensure that the number of cycles in a full line is even.
This I have done within the microcontroller. Before the clock frequency is sent to the FPGA. The full line value is checked to see if it is even. If it is not a cycle it added to or subtracted from the number of cycles in the sync pulse. This will then make the full line value even. A note is kept of whether a cycle has been added to or subtracted from so that the next time an adjustment is made the opposite can be done. This keeps the number of cycles in the sync hovering around the desired value.
Frank
