Watching a product mature is a great experience. Working with ScanWorks for over 15 years has provided a unique opportunity to assist in the maturation process from a point solution to that of a platform. Most of my experience has been in taking business opportunities and developing other tools that start out addressing a customer or niche market needs. These adventures almost always end in a point tool. After product deployment and working with more and more customers, the product evolves to the point but, too often there it is still missing a little something. Then looking at the products in-house you find the missing piece. By extending an interface here and there, you begin to see how to integrate tools together within the architecture and that provide a much better problem-solving solution and better user experience. ScanWorks had evolved to a world-class boundary scan test tool. To make it better, it needed to evolve into a platform where other tools could interface using the same target connection infrastructure, JTAG. Here are examples of two such point tools that are being integrated within ScanWorks. These and other features make ScanWorks a world-class tool and platform by enabling functional test and FPGA embedded instruments.
ASSET, for several years, has had the ability to add programming IP into an FPGA which accelerates the programming of a device at substantially higher speeds than JTAG. The previous solution from ASSET involved two separate applications: ScanWorks, and the Embedded Test Generator (ETG). The process for the embedded instrument generation (in this case SPI programming) was done within ETG and the result was a Serial Vector File (SVF) image for programming the FPGA. Then use ScanWorks and create two actions: one to program the FPGA and the second action to point the embedded instrument to be used for programming the SPI device. Because the two tools both used projects this caused confusion and forced the user to copy files from one project to another. All-in-all, it did not fit the test development design flow and often data, that was needed for others in the organization, was left out of the exported project.
With the introduction of this release of software, we have simplified the design flow when using ScanWorks and the Embedded Test Generator tool by integrating the ETG into ScanWorks. Now with the integration, there are no files to copy and the organization can share the exported project. Different teams can now analyze how the image is configured (pin configuration and parameters) in case there are concerns about the FPGA configuration or utilization. The flow from the FPGA developer’s perspective for embedded instrument generation has not changed. Only slight modifications in the user interface were required to enable the integration.
The benefit of having the FPGA Flash Programming is programming at higher speeds increases the production beat rate and during development improves developer efficiencies. By programming the devices in production, during board test, it is possible to use the same test connection point. Often designs have SPI or QSPI devices only accessible via the FPGA for storing the bit file. Then a connector is added to the design to support the programming which adds costs and is not necessary if the FPGA is accessible from the JTAG port being used for board test.
The next set of tools that were standalone are Processor-based Functional Test, Processor-based Fast Programming and Processor-based Functional Test for DDR memories. These tools targeted System-on-Chip (SoC) silicon. The tools are designed to address the complexities this silicon brings to the manufacturing test world.
SoC adoption rates are ever-increasing and with newer designs comes increasing challenges and learning. Our experience and experience with customers, has observed that designers generally start with a reference board from the SoC provider and learn about their design methods, both hardware and software, and use the experience gained to start our own design. Shortly thereafter designs begin deviating from reference target platform into what is needed. With SoC that can be tricky. Designers still need the design tools from the SoC provider to configure the IO and buses on the SoC to match the hardware design. These design tools are not intended for production test.
Most of the reference boards the ASSET design team saw had the SoC on a dedicated JTAG scan chain. Which made good sense allowing the JTAG clock setting to the highest frequency supported by the SoC which promotes quicker communications to and from the device. One area of deviation seen on multiple designs, as the SoC adoption grew, was adding more JTAG enabled devices on the same chain as the System-on-Chip. This presented a challenge for the PFx tools as the original design was to support a single device, as we had experienced with the reference target platforms. Thus, for the PFx tool suite to become more robust it needed scan path management support added. So, integrating PFx into the ScanWorks platform, which inherently does scan path management automatically for any application, is a great example of the value of integration into a common platform for our users. It is amazing to be a part of the team and watch the ScanWorks platform grow and evolve. For more information on these and other tools check out https://www.asset-intertech.com/products/#scanworks
