Debugging Embedded and Real-Time Systems by Arnold S. Berger

Author:Arnold S. Berger [Arnold S. Berger]
Language: eng
Format: epub
Publisher: Newnes
Published: 2020-07-16T16:00:00+00:00

approximate the performance of processors in modem and related fixed-telecom applications.h

The leftmost column shows the benchmark score for the TMS320C64x DSP processor compiled without any optimization switches enabled, resulting in a benchmark score of 19.5. When various optimization strategies are employed, particularly those that can take advantage of the architecture of the processor, the benchmark score dramatically improves. Specifically, the TMS320C64x has 2 identical groups of 4 functional units and 2 identical banks of 32 32-bit general-purpose registers.

With the compiler able to aggressively take advantage of these architectural features, the benchmark score jumps to 379.1, which is an improvement of more than 19 times. In column 3, the code is hand optimized at the assembly language level, resulting in an improvement in the benchmark score by almost another factor of 2. The total improvement from out of the box to hand-crafted in assembly language is 32 ×.

To put this performance data in context, this is a potential bug that will only become apparent during validation testing, when the system loading begins to stress the processor’s ability to handle it. The scenario might be that deadline failures are observed during testing and the engineers begin the process of debugging the code. However, there is nothing wrong with the algorithms themselves, as the defect lies in the decision of how to compile the code.

It might have been something as simple as the need to turn off optimizations during testing, and the bug was not able to revise the make-file to turn the optimizations back on. That’s certainly happened before.

The key takeaway here is that these performance issues need to be resolved sooner rather than later. In fact, all the compiler issues should be part of the internal specification document that will define the development environment of the project.

Phase 4: Detailed HW/SW Design: This is the phase that everyone is most familiar with because this is the phase where the hardware and software bugs are predominantly introduced into the project. However, I hope that I’ve at least sensitized you to the reality that defects can be introduced far earlier in the process due to poor decisions in processor selection or design partitioning. While clearly not the same as missing trace on a PCB, a project decision having to do with the poor choice of a vendor for a critical part can have the same level of schedule impact as trying to chase down an elusive hardware glitch.

My next favorite defect is the hardware bug workaround. This typically occurs later in the process when hardware and software are brought together for the first time. If the hardware is an FPGA, then it is generally a nonissue. If it is a custom ASIC, then it is a big problem. This is where the “fix it in software” solution is brought into the equation.

Now the advantage of hardware acceleration is lost and more of the burden of maintaining the desired level of performance is put upon the software team because the part of the hardware algorithm that does not work properly must be repaired/replaced/augmented/etc.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.