Hi Jeffrey
Thanks for the file it will prove invaluable should I decide to change the video decoder.
The TVP5146 is overkill and I would suspect the TVP5150 is easier managed with regard to power supplies etc. The TVP5146 performance is glitchy even though I copied the circuit in the data sheet with all the required decoupling capacitors. I expect it is probably down to circuit layout (some of the traces to the cap's are a bit long) and the fact that I don’t have the PowerPAD connected to ground. I didn’t know how to but have seen how it is done on the FPGA board so will know for again
Frank
I've probably got some small PCBs with Philips SAA7118 decoders on them. They plug into the now old fashioned 72 pin memory SIMM sockets. I designed them for a client years ago and used one as the input on my own standards converter.
Photo of my converter attached. The analogue input module is the leftmost but you can't see much of it.
If I have some spares you are welcome to one for the cost of postage.
Hi Jeffrey
That’s an impressive converter it looks very complex.
Its likely, that down the line I will do up a new PCB, if so I will probably try a different decoder chip, either the TVP5150 or a ADV7280. The TVP5150 requires an external anti aliasing filter on the input, where the ADV7280 has it on chip, but the TVP5150 has separate FID, VSYNC, VBLK and AVID, which the ADV7280 has not.
If that don’t work out I may take you up on your kind offer if you have one available.
Frank
Don't worry about separate pulse outputs. Just use a digital sync separator like I did. The 5150 only needs a minimal anti alias filter.
Just an update of progress.
I have move the 405 sync generation from the microcontroller to the FPGA. I also noticed that the write sequence wasn't resetting correctly and have corrected that.
For 405 4:3 out I have chosen a frequency of 8.91 MHz which gives 880 pixels per full line. It will sync with 625 and the PLL can produce it from a 13.5 MHz clock.
One fly in the ointment is the PLL's in the FPGA will only work from a dedicated clock pin and no clock pin is available on the headers on the development board. The only way around this was to remove the 50 MHz oscillator on the board and use it's pad that connects to the clock pin, which I have done and I am now getting the 8.91 MHz 405 clock from the PLL. When I first tried it the output was very poor, very jittery with line tearing. The 13.5 MHz clock from the video decoder was getting corrupted, probably through the wire that I have used to connect it to the pad. Placing a 10 pf cap between it and ground has cured it though.
I have used the two FF method the Jeffrey described to sync the 405 to 625 and it works well. There was no need to do that but it was good to try in case I need it in the future.
Ive been working out what clock to use for 5:4 video. With 720 pixels been used for 4:3 I reckon that 675 pixels would be right for 5:4. 720/1.33*1.25=675.
8.353125 MHz works out well. The PLL can produce it simultaneously with the 8.91 MHz clock and it will sync with 625. The active line length is 80.81 uS which is the same as 720 pixels at 8.91 MHz.
There is an uneven number of pixels in a full line so it will need to be clocked at twice pixel frequency in order to produce the half lines, which is not a problem as the PLL can do that.
Progress will be slow and sporadic over the summer months but I will update as things progress.
Frank
Very annoying that the PLLs can only be driven from a clock pin. In XIlinx parts they can be driven from anywhere. I assume you've carefully checked the Altera data on this point.
Hi Jeffrey
I hooked up the PLL to a IO pin which gave a error message, I then looked up the instructions
.
They claim that by using only the dedicated clock pins it keeps jitter to a minimum. The only other thing that the PLL can be driven from is another PLL.
I tried googling it as well but I couldn't find anything hat helped.
I guess every chip family has it's quirks.
If there was just one of the seven clock pins on the header it would have helped a lot. There is another development board for the EP4CE10F17C8N FPGA and it don't appear to have any clock pins on it's headers either.
Frank
All FPGAs have their little quirks and annoyances. They usually come and bite you when you're least expecting them. For Xilinx Spartan 3 series the quirks have mainly been in clock distribution, not helped by the tools sometimes making strange decisions on how to allocate the global and regional clock buffers. However some things are unexpectedly trouble free. I thought I'd have hell to pay when I made a 49.152MHz clock from 148.5MHz. Why 49.152MHz? It's a convenient multiple (1024) of the 48kHz AES audio sampling frequency. Allows me enough clock cycles (32) per audio bit to do all the processing while being low enough to be like DC for the FPGA. 98.304MHz would have been a bit fast for convenience while 24.576MHz would have been marginal for doing all the processing.
148.5MHz was the main crystal oscillator, it's the pixel clock for 1080/50p etc HDTV. The Xilinx Spartan 3A PLLS can do a maximum of 32 on both numerator and denominator. So going to 54MHz for standard definition related stuff is no problem, it's just 4/11. Getting from there to 49.152MHz takes 3 steps.
Multiply by 32/9 to get 192MHz
Divide by 5 to 38.4MHz (ordinary logic for once, no PLL)
Multiply by 32/25.
I couldn't find a simpler way, even if I started from 148.5MHz rather than 54MHz.
All worked immaculately at first attempt. Including nice low jitter. Been an utterly trouble free part of the design.
I decided to tackle the 5:4 output next. I use the Active video signal from the video decoder to operate the write enable of the FIFO's. For 4:3 it is high for 720 pixels duration. The start and stop of the Active video signal can be programed pixel by pixel, by the I2c bus. For 5:4 output the start is moved later by 22 pixels and the stop moved earlier by 23 pixels giving a active line length of 675 pixels.
As the video decoder would be programed each time the aspect ratio was changed now seemed a good time to move the I2c master from the microcontroller to the FPGA. The microcontroller would then be redundant as this is the only function it is doing.
I cobbled together a bit banger for the FPGA but there was no activity at all from it, after a bit of head scratching I found the reason. The only clock source I have is the 27/ 13.5 MHz from the Video decoder but inconveniently at start up, by default there is no clock output, it has to be switched on by the I2c bus. So for now I have left in place the microcontroller to provide a clock for I2c master.
The first photo is of the 4:3 output and the second is of 5:4 output without changing any controls on the TV.
Frank
(17-04-2017, 10:13 AM)`FRANK.C Wrote: [ -> ]I cobbled together a bit banger for the FPGA but there was no activity at all from it, after a bit of head scratching I found the reason. The only clock source I have is the 27/ 13.5 MHz from the Video decoder but inconveniently at start up, by default there is no clock output, it has to be switched on by the I2c bus.
Sawing off the branch you're sitting on
I've got something a bit like that in one of my designs. I have to provide a temprary clock to the control logic during startup until the correct clock is available and the software in the microcontroller operates a changeover switch int he FPGA. It would be entirely possible for the software to sabotage the FPGA to the point of it needing a reboot.
Well done for getting the 5:4 working.