Workflow

Although every FPGA-based product has its own functionality, every PCBA is very similar from the hardware point of view. It contains many typical components, like oscillators, SPI flashes, DDR memories, Ethernet PHYs, high-speed links, etc. Using a netlist, block diagram or a schematic, identify peripheral components connected to an FPGA and choose Instruments that would test your board.

Not sure how to do this? Send us information about your board and we will provide you with a quote.

All our instruments are pre-developed and can be fetched from the off-the-shelf instrumentation library. Still, we need to adapt them for a particular board under test (to achieve optimal performance) and then compile them using our back-end compilation servers.

To do this, we need to know the basic information about your board: the FPGA partname and a pin map between the FPGA and peripheral components. It could be a simple plain text or an excerpt from a schematic. We understand that this information is usually confidential, so feel free to contact us and sign an NDA to streamline data exchange.

After that, give us half a day to prepare a ready-to-use test firmware (the compilation of FPGA designs takes time)! When ready, QI Test FW - the compiled FPGA bitstream - will be delivered via email in a binary format.

Using Quick Instruments, you test a board component by component and gigabit links - line by line. So, an essential task is to create a project-specific test program for the particular board depeding on the number of components and test specification.

The physical communication between a tester PC and QI firmware running on the  board is done via the JTAG bus. The JTAG is used for uploading firmware, communicating with instruments and fetching the results back to the tester PC. Since all the test complexity is shifted into an FPGA firmware, even basic USB-to-JTAG cables, like FTDI C232HM-DDHSL-0 or Digilent HS-3 fit most of the test setups. 

On the software side, we are providing API access to our .NET DLL. This API provides a very handy way to work with target devices on the board. So, in the end, the test engineer would create a test program that is calling high-level functions either from a scripting language platform (i.e. Python) or from test management software, like NI LabView or TestStand. Most test or measurement functions are designed for automation and can be executed with just one line of code, which allows building a test program in short time.

We recommend to develop a test program using a Python scripting language as it allows to run Quick Instruments in a very easy and efficient way. There is no need to compile a source code, the language is general-purpose and dynamic, thus memory management is handled automatically. Python is widely used and contains many modules that can extend its usability and applicability.

We are not limiting an end-user to some fixed GUI and way of execution. Is it up to an end-user to select the preferred scripting language and test manager / sequencer platform to run. Quick Instruments test digital part of a PCBA and usually it is a piece of bigger test program with DMM checks, analog measurements, application tests, etc. Quite often, test execution software selection is much dependent on the complexity of the overall test procedure and on the number of third-party components which should be integrated together.

The developed test program can be executed either directly using a Python sequencer or it can be integrated into any test execution platfrom, e.g. NI TestStand, Keysight PathWave, etc. LabVIEW suits well when you need to integrate several complex algorithms together and GUI is beneficial. Implementing a set of sequential test scripts using LabVIEW is a very tricky and difficult task. Test sequencers are more suitable for this kind of things.