projects:fibre-optic_video_transmission_for_aircraft_implementation
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
projects:fibre-optic_video_transmission_for_aircraft_implementation [2013/12/17 23:16] steven [How can others build on it?] |
projects:fibre-optic_video_transmission_for_aircraft_implementation [2013/12/17 23:32] (current) steven [TDOD list for the transmitter] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| + | |||
| + | ======= Fibre Optic Video Transmission for Aircraft: Implementation ======= | ||
| By Steven Cooreman | By Steven Cooreman | ||
| Line 10: | Line 12: | ||
| ====== Why did you do it? ====== | ====== Why did you do it? ====== | ||
| I had a couple of different options when I was looking for a thesis subject. What made me choose this one were a couple of different reasons: | I had a couple of different options when I was looking for a thesis subject. What made me choose this one were a couple of different reasons: | ||
| - | * I actually wanted to be an aerospace engineer first. This combines my passion for electronics with a link to the aircraft industry | + | * I actually wanted to be an aerospace engineer first. This combines my passion for electronics with a link to the aircraft industry |
| - | * I get to both design hardware (already happened over summer) and write logic (happening now) in the same project, which is an awesome way to taste and gain experience in the relevant subjects. | + | * I get to both design hardware (already happened over summer) and write logic (happening now) in the same project, which is an awesome way to taste and gain experience in the relevant subjects. |
| - | * I get to solve an actual engineering challenge for a project that already has a deadline because it has been put on the roadmap. It is admittedly freaking me out a bit, but it also introduces the reality of being an engineer: deadlines are often outside your control. Make it happen. | + | * I get to solve an actual engineering challenge for a project that already has a deadline because it has been put on the roadmap. It is admittedly freaking me out a bit, but it also introduces the reality of being an engineer: deadlines are often outside your control. Make it happen. |
| ====== How did you do it? ====== | ====== How did you do it? ====== | ||
| Line 23: | Line 25: | ||
| I did have the advantage that the analog video signal would be converted to a digital one outside of the FPGA, so I did not have to implement any ADC conversion. | I did have the advantage that the analog video signal would be converted to a digital one outside of the FPGA, so I did not have to implement any ADC conversion. | ||
| - | Another part of the diagram was the timing checker. This module is intended to check the timing of the incoming video, and see whether it matches up with a supported resolution by measuring the horizontal and vertical line periods at the reference clock. If the resolution matches up, it indicates to the Finite State Machine that video is ready to be sent out. It also provides a pulse that indicates the start of a new frame, so that the packetizer can sync up to the incoming signal’s refresh rate. | + | Another part of the diagram was the timing checker. This module is intended to check the timing of the incoming video, and see whether it matches up with a supported resolution by measuring the horizontal and vertical line periods at the reference clock. If the resolution matches up, it indicates to the Finite State Machine that video is ready to be sent out. It also provides a pulse that indicates the start of a new frame, so that the packetizer can sync up to the incoming signal’s refresh rate. {{:projects:spec_timing.docx|}} |
| Then comes the clocking. The whole thing runs off of a 106.25 MHz oscillator, because it is an integer fractional of the prospective 2.125 GHz, and so we can generate the transmit clock with a phase-locked loop. It also provides an opportunity to run our packetizer at exactly the right frequency for the transmission: we have to provide the transmitter 32 bytes for every 40 bytes sent, so the data needs to be clocked in 32 bytes at a time at 2.125 GHz / 40 = 53.125 MHz: exactly half of the reference clock. | Then comes the clocking. The whole thing runs off of a 106.25 MHz oscillator, because it is an integer fractional of the prospective 2.125 GHz, and so we can generate the transmit clock with a phase-locked loop. It also provides an opportunity to run our packetizer at exactly the right frequency for the transmission: we have to provide the transmitter 32 bytes for every 40 bytes sent, so the data needs to be clocked in 32 bytes at a time at 2.125 GHz / 40 = 53.125 MHz: exactly half of the reference clock. | ||
| This 32 bytes per 40 sent is a direct result of the encoding applied at the link level: 8b/10b encoding, 4 times in parallel. This type of encoding provides for a couple of benefits: | This 32 bytes per 40 sent is a direct result of the encoding applied at the link level: 8b/10b encoding, 4 times in parallel. This type of encoding provides for a couple of benefits: | ||
| - | * Near-constant Running Disparity: this will ensure that at any given time, the total amount of 1’s and 0’s sent over the link will only be off by one. This is very important with conductor-based transmissions, to keep the average (reference) voltage on the link equal. However, it also ensures that the clock can always be recovered from the link, something that is also important with fiber optics. | + | * Near-constant Running Disparity: this will ensure that at any given time, the total amount of 1’s and 0’s sent over the link will only be off by one. This is very important with conductor-based transmissions, to keep the average (reference) voltage on the link equal. However, it also ensures that the clock can always be recovered from the link, something that is also important with fiber optics. |
| - | * Basic error detection: because you introduce two extra bits per 8 data bits, and use one for the disparity, the other one will provide a rudimentary type of error checking: one of the states is legal, the other one is not. Simple as that. | + | * Basic error detection: because you introduce two extra bits per 8 data bits, and use one for the disparity, the other one will provide a rudimentary type of error checking: one of the states is legal, the other one is not. Simple as that. |
| - | * Introducing control codes: because every 8 bits have multiple possibilities to be converted to 10 bits, you can use one of them for your code, and another one to indicate a ‘special’ character. Very useful if you want to delimit random data that can take on any of the 256 values, and still want to be able to send control signals without first saying how many data bytes you are going to send, and have the receiving system count them out, as this is very error-prone. | + | * Introducing control codes: because every 8 bits have multiple possibilities to be converted to 10 bits, you can use one of them for your code, and another one to indicate a ‘special’ character. Very useful if you want to delimit random data that can take on any of the 256 values, and still want to be able to send control signals without first saying how many data bytes you are going to send, and have the receiving system count them out, as this is very error-prone. |
| Lastly, the state machine takes care of the generation of the packets. On reset, it will wait for the ‘valid’ signal to become true, indicating that valid video is being received. When valid video is present, it will wait until the start of a frame, reset (clear) the FIFO, wait a specified amount of time, and then transmit an “Object 0”. In ARINC818 terms, this is the start-of-frame object, which contains a couple of parameters relevant to the link status, video properties, number of the incoming frame, etc. | Lastly, the state machine takes care of the generation of the packets. On reset, it will wait for the ‘valid’ signal to become true, indicating that valid video is being received. When valid video is present, it will wait until the start of a frame, reset (clear) the FIFO, wait a specified amount of time, and then transmit an “Object 0”. In ARINC818 terms, this is the start-of-frame object, which contains a couple of parameters relevant to the link status, video properties, number of the incoming frame, etc. | ||
| Line 40: | Line 42: | ||
| While this is still a work-in-progress by me, and I plan to continue working on this, another person would need the following: | While this is still a work-in-progress by me, and I plan to continue working on this, another person would need the following: | ||
| * A copy of the ARINC818 spec, available from the organization for a fee. An implementers guide is available upon request at http://www.arinc818.com/arinc-818-library.html | * A copy of the ARINC818 spec, available from the organization for a fee. An implementers guide is available upon request at http://www.arinc818.com/arinc-818-library.html | ||
| - | * A copy of the implementation-specific ICD (example enclosed) | + | * A copy of the implementation-specific ICD (example enclosed){{:projects:advb_ref_icd_xga_24rgb_60h_2g_p_lsync.pdf|}} |
| * The necessary hardware (I designed a board with a Xilinx Kintex-7 FPGA specifically for this) | * The necessary hardware (I designed a board with a Xilinx Kintex-7 FPGA specifically for this) | ||
| * Xilinx ISE tools with IPCores, and simulation libraries for the FPGA. I used Xilinx ISE version 13.1. | * Xilinx ISE tools with IPCores, and simulation libraries for the FPGA. I used Xilinx ISE version 13.1. | ||
| Line 57: | Line 59: | ||
| - Simulate tb_ARINC818 | - Simulate tb_ARINC818 | ||
| - | ==== TDOD list for the transmitter ==== | + | ==== TODO list for the transmitter ==== |
| * Implement the actual CRC calculation. Constant ‘C0FFEE11’ just doesn’t cut it. | * Implement the actual CRC calculation. Constant ‘C0FFEE11’ just doesn’t cut it. | ||
| * Investigate a better timing simulation model. Currently, Modelsim only accepts integer nanosecond periods, and my clocks are respectively 65MHz (incoming) and 53.125MHz (reference). These don’t map, and thus the rounding of the period means my simulation is not accurate. | * Investigate a better timing simulation model. Currently, Modelsim only accepts integer nanosecond periods, and my clocks are respectively 65MHz (incoming) and 53.125MHz (reference). These don’t map, and thus the rounding of the period means my simulation is not accurate. | ||
projects/fibre-optic_video_transmission_for_aircraft_implementation.1387340164.txt.gz · Last modified: 2013/12/17 23:16 by steven
Page Tools
