![\"Schematic](\"http:\/\/cdn2.hubspot.net\/hubfs\/20421\/BLOG\/Images\/datatransfer02.png\" "\\"Schematic")
<\/h3>\nThe frame grabber side of the CoaXPress interface<\/h3>\n
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<\/a> where we used CXP-6 x4.<\/p>\n 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\u00a0 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.<\/p>\n 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.<\/p>\n 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\u00a02) 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<\/a>.<\/strong> 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.<\/p>\n 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.<\/p>\n 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<\/a> 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.<\/p>\n 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.<\/p>\n 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.<\/p>\nFrom frame grabber to host PC<\/h3>\n
![\"Comparison](\"http:\/\/cdn2.hubspot.net\/hubfs\/20421\/BLOG\/Images\/bittransfer.png\" "\\"Comparison")
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.<\/h6>\n