Electronics > FPGA
Book on SMPTE SDI Protocol?
jakubhladik1:
Hello,
I have to implement SDI Tx and Rx in an FPGA and reading the SMTPE specification proved to be difficult as I find myself in an endless loop of trying to get yet another referenced specification. The entire SDI specification set is like a LEGO kit, except the only way to purchase it is one LEGO brick at a time.
Is there any book that presents the SDI protocol in a comprehensive way? Or does the proprietary nature of this specification prohibit someone from writing a comprehensive book?
Someone:
There is a reason SDI IP is expensive, it's not easy! SDI is layers of complexity built up over decades forever wrapping the legacy/older parts which is why it is spread across so many different standards. Also the majority of possibilities covered in the standards is never seen/used in the real world. Complexity is high enough that it's unlikely a single person could build a widely compatible solution in less than years.
I have not come across any reference books on the subject.
dmills:
The basic SDI wire protocols are not that complex, and most of the FPGA vendors have IP blocks for handing the line side of things (Usually line to 20 bit parallel or such with clock recovery and at least some format detection).
There is a trap in that depending on the frame rate (Blame NTSC here) you usually need a serdes clock at either 148.5 or 148.35MHz depending on the rate being integer or 1000/1001, which is aggravating.
The devil is in all the stuff that you can stuff into the HANC and VANC time, that shit is just plain annoying and sprawled across dozens of standards most of which are never used (Or even supported) in practice.
On the physical layer watch the pathological conditions, the coupling caps need to be annoyingly large to make the thing work in the worst case low frequency condition. On a related nots, for SD at 270Mb/s you often have to oversample because the serdes block in the FPGA just does not go slow enough.
As far as documentation goes, I am not aware of a 'collected SDI standards' set, but some of the test gear vendors have very useful white papers on how bits of this work, as do some of the FPGA vendors as a side effect of their IP cores.
jakubhladik1:
--- Quote from: Someone on May 25, 2023, 11:19:14 pm ---There is a reason SDI IP is expensive, it's not easy! SDI is layers of complexity built up over decades forever wrapping the legacy/older parts which is why it is spread across so many different standards. Also the majority of possibilities covered in the standards is never seen/used in the real world. Complexity is high enough that it's unlikely a single person could build a widely compatible solution in less than years.
I have not come across any reference books on the subject.
--- End quote ---
Yes, I agree. 100% compatible solution would take a very long time and would require a ton of expensive and specialized test equipment. Luckily, I do not have to implement an IP that is compatible 100%. This is for avionics application where only a subset of the SDI spec is applicable.
--- Quote from: dmills on May 26, 2023, 09:52:24 am ---The basic SDI wire protocols are not that complex, and most of the FPGA vendors have IP blocks for handing the line side of things (Usually line to 20 bit parallel or such with clock recovery and at least some format detection).
--- End quote ---
Thank you. I noticed both Altera and Xilinx have a pretty good documentation of their IPs. I am working on the receiver first. I am using the vendor XCVR IP outputting raw data and then wrote custom code to the NRZI->NRZ and descrambling. I also finished a block for the TRS word alignment. Now I am stuck not knowing how to tell what format is being sent to know how to parse the pixel data into pixels. Based on the specs, it seems like the format data is carried in the ancillary data during blanking. I am looking into decoding ancillary data before writing an FSM to pull the pixel data out depending on the format.
--- Quote from: dmills on May 26, 2023, 09:52:24 am ---There is a trap in that depending on the frame rate (Blame NTSC here) you usually need a serdes clock at either 148.5 or 148.35MHz depending on the rate being integer or 1000/1001, which is aggravating.
--- End quote ---
On the Rx side, I can set the reference clock to the mid-point between the two and then the XCVR CDR's 1000ppm tolerance will cover both rates and still give me a little bit of margin. If Tx is required, there is no way around having two reference clocks, at least not with integer XCVR PLLs.
--- Quote from: dmills on May 26, 2023, 09:52:24 am ---The devil is in all the stuff that you can stuff into the HANC and VANC time, that shit is just plain annoying and sprawled across dozens of standards most of which are never used (Or even supported) in practice.
--- End quote ---
I have no idea what HANC and VANC time is. It will probably be a surprise as I try to understand the ancillary data side of the specification.
--- Quote from: dmills on May 26, 2023, 09:52:24 am ---On the physical layer watch the pathological conditions, the coupling caps need to be annoyingly large to make the thing work in the worst case low frequency condition. On a related nots, for SD at 270Mb/s you often have to oversample because the serdes block in the FPGA just does not go slow enough.
--- End quote ---
That was the first thing I wondered about when I saw SDI input schematic -- the 4.7 uF caps for AC coupling. I wondered why the well-known "rule of thumb" is being broken there and quickly learned the pathological signals are difficult to pass through something like 100 nF.
--- Quote from: dmills on May 26, 2023, 09:52:24 am ---As far as documentation goes, I am not aware of a 'collected SDI standards' set, but some of the test gear vendors have very useful white papers on how bits of this work, as do some of the FPGA vendors as a side effect of their IP cores.
--- End quote ---
FPGA vendor IP documentation has been a great source of comprehensive documentation on SDI so far. I will check out test gear vendors.
RichardS:
Google for xapp514. I don’t think it’s on Xilinx’s site anymore but there are copies out there.
Navigation
[0] Message Index
[#] Next page
Go to full version