Letter to the Editor

Editor’s Note:  The following Letter to the Editor addresses the Editor’s Insight column published in the recent print Resource Guide issue of DSP-FPGA.com.  Gedae takes issue with my comments that tools do not exist to simplify the problem of designing DSP functions into FPGAs. --C. Ciufo

Hello Chris, I just finished your Editors Insight Article: 2 Trends I Didn't See, and thought I should email you to let you know there are tools available for tackling the system-level issues of DSP system development. We echo your concern about the difficulties and problems of programming at such a low level.  Perhaps fifteen years ago, one could become an expert in SHARC and ASIC processors and use them to their fullest power on a variety of projects.  However, with the advent of multicore processors and FPGAs and the increased complexity of deployed applications, we can no longer get away with tying our knowledge and our code to one type of processor.  It is not reasonable or practical to train all developers to become experts on the workings of each potential target hardware.  If this work can be done once and then reused or automated, why burden our engineers with cumbersome, detail-level work? The increased focus on multi-core, -DSP, and -FPGA technologies also heightens the need for tackling system-level issues in a high-level toolset.  If your high-level programming tool can only program one DSP in a quad-board at a time, or only one of the eight Synergistic Processing Elements (SPEs) of the IBM Cell processor, then how is that output getting used in your end product?  Likely it means the project's schedule includes significant planning time on the front end to preplan the partitioning of the work and significant integration time on the back end to bring all the pieces together.  Ignoring these system-level design issues means using "one piece of the puzzle" tools does little if anything to reduce the risk of digital system development.  How many programs fail each year because it is just too difficult to rewind the design process and readdress these vital system-level issues? We believe our product, Gedae, is unique in its ability to solve these system-level issues.  Partitioning of work and mapping to heterogeneous processors can be done at build time, not design time, and this partitioning and mapping can be iteratively improved in a spiral development process.  The language is fully faceted - capable of programming any digital system - and uses autocoding to create efficient applications using only a lightweight layer of abstraction above the hardware.  The tool has been used successfully in several real time deployed systems on both COTS and custom multiprocessor DSP hardware. We would like to thank you for bringing this issue to the forefront with your article. We believe the main risks in program success and software obsolescence are becoming too mired in the details of architecture-specific coding, and share your hope that the industry will face this problem in 2007. James Wakiza Steed Gedae, Inc.