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 did you do it?] |
projects:fibre-optic_video_transmission_for_aircraft_implementation [2013/12/17 23:32] 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. | ||
| 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.txt · Last modified: 2013/12/17 23:32 by steven
Page Tools
