senior design technical paper.docxedge.rit.edu/content/p14571/public/msd ii/seniordesignt… ·...

Multidisciplinary Senior Design ConferenceKate Gleason College of Engineering

Rochester Institute of TechnologyRochester, New York 14623

Project Number: P14571

Ruggedized Camera EncoderMatthew Hornyak

Mechanical EngineeringAlonso Moreno

Mechanical Engineering

Lennard StreatComputer Engineering

Jordan O’ConnorElectrical Engineering

Kyle E. JasonElectrical Engineering

AbstractThe objective of project P14571 was to plan, design, and implement a Ruggedized Camera

Encoder module for the embedded systems design company D3 Engineering. The Ruggedized Camera Encoder is a robust system that collects and analyzes a stream of high-speed camera data in real-time. A ruggedized enclosure is intended to be used in military applications and in other extreme environments. The original project goal was to create a complete prototype using the latest System on Chip Field-Programmable Gate Array (SoC FPGA) technologies to operate with D3 Engineering’s proprietary CoaXpress (CXP) camera, which is capable of sending HD video at high transmission speeds. The project consisted of mechanical, electrical and software sections, each working through the phases of system design to subsystem design and finally to a detailed design. Due to the scope of the project and other limitations, the deliverable was reduced to a ruggedized case surrounding a SoC FPGA development kit 1

capable of simply streaming image frames from the CXP camera. The end result of the project provides a finalized design for a ruggedized housing for the system, a CXP High Speed Mezzanine Connector (HSMC) printed circuit board daughter card to directly link to the CXP camera, and FPGA base system architecture to implement future development in streaming frames and real-time image processing.

NomenclatureCXP - CoaXPress: a protocol for transmitting high speed data over a coaxial cable.

1 "Cyclone V SoC Development Board Reference ... - Altera." 2013. 6 Dec. 2014 <http://www.altera.com/literature/manual/rm_cv_soc_dev_board.pdf>


FPGA - Field Programmable Gate Array: a programmable chip programmed with a hardware description language.SoC - System on Chip: a reference to the ARM processor embedded in the FPGA.HSMC - High Speed Mezzanine Connector: A standard connector for transmitting large datasets at high speeds.XCVR - High-speed Transceiver

IntroductionReal-time high performance image processing plays an integral role in analytics applications.

Typical applications for real-time image processing require that the hardware subsystem be capable of withstanding specific environmental parameters such as humidity, temperature, shock and impact. Due to cost limitations, many systems are specialized for these applications and take all the environmental parameters into consideration. Many such systems that meet these challenges exist, but not for the CoaXPress protocol.

This project is a reiteration of a previous project, sponsored by D3 Engineering. Project P13571 was an effort to design a ruggedized camera module. The final system was capable of processing a stream of camera data and applying histogram equalization to it. In theory the design is extensible to other more advanced applications.

Design ProcessThe design process for this project was initiated by establishing the customer requirements. The

main customer requirements for this project were: 1) it had to be ruggedized; 2) had to process 1080p at 30fps raw image data; 3) had to use the CXP communication protocol, had to be “tabletop” size; 4) had to use an FPGA to complete image processing; 5) had to connect to a pre-designed D3 board; 6) and had to be able to store processed image data in SATA drives. Once these customer requirements were established, next step was to extrapolate engineering requirements from them. For example, the customer requirement of “being ruggedized” was transformed into multiple specifications such as; the system must meet the IP67 standard, must be able to withstand temperatures from -45ºF to 140ºF, and the system must be able to handle a force of 2000N. Another example of an engineering requirement was “FPGA transceiver speed must exceed 0.746Gbps to accomplish a continuous stream of 1080p 30fps processed image data.”

Once all the engineering requirements were written the next step was to decompose the entire system to understand what each subsystem had to accomplish. Once the system was understood the next objective was to brainstorm system concepts and then to choose one of the generated concepts. The concept selection was a lengthy process involving a variety of trade analyses, feasibility analyses, mechanical drawings, and risk assessments. After a few iterations a final system concept was chosen and then broken up into smaller subsystems. In this particular case the subsystems were broken down to a three main subsystems which are mechanical subsystem, electrical subsystem, and software subsystem.

Electrical Design ProcessThe electrical system design was broken up into two smaller subsystems. The first subsystem was

the custom FPGA board which would complete all of the image processing and route the processed data to the desired location. The second subsystem was the development and creation of the CXP board. The purpose of this board is to take in the CXP 1080p feeds from each camera and then send the raw image data over the HSMC connector to the FPGA.


FPGA Board Design ProcessThe first step of the electrical design process for the FPGA board was to perform a trade analysis

to explore and compare the FPGA’s available. For this benchmarking task the top five FPGA manufactures were examined and all the models and specs were compared in a spreadsheet. A major factor in the decision of the FPGA was if the FPGA had high speed transceivers and if so, the speed of the transceivers. Equations 1-3 below show the calculations needed to find the minimum transceiver speed to accept the raw image data of one single camera feed.

High Definition1080 p=1920∗1080=2.0736 Million pixels per frame (1)

1080 p @ 30 frames per second=2.0736∗106∗30 fps=62.208 Million pixels per second (2)

If each pixel is12 bits , total bits=62.208∗1 06∗12=0.746Gigabits per seconds (3)

These calculations showed that in order to accept four camera feeds the transceivers needed to handle a total of approximately 3Gbps. The result of this trade study came down to two choices which were Altera’s Cyclone V and Xilinx’s Spartan 6 as shown in Figure 1.

Figure—1: Altera Cyclone V and Xilinx Spartan 6 FPGA comparison

When the cost and availability were taken into account the final choice was the Cyclone V. Once the FPGA was chosen some other benchmarking was conducted to choose the SATA drives needed for storage. During this time support was also given to the mechanical engineers for the benchmarking of the external connectors.

After all of the major components were selected and approved the next step was to start picking all of the important board-level components. These board-level components were the devices that were needed to support the FPGA such as the SDRAM and transceiver PHY, as well as the connectors used for bringing signals in and out of the board, such as the HSMC connector, USB, HDMI, and Ethernet. Another important task during this time was to complete the power design. This included creating a power tree to show what components need what voltage and current and then to choose the regulators that could disperse this power. Once these components were selected the next step was to do an initial placement of all the parts to make sure they would fit on the board. This was completed as a Visio block


diagram and after approval, could be used as a rough outline for the schematics.

The purpose of the schematics are to create the entire structure of the board and to show how all the components are connected. The beginning step of the schematic design process was to use the initial placement diagram to lay out all the major components. Once all the major component blocks were placed in the schematic, the bulk or the work came from doing all of the fine detail connections. During the creation of the schematics every so often a design review was held so other engineers could review the schematics to make sure everything was connected properly and according to the specifications. The design and creation of the schematic took weeks and even after many hours of work, the fully finished schematics were never achieved and were forced to the back burner so software development could begin. Had the schematics been finished the next step would have been to do the PCB design. The layout for this particular board is very difficult and would have needed a senior engineer to complete it so it was out of the scope for this project since the beginning of the senior design I.

CoaXPress SubsystemThe objective of this section is to provide an overview of the major components within the CXP

HSMC subsystem. High-level descriptions of each subsystem and subcomponent are provided in this section. The complete CXP-HSMC interface (from high-speed camera to processing circuitry) is depicted in Figure—2.

Figure—2: The architectural overview of the CoaXPress HSMC card and it’s connectivity with an external CXP-6-compliant device.

The complete equalization system functions as follows. The host system ( that utilizes the CXP HSMC) transmits configuration commands to the camera via the low frequency uplink (LFI—a 1.2V LVTTL signal, which is then stepped up to 2.5V using a series resistor) at a rate of approximately 21Mbs. Through the aid of filtering capacitors and inductors, data and power are transmitted in a bidirectional fashion simultaneously to and from the camera peripheral. The received camera data is acquired on the SDIp

and SDIn input lines. The equalizer core handles the conversion from the low-voltage differential input and then transmits that data back out through the SDOp and SDOn pins.

Mechanical Design ProcessIn order to come up with different design ideas for a rugged enclosure, the customer requirements

were first analyzed and changed into engineering requirements. The primary requirement was the enclosure being rugged enough to function in a multitude of different environments. In order to head start the design process, benchmarking different materials was necessary in order to choose one that would withstand long-term operation in harsh environments. The mechanical design team decided on AL-6061 due to its high tensile yield strength, 40,000 psi, and ability to dissipate heat, 1160 BTU*in/hr*ft2*°F [1].


One of the first issues the mechanical design team ran into was not knowing the placement of the

processors on D3’s DesignCore board and the FPGA board that was being designed by the electrical team. Without this information, it was difficult to determine where the majority of the heat within the enclosure was being produced from, but it did also give some leeway on the design. The first iteration of the design consisted of two hard-drives side by side under the two boards with the HSMC card at the top. One of the first issues with this design was the fact the hard drives would come out of the side of the enclosure creating a bigger opening. Secondly, the orientation of the hard-drives, boards and the HSMC card made the design bulky and would be non-compliant with the customer requirement of making this system easily mountable. Another issue with the original design was the use of MIL-STD connectors which also contributed to the issue of bulkiness.

The second iteration of the enclosure the mechanical team had a better idea how much heat was being produced by the FPGA and the boards, which made placement of certain parts easier. The team was also more conscious of placement of the hard-drives and a sheet metal tray to help dissipate heat and mount the boards. One of the major improvements from the initial design to the second design was the use of the StarTech 2 Drive tray, which houses two 2.5” hard-drives stacked one on top of the other in an aluminum enclosure which also helps dissipate heat. This reduced the amount of space two hard-drives side by side would take and fit it all into the size of one 3.5” hard-drive. The second major improvement of the second design iteration was the rugged connectors used. Another major customer requirement was the enclosure being watertight which the team translated into an engineering requirement of being IP67 compliant. In order to be in compliance with the IP67 standard the enclosure must be totally protected against dust ingress and must be able to withstand being immersed in water for short periods of time.

Finding connectors to meet this IP67 compliance proved to be more of a challenge than anticipated. For starters, the external connectors which needed to be at the minimum IP67 compliant were the RJ-45, power, USB, and BNC connector. Any other connectors used would be internal to the system and protected by the enclosure. Besides just being waterproof another concern with the connectors was their operating temperature. The enclosure is to be totally sealed which only further complicates dissipating heat and making sure any internals are not damaged. Due to this fact, the connectors must be able to withstand a temperature of 85°C. The connectors chosen can be seen in the table below, these connectors were chosen based off the drawings or data sheets provided by manufacturer. All connectors meet the operation temperature specification and they are at a minimum IP67 compliant.

# Supplier Part No. Qty. Price per Unit Total Part1 Digi-Key2 EGW.LM.U2A.XPL 1 184.57 184.57 USB2 Digi-Key RJFTV2PE1N 1 72.75 72.75 RJ453 Digi-Key 034-1030 4 8.16 32.64 BNC4 Digi-Key PCL712A 1 5.19 5.19 Power

Table—1: Connector Selection Breakdown

The final iteration of the mechanical enclosure was based on the desire of the customer to produce an enclosure that could easily be extruded as opposed to being machined. This drastically changed the design of the outside of the enclosure as well as, the sheet metal tray used to house the boards. The fins originally included in the design had to be removed due to the fact the enclosure was not

2 "DigiKey Electronics - Electronic Components Distributor." 6 Dec. 2014 <http://www.digikey.com/>


thick enough to have this geometry machined and no extrusion with fins was found to be big enough to house the system. The second major change was the placement of the sheet metal tray. Originally channels on the inside of the casing along with wedge-loks were to hold the sheet metal tray in place. With the use of an extrusion these channels could no longer be machined. As an alternative the sheet metal tray was redesigned to attach to the hard-drive tray as well as attach to the end plate with the connectors. This would allow for the entire system to just slide into the casing and then be sealed off.

Software Design ProcessThe software portion of this project has several different parts. The final goal is having all of

them working together to integrate the FPGA and the SoC so that the system can dynamically adjust certain characteristics of the FPGA’s I/O interactions, data storage and data manipulations. The SoC FPGA was chosen because it is a customer requirement due to familiarity and scalability. This led to the specified software languages and frameworks that will be used individually, and cooperatively on the FPGA and the SoC ARM processor.

The FPGA (Altera Cyclone V3) handles I/O interactions with the CXP camera, and also handles storage of the acquired frames into the local memory. It requires programming with the hardware description language Verilog, which programs information and data paths along with the logic needed to receive, parse and organize data. The SoC is designed to work in harmony with the FPGA. While running Linux, it is able to execute register editing scripts to allow for system automation without the need for flashing a new system architecture on the FPGA. Altera provides design suites for programming the FPGA (Quartus II4), and integrating the SoC to the FPGA (Qsys5). Altera also provides an embedded design suite, which is used to program the SoC ARM processor to boot into Linux from SD card storage. It also provides a debugging mechanism to analyze the operations and data flow as it is happening.

There are three main components to successfully capturing an image and displaying it. There is a component that is always polling the camera for new frames, a component that decodes the raw frames from the camera and stores them into local memory, and a final component that pulls the reconstructed and decoded frames from the local memory to be displayed over HDMI. The data flow is constructed this way, as can be seen in the figure. The time flow diagram is constructed differently because most of the main components are happening at the same time, which is the advantage of using an FPGA versus a standard processor. Because of the nature of the HDL programming, it processes more like a circuit rather than a looping script. Latencies are found only between logic gates, and not found in background maintenance processes like a standard processor. This allows the FPGA to produce truly real-time video streams while operating other functions simultaneously.

Although there was not enough time to get any sort of software demo working, there was some work done programming the FPGA. The first test completed was getting a “Hello World” script run on the FPGA to prove all of the hardware and SoC were working correctly. Once this test was complete work began on getting the transceivers up and running as well as using I2C protocol to control the FPGA with the ARM processor. A custom transceiver PHY was created using the Megawizard function in

3 "Cyclone V FPGAs: Lowest System Cost and Power - Altera." 2011. 6 Dec. 2014 <http://www.altera.com/devices/fpga/cyclone-v-fpgas/cyv-index.jsp>4 "Quartus II Subscription Edition Software - Altera." 2008. 6 Dec. 2014 <http://www.altera.com/products/software/quartus-ii/subscription-edition/qts-se-index.html>5 "Qsys - Altera's System Integration Tool." 2010. 6 Dec. 2014 <http://www.altera.com/products/software/quartus-ii/subscription-edition/qsys/qts-qsys.html>


Quartus. The parameters were setup to allow the image data to stream into the FPGA from the CoaXPress cameras. The I2C work done was meant to allow the ARM processor to communicate with an I2C peripheral on the board but not enough testing was done to present a demo.

Figure—3: Software Data Flow and Time Flow Representations

Results and Discussion

Final Electrical DesignThe final electrical design for the FPGA board was for the most part done in the schematics. The

design of the FPGA board was very similar to that of the development kits used for this project so the priority to finish the FPGA board was very low. The development kits used were enough to complete all of the necessary software needed for the scope of this project. The CXP board on the other hand was almost completed in that the schematics were completed and reviewed as well as most the PCB layout. A lack of time inhibited the team from getting the CXP board fully integrated into the system.

Final Mechanical DesignThe major difference between the second iteration of the enclosure and the final design is the use

of an extrusion as oppose to having an enclosure to be machined. This is largely due in part to reduce the cost of the enclosure. The outside of the enclosure no longer consists of fins machined onto the outside as this would not be possible on the extruded version. Another major difference is the channels on the inner sidewalls can also no longer be included in the design due to the inability to machine them into the extrusion. The final design as oppose to having wedge-loks hold the sheet metal tray in place, the sheet metal tray will be attached to the end piece and will slide into the enclosure and be sealed off. At room temperature or about 23 and each of the board producing about 9 watts of heat, the enclosure was able℃ to dissipate the heat and remain below the 85 maximum requirement. An exploded view of the final℃ design of the enclosure can be seen below.


Figure—4: Exploded View of Final Mechanical Design Final Software Design

The final software design was not completed due to time constraints and poor planning. While focusing on finishing the hardware components, too much time had passed when the team began developing software. The only completed work for the software section was the initial “Hello World” demo and work done to get the transceivers up and running. This process included writing a CXPReceive system Verilog file and creating a custom transceiver PHY in Verilog.

Conclusions and RecommendationsWith the completion of the project right around the corner, it is beneficial to look back at all of

the work completed for the duration of this project. This project definitely enhanced the knowledge of FPGA’s available and what they are able to accomplish. It also improved the knowledge of basic circuit analysis and shed light on the intensity and thoroughness needed to complete a schematic design. Although the FPGA board was never fully completed it was very beneficial to be able to invest more time into the software development and execution.

Mechanically related, the different iterations of the design and the models created using SolidWorks along with the heat analysis carried out using Autodesk Simulation showed that the enclosure could meet the customer requirements. The second design, though superior in regards to heat dissipation, would have not been cost effective when compared to the final design.

Future work for the mechanical team would consist of sending out the sheet metal to be fabricated, fabrication of the extruded enclosure and final testing of the enclosure with connectors and boards in place. Any future work for the mechanical team would more than likely also consist of minor design tweaks and rearrangement of components. This is due to the uncertainty with the placement of the FPGA’s. After any full construction of the enclosure testing would need to be carried for IP67 compliance, heat dissipation, and force analysis. Results from the testing would then need to be compared to our original design and adjusted as needed. Future work for the electrical system would include finishing the FPGA board schematics, completing the PCB layout of the FPGA board, integrating the FPGA board with the rest of the system, specifically with the CXP board, and to test the software written on the development kits.

The software required to complete this project would need to be very sophisticated and would be


challenging for an entry level engineer. There aren’t any complete example solutions, or pre-produced open source processes that can take you directly from start to finish for this design concept. That ended up being a good thing and a bad thing for this project, because it made it interesting and challenging, but it also made it unreasonably difficult to complete for the scope of this course. Many concepts and ideas were generated, but in the end there are so many factors that were not taken into account when planning for this portion of the project. In hindsight, it would have been better to start with smaller ambitions and build upon that as we completed smaller tasks.

Future work for the software design would be to run a loopback test on the transceivers so known transmitted data could be read back through the receivers and then verified. Once this test was completed the next step would be to take in actual camera feed data and pass it into the FPGA for image processing. At this point the ARM processor could be setup up to control parameters of the FPGA to complete the data processing.

References"Cyclone V SoC Development Board Reference ... - Altera." 2013. 6 Dec. 2014

<http://www.altera.com/literature/manual/rm_cv_soc_dev_board.pdf>"DigiKey Electronics - Electronic Components Distributor." 6 Dec. 2014

<http://www.digikey.com/>"Cyclone V FPGAs: Lowest System Cost and Power - Altera." 2011. 6 Dec. 2014

<http://www.altera.com/devices/fpga/cyclone-v-fpgas/cyv-index.jsp>"Quartus II Subscription Edition Software - Altera." 2008. 6 Dec. 2014

<http://www.altera.com/products/software/quartus-ii/subscription-edition/qts-se-index.html>"Qsys - Altera's System Integration Tool." 2010. 6 Dec. 2014

<http://www.altera.com/products/software/quartus-ii/subscription-edition/qsys/qts-qsys.html>

AcknowledgmentsWe would like to thank Scott Reardon, Stephen Brown, Jim McGarvey, and Alex Sojda of D3

Engineering. We would also like thank Peter Hammond of Lightforce Technology along with Robert Spurr and Bill Jenkins of Altera Corporation.


senior design technical paper.docxedge.rit.edu/content/p14571/public/msd ii/seniordesignt… ·...

Documents