Great article Rick! I will count Adapteva in the "others" group.:-) Inspirational answer from Eran!
Here are the two fundamental questions I have been struggling with for close to ten years. (first as a designer on the TigerSHARC DSP team and more rectently at Adapteva). There is certainly no right answer here..
--------------------------------------------------------------- Question #1: What kind of DSP to build? a.) Try to build a DSP that is great at a broad set of applications (impossible based on my TigerSharc experience) b.) Design a scalable DSP core that has "good enough" performance for many applications c.) Instantiate many slightly different DSPs each one tuned for specific applications (communication, embedded vision, compression ,etc).
Answer: I firmly belief that the cleverness of a small team of DSP architects and designers is no match for the infinite imagination of a world of developers. The general purpose DSP has always been a processor looking for a killer app. The more you constrain your architecture to solve a problem of today the worse you make it for the next killer app. This is the philosophy that drove us to develop the fairly generic Epiphany multicore coprocessor. (or multicore floating point DSP..)
------------------------------------------------------------ Question #2: Who will write the application? a.) The DSP IP provider, b.) A set of 3rd party development companies, c.) The semiconductor vendor. d.) A community of unaffiliated developers
For us and for all processor vendors, this is really the biggest issue. a.) Writing your own code doesn't scale, especially for a startup company b.) 3rd party vendors will generally not develop code for processors that don't have a big installation base without a significant NRE payment up front c.) Semiconductor vendors are under such intense schedule and complexity pressures that they prefer integration over compete stack development. We explored options a,b and c but realized that due to our economic situation and the market dynamics none of them would work. One of the reasons we started the Parallella project was to help bootstrap an eco-system around the Epiphany DSP.
With efforts like OpenCL and HSA, the importance of the ISA is actually shrinking, so we should see the number of DSP architectures proliferate going forward. Processor diversity is a good thing very everyone, including the consumer.
The DSP market is a fragmented and diverse one that requires a broad set of solutions, with flexibility and configurability being essential. Going forward it will be interesting to see how committed Qualcomm is to meeting this challenge. The CEVA approach is to offer customized, special purpose platforms consisting of hardware and software offerings for the unique needs of applications such as LTE/baseband, WiFi/connectivity, imaging and vision, voice and audio. The "one size fits all" approach of the Qualcomm DSP won't work for these types of specialized needs. For example, LTE and vision applications require a unique vector ISA, and must enable special data flow and processing offloading. In the audio/voice domain, the low power requirements of always-on use cases cannot be met with a VLIW / multi-threading processor such as the Qualcomm DSP; it requires a much lower power and smaller footprint DSP.
As important is the availability of value added software, delivered in source code format allowing licensees modification rights. Will Qualcomm be willing to deliver its proprietary software and algorithms like gesture and face recognition, camera and display enhancements? If this software is excluded, customers will hesitate to license just the hardware from a company they may see as a competitor.
Developing a software ecosystem is another challenge Qualcomm will face if and when they license their DSP. CEVA has invested thousands of man years into developing its ecosystem, and now has a massive developer community around its DSPs. This has been a key reason why the CEVA DSPs have shipped in more than 4 billion handsets, smartphones and other types of computing, communications, video, imaging, gaming, entertainment and automotive products. Simply delivering a set of tools does not cut it; developers need a solid development environment, customized kits, software libraries for various applications, system drivers, close support, documentation and more.
So to sum up, customers looking to license DSP cores do not look for a bare-bones general purpose DSP. They are looking for a platform solution, a combination of a special purpose DSP architecture combined with value added software and a robust ecosystem that can meet the power, performance and area needs of their targeted applications.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.