Image data transport: from pixel to PC by CoaXPress Part 2
Benny Koene on Fri, Aug 26, 2016
Translating data rate and frame rate
In our previous blog we analyzed the image data transport from the generation at the pixel level up to the transport via the CoaXPress cable towards the frame grabber as part of understanding the data rate required for the imaging system and where the limitations may be. Here we will analyze the data transport through the frame grabber to the host computer. In this part you will find the answer to the question: what is the influence of the frame grabber and host computer on the frame rate of the camera?
The frame grabber side of the CoaXPress interface
Basically there is no difference between the frame grabber side of the CoaXPress interface (block 3 + 4) and the camera side (block 2 + 3). The frame grabber has to support the same CoaXPress data rate and cable configuration as the camera, like in the blog from last week where we used CXP-6 x4.
However, it is interesting to discuss about how some frame grabber manufacturers report the CXP data rate. For example, Euresys actually reports a data rate of 2500 MByte/s (20 Gbit/s) on their webpage for CXP-6 x4 while in our previous blog we have seen the total data rate equals 4 x 6.25 = 25 Gbit/s and the effective data rate equals 19.2 Gbit/s. So where does this 20 Gbit/s come from? Actually this 20 Gbit/s includes the reduction in effective data rate from the encoding used to guarantee a perfect data transfer, but it does not include the estimate of 4% overhead as we included in our previous blog. By leaving out the bandwidth that is being occupied by the encoding it is easier to compare with the data rate of other interfaces that might use a different encoding. For example, while CoaXPress uses 8 to 10 bit decoding which requires 20% of the total available bandwidth, the PCIe 3.0 interface uses 128 to 130 bit encoding which requires only 1.5% of the total available bandwidth. As both interfaces will require overhead data, the overhead data is not taken into account in the data rates mentioned by Euresys.
From frame grabber to host PC
After arriving at the frame grabber, the next data highway is the transfer from the frame grabber to host PC. In almost all cases, the interface for this task will be a variant of PCI express (block 5 in the schematic overview). Some of these PCI express variants are slower in comparison with the CXP interface. Furthermore the PCI express interface has a different data handling which influences the possible frame rate in pixel formats that are different from 8 bit. Below are a few examples to illustrate the important aspects.
Although we will take Euresys frame grabbers as an example, the phenomena described here is applicable to other frame grabbers as well. For our first example we will consider the the Euresys Coaxlink Quad frame grabber. The fastest configuration supported by this card is the CXP-6 x4 configuration. To transfer the image data from the frame grabber to the PC it uses the PCIe 2.0 (Gen 2) x4 interface. Although it depends a little bit on the exact host computer hardware that is used, from the maximum bandwidth of 2000 MByte/s of this interface on average 1700 MByte/s will be available for image data transfer. For more information about why the maximum bandwidth cannot always be reached, please read the information from the Xilinx white paper in this pdf. This 1700 Mbyte/s is not sufficient to transfer the full CXP-6 x4 data rate of 2500 MByte/s in real time to the PC. In this case the frame grabber is thus the data rate limiting factor.
The maximum supported frame rate by the frame grabber can be calculated by multiplying the maximum supported frame rate of the interface with the factor obtained by dividing the effective PCIe interface bandwidth by the CXP-6 x4 bandwidth: 1700/2500 = 0.68. For an 8 bit 25 Mp image like we used as an example in our previous blog this gives a frame rate of 91.6 x 0.68 = 62.3 fps.
The follow-up version of the Euresys Coaxlink Quad is the Coaxlink Quad G3. This version supports the PCIe 3.0 (Gen 3) x4 interface for data transfer between frame grabber and host PC. From the total bandwidth of 3938 MByte/s, on average about 3300 Mbyte/s is available for image data transfer. This seems to be sufficient to support the full CoaXPress data rate, and it is also sufficient for the 8 bit pixel format. However in case of the 10 bit pixel format, a difference in how the two interfaces (CXP and PCIe) treat the pixel data causes that the data rate on average is actually not sufficient.
This has its origin in the fact that CoaXPress supports pixel packing and PCIe does not. The result of CXP pixel packing feature is best explained by an example of what happens if no pixel packing is supported, like with PCIe. In PCIe all data is packed in bytes, e.g. 8 bits. This means that if a 10 bit pixel is sent over a PCIe interface it actually requires two bytes (16 bits). This results in a data increase with a factor of 16 bits / 10 bits = 1.6 for PCIe in comparison with CXP. Six empty bits are required on top of the 10 data containing bits for the correct PCIe data handling. For CXP this strict use of 8 bit units is not required. The data of two subsequent pixels can be placed directly next to each other without empty bits. So as CXP has a data rate of 2500 MByte/s , for 10 bit pixel data the PCIe interface requires a data rate of 1.6 x 2500 = 4000 Mbyte/s.
Figure 1: the top line represents the 10 bit data handling by CXP while the bottom line represents the 10 bit data handling by PCIe. The green parts are data containing bits while the red parts are areas with empty bits.
So if we now go back to the Euresys Coaxlink Quad G3 frame grabber, which has a PCIe data rate of 3300 MByte/s, it is clear that this is insufficient for a 10 bit pixel depth at the maximum frame speed that is supported by the interface. The 10 bit frame rate supported by this frame grabber will be 3300 / 4000 = 0.825 times lower compared to the maximum frame rate supported by the interface, i.e. 73.2 x 0.825 = 60.4 fps. In this situation the frame grabber is thus the data rate limiting factor.
We would also like to mention again that the above analysis is not limited to Euresys products but also applies for all other frame grabber brands such as BitFlow, AvalData, Matrox, Silicon Software, Active Silicon, Kaya Instruments and Gibel. Links to these companies can be found here
All CoaXPress frame grabber suppliers are experienced in helping their customers setting up cameras and Host computers in such a way that the required data rates can be processed.
In summary
As this is the last part of a two part article it is useful to give a brief summary. As you have seen data rate and thus frame rate limiting factors can occur at all places along the transport line between the detected pixel signal and the host PC. In case a higher frame rate is required it is thus useful to do an analysis of what actually limits your data transport. Is it the image sensor? Is it the Interface or is it the frame grabber? In this article we have shown some simple calculations which hopefully can assist you in analyzing your vision system. If you need some more help or require more information don’t hesitate to contact us.
Comments
