Understanding SDI video data format

[BrianHG]

Also check the 'Clock & Data Recovery/Retiming'  SY87701.  The state by name support for the SMPTE SDI data rates, but I don't think it's as high quality as the analog devices ICs though it's function is identical, and it does not have a built in cable length equalizer amp.

https://www.microchip.com/wwwproducts/en/SY87701V#additional-features

[Yansi]

2) Oversample the input data by 4 (using a quadrature clock), which may also work, as per Xilinx XAPP224 and extract the data only (which is what can be done for multiple inputs, without dedicated PLLs). Bit more complicated, but no fiddling with PLLs.

If all you are worried about is 270mbit, 4x clock the input is doable.  Also, if you have multiple unused PLLs in the fpga, you can trick them into each running an SDI input even if they weren't designed for serial decoding.

Running a fixed 540mhz serial shift inputs, 2 in parallel per input, 1 on nclk and the other on pclk, basically a DDR ram input, will give you the equivilant to a 1080mhz clocking fpag even if the fpga max is only in the 540Mhz range.  You need additional logic to select which n or p input is currently in phase dynamically.

Also, the best solution, there exist generic deser clock recovery ICs which will take in SDI among many formats, output a CLK and 1,2, or 4 bits where you still need to deser the rest in the FPGA, but all the clocking PLL and really high speed signals are taken care of allowing you even higher speeds like 1.5gb and 3gb using only 2-5 FPGA inputs per SDI channel.  Same for HDMI, but the IP for that 1 costs big $.

The mentioned XAPP224 uses quadrature clock to obtain 4 sample points per bit. All clocks are equal to the bit rate, which is 270MHz, not 540MHz - that is unfortunately way out of range of a cheap FPGA such as the Cyclone IV E is. (I think the maximum theoretical limit is about 400MHz according to the databook, for the cheap C8 speed grade)

The FPGA I have only has two PLLs available. As far as I understand, each of the PLL has only up to 5 outputs.
I could probably use just one of the PLLs to produce 270MHz SDI clock, both polarities of the in-phase and both polarities of the 90° shifted clock. Hopefully...

Iknow about those external serdes ICs. But they are either hell obsolete, or cost utter bullshit, like 5times or more the price of the FPGA itself (I have already tried, there is alson the other SDI thread, where I have asked about this).  Also, I do not need 3gpbs serdes for 270mbps job. And 270mbps only serdes ICs are no longer made.


SY87701V is of no use for me. I need cable equalizer/receiver. Not a reclocker.  Also the price and availability is bullshit and none respectively. There are way better suited ICs from Microchip, such as EQCO30R5. Cost $4, does up to 3Gig. Decent availability from distributors.
Still, good ol' CLC014 is just $2 and fits the job fine.

I am still open to look for any replacement for the CLC014, so far nothing beats the EQCO30R5. But I am reluctant to use a 3gig part where it is not required.

[BrianHG]

2) Oversample the input data by 4 (using a quadrature clock), which may also work, as per Xilinx XAPP224 and extract the data only (which is what can be done for multiple inputs, without dedicated PLLs). Bit more complicated, but no fiddling with PLLs.

If all you are worried about is 270mbit, 4x clock the input is doable.  Also, if you have multiple unused PLLs in the fpga, you can trick them into each running an SDI input even if they weren't designed for serial decoding.

Running a fixed 540mhz serial shift inputs, 2 in parallel per input, 1 on nclk and the other on pclk, basically a DDR ram input, will give you the equivilant to a 1080mhz clocking fpag even if the fpga max is only in the 540Mhz range.  You need additional logic to select which n or p input is currently in phase dynamically.

Also, the best solution, there exist generic deser clock recovery ICs which will take in SDI among many formats, output a CLK and 1,2, or 4 bits where you still need to deser the rest in the FPGA, but all the clocking PLL and really high speed signals are taken care of allowing you even higher speeds like 1.5gb and 3gb using only 2-5 FPGA inputs per SDI channel.  Same for HDMI, but the IP for that 1 costs big $.

The mentioned XAPP224 uses quadrature clock to obtain 4 sample points per bit. All clocks are equal to the bit rate, which is 270MHz, not 540MHz - that is unfortunately way out of range of a cheap FPGA such as the Cyclone IV E is. (I think the maximum theoretical limit is about 400MHz according to the databook, for the cheap C8 speed grade)

The FPGA I have only has two PLLs available. As far as I understand, each of the PLL has only up to 5 outputs.
I could probably use just one of the PLLs to produce 270MHz SDI clock, both polarities of the in-phase and both polarities of the 90° shifted clock. Hopefully...

Iknow about those external serdes ICs. But they are either hell obsolete, or cost utter bullshit, like 5times or more the price of the FPGA itself (I have already tried, there is alson the other SDI thread, where I have asked about this).  Also, I do not need 3gpbs serdes for 270mbps job. And 270mbps only serdes ICs are no longer made.

How many inputs do you need?  I typically would have used 2 with 2 PLLs.  Feeding those 2 inputs, I would have an 8x2, 16x3 or 16x4 SDI crossbar switch IC which allowed 1 channel working while selecting an alternate channel, doing my clean swap, then using the alternate channel to select the next channel to swap to.  This means only 2 PLLs were required for PLL locking to a source input signal.

Also, 270mb is slow, it you want to play dirty, you could use 2 adjacent FPGA IOs with an inductor and 75v zener or tuning diode with resistor and cap to make a crude 270MHz or 135MHz PLL oscillator.  You would need to assign 'Fast output' and 'Fast input' registers for those IO with the serial input to keep consistent timing between compiler builds.  I must be fair here and say I've been successful at 54 Mhz 20 years ago and the first generation FPGAs.  270Mhz would be an exercise in experimentation, but you can have each SDI input utilize 3 FPGA IOs and have true dedicated PLL clocks for each one.

[Yansi]

For this learning toy project, I don't think I actually need more than 3 inputs (2x SDI in, 1x CVBS in).

I am starting to like quite some the idea described in the Xilinx XAPP224, oversampling the input with multiphase clock. Requires no input-dedicated PLL, apart from one to create a common system clock, used then to deserialize any number of inputs.

I will either way put one external loopfilter+VCO on the PCB. No dirty tricks with FPGA pins and inductors, MAX2607 is a cheap VCO and a pretty clean source too.  (<$1 from the "usual sources").

[Yansi]

Updated block diagram and a bit of first sketch how the board layout may look like. I like to think about it a lot before I start working on these. Power supplies will occupy the right hand side space on the board.

[BrianHG]

I will either way put one external loopfilter+VCO on the PCB. No dirty tricks with FPGA pins and inductors, MAX2607 is a cheap VCO and a pretty clean source too.  (<$1 from the "usual sources").

LOL, the MAX2607's block diagram is basically what you would have been creating...

[Ice-Tea]

TVP5150 does not seem obsolete: http://www.ti.com/lit/ds/symlink/tvp5150am1.pdf
Can be sourced from the usual sources from the east for less than $1, unlike the ADV7280, which costs more than I have payed for the FPGA.  But sure, the ADV7280 has 4 analog inputs and likely a better ADC, and can do YPbPr, which may be beneficial for some cases.

AFAIK, the AM version is a long-term availability version. Probably exactly the same but only available at much higher prices through regular sources. But if you don't mind going through chinese suppliers it doesn't really matter. Not my cup of tea though. I actually bought some chines 5150 modules and I could never get them to lock on the incoming signal.

[Yansi]

I will either way put one external loopfilter+VCO on the PCB. No dirty tricks with FPGA pins and inductors, MAX2607 is a cheap VCO and a pretty clean source too.  (<$1 from the "usual sources").

LOL, the MAX2607's block diagram is basically what you would have been creating...

Sure, it is called a VCO.     

TVP5150 does not seem obsolete: http://www.ti.com/lit/ds/symlink/tvp5150am1.pdf
Can be sourced from the usual sources from the east for less than $1, unlike the ADV7280, which costs more than I have payed for the FPGA.  But sure, the ADV7280 has 4 analog inputs and likely a better ADC, and can do YPbPr, which may be beneficial for some cases.

AFAIK, the AM version is a long-term availability version. Probably exactly the same but only available at much higher prices through regular sources. But if you don't mind going through chinese suppliers it doesn't really matter. Not my cup of tea though. I actually bought some chines 5150 modules and I could never get them to lock on the incoming signal.

Well, Chinese suppliers or not... as a low income hobbyist, there is not much choice. It is either the BOM being <$20 total, or becoming more than $200 otherwise.

Could not lock onto incoming signal...  huh.   TVP5150 ain't the simplest IC to work with from the software side. You sure it was correctly programmed?

I currently have no way to test the TVP5150 I got, but should not be difficult to do, to see at least the sync outputs toggling at the correct frequency.

In the end, even if I should buy TVP5150 from Mouser, it is still almost half the price of ADV7280. 

[Ice-Tea]

Could not lock onto incoming signal...  huh.   TVP5150 ain't the simplest IC to work with from the software side. You sure it was correctly programmed?

Off course not  I programmed it best I could, chose the easiest possible configuration and it would not lock. Problem with programming? Bad chinese chip? Who knows. Rather than to waste time on it (or rather to waste my clients money) I switched to an actual AD dev kit and got it up and running in no time.

[chris_leyson]

Used the TVP5150 and ADV7178 in a PAL to NTSC converter many years ago and never had any problems. Data in and out of the FPGA was 8-bit 4.2.2 YCbCr BT656. The only minor issue was the TVP5150 14.31818 MHz crystal being slightly off giving rise to some incorrect color encoding, a slight tweak to the crystal loading caps fixed the problem. TVP5150 is a nice chip and it's a shame it's not recomended for new design. EDIT: First iteration used the ADV7182 decoder, it didn't work and ran very hot, never found out why.

[Yansi]

Could not lock onto incoming signal...  huh.   TVP5150 ain't the simplest IC to work with from the software side. You sure it was correctly programmed?

Off course not  I programmed it best I could, chose the easiest possible configuration and it would not lock. Problem with programming? Bad chinese chip? Who knows. Rather than to waste time on it (or rather to waste my clients money) I switched to an actual AD dev kit and got it up and running in no time.

If you work for someone else's money, than it is a quite different story. But not the case here.

I'll probably make my own TVP5150 breakout board to see and test the chips I got.  At least I can test my software library and see if it works. 

[Yansi]

So for the giggles and what not, I have slapped together this small bastard to test a couple of the TVP5150 chips I got, whether I can make them lock onto video signal. I will have it manufactured somewhere in the January, with some other stuff.

As simple as it can get:



Now my lab is starting to lack a couple of things: A decent oscilloscope (500+ MHz BW), video signal (test pattern) generator and a BERT (I may just cobble one up later, PRBS generator would be a nice project to do with an FPGA). Seems some shopping may be ahead. Oscilloscope first, I am starting to hate the Hantek shite, and the old Agilent 3062A is good for watching the CVBS video at best. 

[Yansi]

Looksie what we got! Finally. (I made the mistake of ordering via snail mail). I am looking forward to trying this one out.

[Wiljan]

The board look's great 

Quite some years ago I got my hands on the Bitec Video Dev Kit cycloneIII 3C120 it did use the TVP5140 chip and it did work fine.

Here you can find the Bitec documentation and source files which might help you
https://bitec-dsp.com/product/cyclone-iii-video-development-kit/

[Scrts]

The mentioned XAPP224 uses quadrature clock to obtain 4 sample points per bit. All clocks are equal to the bit rate, which is 270MHz, not 540MHz - that is unfortunately way out of range of a cheap FPGA such as the Cyclone IV E is. (I think the maximum theoretical limit is about 400MHz according to the databook, for the cheap C8 speed grade)

I've used SDI received on Cyclone II (yes, that's 2), which used 337.5MHz clock with phase shift for bit decoding. It had some specific constrains, i.e. the sampling flip-flops had to be physically located next to the input pins. See Appendix A-8 here: https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_sdi.pdf
For clock generation, it was popular to use Genlock components from company Gennum, but I think they were later acquired by Semtech.

P.S. I worked on this 8-9 years ago... Might be crazy outdated.

[Yansi]

Well, even the Cyclone IV I'd like to use is crazy outdated, but I don't give a rats ass. As long as it is a cheap suitable alternative with good availability, I'll try. I just don't see a reason to justify the overpriced new devices.

I am not sure, but aren't those "megacore" functions only available for a subscription fee? Obviously, I'm a hobbyist in this case, not a corporate willing to pay nonsense.


Can anyone of the TVP5150 aficionados give a hint as what is needed as a minimum configuration of the TVP5150 to chew on some video input? It's been quite some time since I have studied the datasheet thoroughly and tried to understand it. I am looking forward to soldering the board today and start putting down some code for it.

Thank you

[Yansi]

Board soldered. I'll test it probably tomorrow, or in the near days.

[Yansi]

I'm an idiot.  FUuuuuuuuuuuuuuuuuuuu!!

I forgot to make a breakout for the IOVDD separately and incorrectly named the 1V8 bus as 3V3. Dammit! Fortunately a fix is simple enough.



(.. and exactly this is why I tend to test stuff part by part, block by block and only then I build complex circuits on a single PCB).

[Wiljan]

I am not sure, but aren't those "megacore" functions only available for a subscription fee? Obviously, I'm a hobbyist in this case, not a corporate willing to pay nonsense.

Yes that's correct, and the VIP (VideoIP) are very expensive, you can have a test license for 1 month but 1 time per PC.

Alternative is to buy a dev board with one of the bigger non "Free" Quartus supported devices from Altera / Intel, some of them have a 1 year full license with the VIP which are way cheaper than a normal license for a year.

[Yansi]

Okay, no change of game plan then. I will make my own set of IPs.

[Scrts]

I am not sure, but aren't those "megacore" functions only available for a subscription fee? Obviously, I'm a hobbyist in this case, not a corporate willing to pay nonsense.

Yes that's correct, and the VIP (VideoIP) are very expensive, you can have a test license for 1 month but 1 time per PC.

Alternative is to buy a dev board with one of the bigger non "Free" Quartus supported devices from Altera / Intel, some of them have a 1 year full license with the VIP which are way cheaper than a normal license for a year.

Fun fact: the SDI ancillary audio data extraction function on Altera core did not work correctly and support did not respond on that. I guess that core was made by some 3rd party and Altera support did not have details about it. I had two options: write my own core from scratch or decode/unlock/hack the existing one and fix the bug. The money was paid for the original code, so went with option #2 and succeeded. However, not recommended by any chance.

[Yansi]

Good news everyone, I have bodged the board so the chip gets a correct supply voltage of 1V8 and voila! After a bit of I2C wrestling, we have R.BT.656 data output, even with dedicated VS and HS signals at the correct timings.

The IC used in this experiment is one of a bunch I got from Aliexpress dirt cheap. (I mean like $1 a piece or less). They seem to be the TVP5150AM1 newer version, according to the marking.

Unfortunately, I do not have anything I could plug the video data directly into, that will have to wait for some other FPGA work. :-/

Here's the bodged pcb with added voltage regulator, for fun and giggles.

[Wiljan]

Nice you got the board running, but don't you have any FPGA board at all to play with?

Way back I had the BT656 to drive a small OLED board via a FPGA by just using some of the BRAM as timing buffer between input / output data

[Yansi]

I haven't touched FPGAs so far, so no boards available, just a bunch of unsoldered Cyclone IV in LQFP144 are laying here.

I have only worked with a few CPLDs in the past, simple stuff, I have only couple boards with Altera MAX II CPLD. But I don't think I could do much with such a CPLD regarding the video signal. Probably just try writing a state machine for decoding the SAV/EAV and extracting the H, V and F flags on some IO pins and probably ad something like a line counter.

I have ordered a development board with Cyclone IV E device from China, but due to the unfortunate situation in China now, the board will not probably arrive any time soon. I'd probably slap something together myself faster.

What I would currently like to work on, is to make a complementary PCB with a video DAC (encoder). Some of you may have already notice I have yet again spammed the forum asking for an BT.656 to CVBS encoder IC suggestion.

I will probably make a re-spin of the TVP5150 board to have the mistake fixed and will make some video encoder board, that can take the BT.656 data and spit out the PAL/NTSC CVBS back.  Probably will use something small and simple like ADV739x (datasheet).

Having a video ADC and DAC will be a good starting point, any of these two could be easily wired to any FPGA kit my hands will get onto.

[Yansi]

It seems I've been way too hyperactive last days. Here you have a board for the ADV7391 video encoder/DAC.

The layout is not what I am proud of, there are just too many compromises. But you can't expect a pretty layout on 2 layer board with a part designed for 4 layer boards (and 0402 or 0201 component size). Either way I don't think it is that bad it could not work, I think it will work well enough, sure at least with SD resolution output, which is what I will mostly be working with now.