Today's SoCs typically include a variety of specialized co-processors and accelerators. In some cases, the chip supplier provides its customers with the ability to program these specialized engines. In other cases, the chip company does all of the programming, and provides API-level interfaces for application developers.
Although lack of access can be frustrating to application developers, providing complete access to a chip's capabilities isn't necessarily the optimum course of action at a particular point in time. Doing so might, for example, give competitors undesirable insight into a product's implementation details, including its strengths and shortcomings. There's something to be said, too, for "saving customers from themselves;" i.e. preventing them from making mistakes by doing the low-level coding for them. The more information a chip supplier provides about a particular block's implementation, the more constrained it might end up being in its ability to later evolve that implementation in a compatible fashion. And of course, the level of documentation and toolset robustness required for external customers is much higher than what internal developers tolerate, especially considering that the internal developers also have comparatively easy access to the engineers who designed the block in the first place.
On the other hand, opening up the specifics of a specialized block has benefits, too. Partners or customers may be able to implement a particular function better (whether "better" means with higher performance, with lower power consumption, less expensively, in a reduced memory footprint, a combination of these factors, and/or others) than the chip supplier's own engineers could, thanks to having a fresh "outsider" perspective, or the ability to spend more time optimizing. More generally, an outsider may devise new application capabilities that the chip supplier's engineers didn't anticipate. And some customers are flat-out unwilling to accept a "black box" API-based approach to interacting with a particular subsystem; they insist on gaining access to all functions as a prerequisite for considering the chip for their design.
Recently a semiconductor manufacturer contacted BDTI, requesting assistance with its plan to allow partner and customer access to a specialized co-processor core on-board its SoCs. The core had been used in several generations of devices. Yet up to that point, the manufacturer had handled all low-level programming itself via internal software development teams, providing external access to the core only via a set of high-level APIs. The chip company’s tools developers knew more work was needed to field a strong set of development tools that would enable customers and partners to access the coprocessor—but they were unsure of how to prioritize the many potential improvements.
To evaluate the toolset, BDTI performed a series of typical embedded software development tasks, focused on porting and optimizing a representative audio algorithm. In performing these hands-on development tasks, BDTI's engineers were impressed with the architecture's capabilities. But not surprisingly, the software tools and documentation weren't ready for "prime time"; some documentation references were out of date, for example, and documents were poorly organized. Similarly, the compiler and other software tools were buggy, un-optimized in certain respects, non-intuitive from a user interface standpoint, and clumsy from a development flow perspective. BDTI's engineers worked closely with their counterparts at the semiconductor manufacturer to identify and prioritize important improvements in all of these areas, along with others.
BDTI's unique value in this project was multi-fold:
- An independent perspective
- Extensive hands-on DSP software development experience—we don't have to imagine how users would use these tools, because we use them every day
- Extensive knowledge of the client's competitors' products, and
- Extensive experience in performing evaluations
Using these assets, BDTI was able to give the client a clear picture of how their tools will look and feel to typical users, and what needs to be done to make them competitive. The semiconductor manufacturer gained a fresh, unbiased and thorough perspective on what was needed to succeed in the marketplace, both for meeting customer expectations and for measuring up to competitors. And by engaging BDTI, it did so without need to divert internal resources from other important projects. Find out how BDTI can help you polish the resources needed to harness new product capabilities: contact Jeremy Giddings at +1 (925) 954 1411 or giddings@BDTI.com.
Add new comment