Extreme Testing

Interfaces with high data transfer rates play an increasingly important role in virtually all areas. These so-called high-speed interfaces are common as USB 3.0, SATA and PCI Express. In the automotive industry in particular, it is becoming increasingly popular to use interfaces of this type when it is important to process large amounts of data with minimal delay, for example in the case of video-aided parking assist systems. Interfaces with high transfer speeds are also required to connect external mobile devices.
However, the high-speed interfaces present special challenges when it comes to the options for testing. So far, the test options have essentially been confined to the use of a sampling oscilloscope during development on the one hand and to function testing at the end of production on the other. Both are certainly legitimate options and have their technical merits – but they also have their limitations.
While a sampling oscilloscope does enable precise test analysis, it is not suitable for production for reasons of sensitivity and high investment costs. In addition, modern error corrections on the interfaces are so good that the signal observed on the transmission line has limited informative value. An end-of-line function test is usually synonymous with a system function test. This test, too, is important – particularly in its role as the final test – and is not easily replaceable. Error analysis is complicated by the fact that various assemblies are the subject of the function test, however. Detected defects can only be traced back to faulty functions, or sub-functions. This is not always indicative of faulty hardware, which thus restricts the analysis. In addition, a high level of complexity of the assemblies in a system to be tested can complicate error analysis right at the end of production.
At this point, the BERT (Bit Error Rate Test) IP for FPGAs begins, to close this gap by enabling functional tests at board level with a qualitative assessment. Modern FPGAs include modules for operation and testing of high-speed interfaces. The ChipVORX BERT IP from GÖPEL utilises these modules to use the FPGA as a local measuring instrument. This FPGA is in turn controlled by a test system, CASCON.

BERT Performance
The test analyses the signal received directly at the high-speed interface. Depending on the capabilities of the module and of the test mode selected, it is possible to ascertain the bit error rate by means of a comparison with the transmitted data on the one hand and on the other to create a graphical eye diagram. Because the signal used for the test has already been cleaned up by the existing error corrections, the test results describe the effective transmission signal. The eye diagram thus provides a qualitative assessment of the transmission path from the perspective of the FPGA. This makes it possible to see when the silicon "sees".
Depending on the customer-specific set-up of the system to be tested, there are various possibilities for applying the Bit Error Test Rate.
The first fundamental distinction is in the controllers used. A distinction must be made here not only in terms of whether an FPGA or a microcontroller is used but also which type. This decides whether or not the BERT IP on the module can be operated at all. On the other hand, it is also possible to determine which test methods are possible besides the Bit Error Test Rate. This could be sampling eye diagrams or statistical eye diagrams, for example.
A loopback test can be configured by connecting the transmission line to the receiving line, where both the transmission and receiving line are connected to one another. This results in a loopback circuit, in which the same FPGA works as both the transmitter and receiver. Only the controller with the de-bugging connection for the assembly to be tested is necessary, resulting in a very simple test set-up. Since the entire path is always tested, this gives rise to short test times in production overall. However, the result of the test applies for the entire transmission path. It is therefore not possible to provide any information about the precise sub-area in which a possible error was caused.
With the embedded peer-to-peer setting two FPGAs located on the same assembly are connected to the corresponding transmission and receiving lines and can be accessed via a debugging connection. With this form of the test set-up, each transmission line is tested individually. This results in incredibly accurate test results. In order to achieve this, however, two debugging connections are required. This can lead to an increase in test time, depending on the number of lines to be tested.
In an external peer-to-peer setting each FPGA is located on its own assembly and connected to a debugging connection. The connection of the transmission and receiving lines is set up via the assembly interfaces. This results in the most accurate possible test, on account of the fact that the individual lines are tested. A test set-up such as this is also possible with an external test module instead of a second assembly. However, the complexity of the set-up also increases with this set-up, as does the number of possible influencing factors. A rise in the overall test time is associated with this.
In the loopback test with adapter board configuration, the controllers are each located on a separate assembly but are each connected to only one debugging connection. The connection of the transmission and receiving lines is set up via the assembly interfaces here, too. This test is possible because the standards for the high-speed interfaces provide a loopback mode. In this respect, the BERT IP in the test assembly can be replaced by loopback software, which sends the received data directly to the test module. As a result, the transmission path can be tested through the module on the assembly.
The advantage of this is that the assembly under test does not require a dedicated debugging connection. However, the software on the UUT must support loopback mode. In addition, with this set-up there are many possible influencing factors affecting the test setting, which must be taken into account.
The software environment SYSTEM CASCON is necessary in order to be able to use the BERT IPs, which takes over the control and evaluation of the IP from the PC. Test selection and test configuration are accordingly carried out in the CASCON software. In addition to the specific test cases, the test environment always plays a major role, too. Depending on the interface used, the issue of contacting can necessitate special adapter solutions, particularly in the production line. Specific analysis and advice is always recommended here in order to obtain continuous and reliable test results.
The Bit Error Rate Test IPs enable qualitative tests of high-speed interfaces on a functional level. The various test types (such as eye diagrams) allow a glimpse of the signals as they actually arrive at the relevant FPGAs/microcontrollers. In the production line in particular, this enables quality assurance at the assembly level, which cannot be achieved with function tests alone.