Integrated tools improve design and verification automation of embedded DSP systems

The traditional design process of embedded DSP system usually consists of two stages: from concept to algorithm and from algorithm to product. Usually these two stages are independent of each other and completed by different design teams.

In the traditional design process, manual conversion and connection between the two stages are required, which is prone to errors and delays the time to market. This article introduces an integrated tool that can make design and verification testing more automated and more efficient, thereby reducing product defects.

Over the past few years, products and systems have become increasingly powerful in terms of software functionality, with more and more intensive real-time requirements. For design engineers, in order to compete with competitors and bring new products to market faster, efficient system development methods have become a top priority, especially for engineers developing digital signal processor algorithms. In addition, factors such as the continuous shortening of product development cycles and life cycles have also prompted engineers and design managers to comprehensively re-evaluate development methods and software tool processes.

Product vulnerabilities can lead to a rapid decline in market share, and if a company sacrifices quality, its reputation will be immediately affected. Product engineers encounter many difficulties when implementing algorithms designed by R&D engineers, one of which is to manually transfer system parameters, test vectors, and other data from development tools based on the host PC concept to DSP code development tools based on target hardware. This manual conversion often causes errors that can only be discovered during confirmation and testing, resulting in longer development time. Market research shows that more than 50% of customer product development time is often spent on product integration and testing. At this stage, time-saving tools have a great impact on product functional reliability, time to market, and ultimate success.

In today's market environment, traditional product development processes are no longer able to develop engineers' development processes from concepts to algorithms and ultimately to product launches. New development processes require extensive tool integration to ensure that data and other information can be dynamically shared to achieve higher work efficiency.

Traditional DSP development process

The traditional design process of embedded DSP systems usually includes two main stages, namely the concept to algorithm stage (implemented by the R&D team, which includes algorithm development and system design) and the algorithm to product stage (implemented by the product development team, which includes actual product implementation, target programming and testing), as shown in Figure 1.

Since the above two stages are often independent of each other and completed by different design teams, and the goals of each team may not be consistent, there will be some problems within this structure. In addition, the tools used by the design team may be incompatible with each other and cannot be integrated together.

In most cases, R&D engineers use digital computing environments that allow them to fully exploit algorithm development, analysis, and visualization capabilities for a variety of scientific, mathematical, or engineering applications. R&D engineers often create algorithms in M ​​or C code, and can also create test vectors (usually data files in text or binary format) for their algorithms. They then run the algorithm in simulation on a host PC to analyze and visualize the algorithm response, with the goal of ensuring that the algorithm works not only independently of a specific platform, but also independently of any physical memory, speed, or real-time limitations. When they want to transfer the design to a product development group, they will submit written specifications or actual C or M code and ask the development group to implement the algorithm for a specific DSP target.

In product development, most DSP work groups use an integrated development environment (IDE). The team's goal is to implement the algorithm using written specifications, test the algorithm, and confirm it in the final product to ensure that it meets the system's real-time, speed, power, and memory constraints. Product development teams often rely on manual methods to perform the above tasks because there is usually no easy way to test the product directly based on specifications or algorithm test vectors. When encountering complex systems, manual conversion and confirmation will delay product development and affect product success.

Some manual methods that product engineers use to prevent disconnection include:

1. Manually copy and paste the M-file test vectors (e.g., an array of 100 values) into the C code (or assembly) file of the IDE. However, the engineer must be careful to copy all data without omission and to add the correct syntax to ensure compatibility (e.g., commas, brackets, parentheses, etc.);

2. Manually load the entire data file from the PC hard disk into the DSP memory using the "load data" command in a typical IDE. The engineer must be careful to reformat the data manually or through a script (which needs to be written and debugged) to ensure that the file format and subsequent syntax match;

3. You can use the IDE's file I/O functions (such as the fscanf() function) to load files in an automated manner like the second method above, but the problem of file format and syntax type still exists. Another major problem with traditional file I/O is that engineers must run a large and inefficient C library on the DSP itself, which will lead to code bloat, not only wasting memory, but also slowing down the DSP and making it lose real-time performance;

4. Use external hardware to generate signals as input to the system (such as music or sine waves) to observe whether the system can respond in real time. Unlike the test vectors and data mentioned above, which are already digitized, the data here is analog and must pass through an A/D converter, which will bring more errors and inconsistencies because it is no longer a pure digital signal, resulting in inherent analog distortion. In addition, it will bring additional variables, causing more uncertainty and making it more difficult to find the root cause of the problem.

Integrated tools increase efficiency and productivity

A more integrated development process can automate these tasks in a more dynamic way.

Let's take a real-world example, implementing an adaptive noise cancellation system on a DSP. The first step is to design an adaptive filter (i.e., filter coefficients, filter response, etc.), and the development engineer develops C code using commonly used DSP algorithm design and analysis tools (such as MATLAB from MathWorks) and runs it on the DSP, then synthesizes the input signal and tests the performance of the filter.

By integrating MATLAB with a common DSP IDE such as Texas Instruments’ Code Composer Studio, engineers can use the same front-end tools to design, visualize, analyze, and optimize algorithms in simulation, then implement the design on a DSP target, run it again, and compare the actual results with the simulated design.

In the example we present, developers can use MATLAB to directly access the DSP target memory, control the DSP program as it runs on the target, and gain access to MATLAB visualization, simulation, and optimization capabilities. The connection is enabled by a high-speed, real-time, two-way data communication mechanism, such as TI's high-speed Real-Time Data Exchange (RTDX). Figure 2 shows the MATLAB code, demonstrating how to use MATLAB to perform comprehensive testing of a signal, connect to the DSP implementation of the executable filter in real time through RTDX, and visualize the results.

The algorithm running on the target DSP receives the noise signal and the white signal as input and performs the LMS algorithm to remove the noise. Figure 3 shows the DSP output signal, filter tap, and filter response sent back to MATLAB in real time via RTDX, which means that when the code is executed, we can dynamically optimize the parameters in MATLAB, adaptively adjust the filter, and run Monte Carlo simulations to visualize the results. While the algorithm is running on the DSP, users can also call specific functions on the DSP directly from MATLAB and execute them in batch mode or interactive mode.

Therefore, the test and validation team can use the original MATLAB-based design or specification directly as part of the test setup. The test team can then directly compare the actual system output with the expected output generated by the original MATLAB design and make appropriate changes in real time.

Conclusion

By integrating the tools used by R&D and product development groups, we can greatly improve productivity, making design and verification testing not only more automated but also more efficient. Design teams that develop DSP algorithms and implement those algorithms on real targets can use a design environment front end that is integrated with the IDE and hardware back end without changing their development process methods. They can also automatically transfer data in real time to iterate product designs more quickly and efficiently without introducing new errors.

Design and development tool integration can promote testing and verification early in the development cycle, helping engineers to identify and solve problems more efficiently. Engineers need to build and launch new DSP products with more powerful functions faster and to market more quickly, and most importantly, to reduce product defects. Tool integration will help the ultimate success.