In addition to the extreme difficulties of developing the hardware, design teams should focus on developing more software. Some of the latest tools can generate an RTL representation of the design as well as a software representation, usually in C or one of its variants. With this capability, design teams can leave the design in its high-level representation until the last unit of design time and make a relatively simple change to either the hardware or software domain.
All of the design converges at the RTL and is the programmable-logic equivalent of RTL handoff/signoff. By moving toward increasing specialization at the tool level through other languages like C, MatLab, and RTL, designers can take advantage of higher-quality optimizations and faster run times. They can also get to a working system that's functionally correct at the algorithm level and relatively easy to transform to an FPGA.
C For Hardware Design: Most versions of C are reasonable for algorithmic and datapath descriptions but not so good for control logic or structures with high parallelism and concurrency. It's hard to explicitly define concurrency and parallelism in C without special constructs, but the special constructs just define another HDL.
Designers need a structured subset of the language for hardware, so C becomes just another HDL. It's a struggle to get to cycle-accurate constructs without using a structured language subset, such as system C. One strong objection to C or its variants as a design language is that compiler-generated names and connectivity information make it very difficult for designers to read the design when it's time to debug. The only port names that make sense are those generated by the designer. All of the others may as well have been run through a random-number generator or data-encryption engine.
Dan Ganousis, Accelchip's president, says the various versions of "C" are good for general-purpose functions and DSP coding. In fact, a person can do any design in C, but the design won't be very well optimized. Specialized languages like MatLab are much more efficient in developing models of certain types of systems, such as filters through the filter construction set. Even with the specialized languages, developers still need C for the rest of the application code, specialized constructs, and the specific calls to the hardware accelerators.
PLD Vendors To The Rescue? The big FPGA vendors, Altera and Xilinx, have developed specialized tools to address the block-, IP-, and functional-level of design with new tool suites. These tools not only help designers import IP blocks, but they also will create the interconnect and software drivers for all of the blocks.
These proprietary tools can expedite the design process by identifying the blocks to use, the structures, and the interfaces needed to assemble a functional unit, as well as enough code to get the design through the boot phase. The IP blocks supplied by the vendors and their partners are designed to be as parametrizable as possible for the greatest flexibility. Both companies also generate a majority of the interblock interconnect and the source code necessary to begin operating the functions.
One challenge for programmable-logic vendors is to find a way to wean their customers from their preferences for low-priced tools. If a company spends as much money for software development as for a new IC, the costs will run into the $10 million range. If the FPGA company gets 2000 users to buy the tool for as much as $1000 per copy, the $2 million in revenue for the new tools only pays for about one-fifth of the total cost of development.
One reason for the high cost of ASIC tool sets is the ongoing need to fund extensive and expensive R&D for new tool functionality. This disparity in costs and income will continue to be a challenge for PLD vendors who can't afford to subsidize their software development costs forever.
Future system-on-a-chip (SoC) design will require hardware-software profiling and partitioning tools to evaluate the hardware-software mix. Partitioning and synchronization is the difficult part of the design. So far, no tools exist to help in the tasks. Designers will need to evaluate architectures before implementation. As a part of the evaluation, designers will need to map the functions and timing to the implementation platform, then synchronize the various data transfers across the time domains. Such exploration tools would permit the profiling of the software and the associated software calls to the hardware accelerators.