In our day-to-day lives, we don’t notice the complex silicon chips at the heart of our most-used devices – they are usually well hidden inside. The chips’ capabilities, on the other hand, are very noticeable: they enable us to take high-quality photos with our phones, alert us to pedestrians when driving and to detect and recognize the commands we issue to our virtual assistants. In this post series, I want to focus on the challenges involved in verifying chip functionality.
There is a hidden army of talented people – researchers, hardware architects, hardware designers, software developers, integrators, and quality assurance engineers – who ensure that every chip in your slick-looking device works smoothly and as advertised, under all possible circumstances. These people must coordinate their efforts, even when oceans and time zones separate them. Their task is to guarantee that the different pieces of the puzzle fit together perfectly and that, out of the multitude of software code lines and hardware logic blocks, the required functionality works smoothly to meet consumer expectations. One of the biggest challenges in implementing those chips functionality lies at the boundary between the software and the hardware.
Since you’re reading this post, I’m going to assume you already have some familiarity with the world of embedded design, but I’ll quickly recap some of the main challenges, especially as they apply to software development for embedded DSPs.
First, why would you want to use a DSP? CEVA DSPs are specialized for multiple application domains, such as AI, computer vision, speech recognition and mobile communication. Using a DSP allows for higher performance and lower power than you could achieve using a general-purpose CPU, while still preserving the flexibility of being able to program behavior through software. CEVA DSPs run a real-time operating system where needed in order to guarantee the real-time performance usually demanded from DSP applications. Applications can run multiple threads, concurrently on a multi-core system, or by time-sharing on a single core. The threads can then handle asynchronously multiple parallel processes, controlling different hardware elements of the system and processing the data.
An example of a DSP operation is processing the images coming from the camera, by enhancing the colors or the contrast, fusing multiple images into one through a High Dynamic Range (HDR) algorithm, automatically detecting scene content or stabilizing a shaky video shot by a handheld phone during a fast ride. Or it might perform all of these functions for two video streams coming from two sensors at 120 frames per second, with Ultra-High Definition 8K images of 12 bits per sample. At these levels of complexity, data-rate can exceed 33GB/sec, highlighting the complexity and challenges in making every bit of this process work as expected.
DSP architectures can be rather complex, and corresponding assembly operations can span over multiple lines. To meet throughput expectations, code is heavily optimized for performance, either by a dedicated compiler or manually by the programmer. This involves unrolling loops, re-ordering instructions, combining them for parallel execution in a single cycle, and so on. Debugging such code can be extra-hard and calls for extra-strong debugging tools.
Development of new functionality typically starts in a high-level environment, such as MATLAB, Visual Studio or GNU development/debug tools running on a PC. These environments are popular among software developers, well documented and have lots of ready implementations for various algorithms, often distributed as open-source. This allows for quick ramp up of software, reusing code, taking advantage of high-level programming environments and working on fast server infrastructure. Engineers can communicate easily, sharing code and splitting work between several developers or even teams. These development environments provide an easy and comfortable debugging experience: programmers can relatively easily trace bugs and implementation faults by stepping inside their application during run-time, to check memory and variable values, set breakpoints, manually manipulate resources and check results, sometimes recompiling the code without even stopping the debugged application.
But ultimately this software needs to run, and run effectively, on the embedded target. At that point, developers need tools that enable them to debug and optimize software on the actual chip. That requires deeper insight than can be provided by mainstream development and debug tools.
Hardware Debugging Challenges
Debugging software on the target hardware presents a different set of challenges because the target chip or device is a ‘foreign’ element in our desktop working environment. The desktop working environment and its operating system know (somewhat) about their own compute engines but usually have no standard way to access the internal state of external hardware. This is why ultimately you have to work with the embedded development environment provided by your hardware vendor. These embedded development tools can communicate with the target device and observe or manipulate internal state. When you work in a different debug environment for this detailed stage of debug and optimization you’re going to want those tools to provide an easy-to-use debugging experience, and that they will fully support all your needs at this stage.
Debug against the target hardware can be challenging for multiple reasons you won’t see in early development. One is simply to establish the debugging connection with the DUT (Device Under Test), where you can run into communication problems which can be mystifying. More generally, hardware debugging problems can occur at various stages: on initial connection, device reset, application loading, debug-stepping through the program or viewing the values of memory and variables; the cause of such problems may not be at all apparent. Host-based or generic development and debug tools can provide little help in isolating this kind of problem since they have no knowledge of the target platform. You have to turn to a development/debug platform designed to understand the system you are building.
In the next post I will talk about the CEVA Software Development Tools components, and the specialized mechanisms they offer to help manage the challenges of DSP programming and debugging.
- Read More: