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:18] steven |
projects:fibre-optic_video_transmission_for_aircraft_implementation [2013/12/17 23:32] (current) steven [TDOD list for the transmitter] |
||
---|---|---|---|
Line 1: | Line 1: | ||
- | By Steven Cooreman | ||
======= Fibre Optic Video Transmission for Aircraft: Implementation ======= | ======= Fibre Optic Video Transmission for Aircraft: Implementation ======= | ||
+ | By Steven Cooreman | ||
+ | |||
====== What did you do? ====== | ====== What did you do? ====== | ||
I made a blazing fast video signal converter in VHDL. | I made a blazing fast video signal converter in VHDL. | ||
Line 24: | 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 41: | 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 58: | 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. |