Can CoDeveloper handle "untimed" C?

Yes, CoDeveloper accepts untimed C. "Untimed" refers to C code that does not include additional information related to register boundaries, clocks and reset logic. CoDeveloper automatically parallelizes C code, and there is no need to express such parallelism at the level of individual statements or blocks of code. To do this, CoDeveloper analyzes your C code, finds interdependencies and collapses multiple C statements into single instruction stages representing a single clock cycle. This automated creation of parallel hardware can be controlled by the programmer (for size/speed tradeoffs) using compiler pragmas.

Does CoDeveloper fully support my selected FPGA?

CoDeveloper generates synthesizable HDL outputs that are compatible with most common FPGA device families. For users of Altera and Xilinx devices the tool includes additional, FPGA-specific optimizations to increase performance. CoDeveloper also supports certain types of FPGA-specific hardware interfaces, including Xilinx FSL, OPB, PLB and APU, and Altera's Avalon.

Does CoDeveloper require that an embedded processor be used in the FPGA?

No, an embedded processor is not required. If the target device includes a Xilinx MicroBlaze or PowerPC processor core, or an Altera Nios or Nios II processor, then the CoDeveloper compiler allows hardware processes to be described in C and connected to software running on the embedded processor. If, however, the goal is to connect Impulse C generated processes to other hardware elements (such as those written in VHDL or Verilog) then there is no need to use an embedded processor, and CoDeveloper can be thought of as a hardware IP block generator.

Does Impulse C allow me to compile my legacy C applications to hardware?

Impulse C is a set of library functions that support parallel programming for FPGAs using the C language. The CoDeveloper compiler tools are capable of accepting one or more C-language subroutines (which in Impulse C parlance are called processes), and compiling these to generate equivalent low-level hardware. As such, Impulse C and CoDeveloper are not specifically intended for taking large C applications that are written using traditional C programming techniques (function calls, etc.) and compiling these applications entirely to hardware. Such applications are best-suited to processor architectures, but may be accelerated dramatically by identifying key subroutines and inner code loops and moving them to hardware using data streaming or shared memory, both of which are directly supported in the Impulse C programming model. Using Impulse C, key subroutines can be partitioned and moved into dedicated hardware with relatively little effort. This can be done in an iterative manner, with software-based simulations being performed along with actual generation of prototype hardware to simplify debugging and system-level optimization.

What subset of C language does Impulse C support?

Impulse C is not (formally speaking) a subset of the C language. You can use any feature of C, for example, to develop an Impulse C test bench or to describe processes that will run on embedded FPGA processors. For those processes that will be compiled directly to FPGA hardware, however, there are certain constraints placed on your C code. These constraints currently include only limited support for pointers, no support for recursive function calls, and certain constraints on the types of control flow statements that may be used. When considering Impulse C, it's useful to think of the FPGA as a coprocessor for an embedded or host processor. The traditional processor hosts traditional C programs with all the features of C or C++. The FPGA is used to create hardware accelerators, using a somewhat more restricted subset of the C language and using the Impulse C compiler. Data streams, shared memories and signals (specified using function calls from the Impulse C library) are used to move data between the processor and the FPGA hardware in an efficient manner. The Impulse C compiler creates the interfaces between the processor and the hardware to implement data communication via streams, memories and signals.

How about global variables, pointers to structures, and other such features of C?

Impulse C allows specific modules (subroutines, or processes) of your C application to be selectively ported to the FPGA. Those portions that are being moved to the FPGA as dedicated hardware are constrained in the level of C that can be written, as described above. Those portions that will remain in software (in an embedded processor, for example) are not constrained, except by limitations of the cross-compiler being used. For hardware modules (subroutines that are being moved to the FPGA through hardware compilation), the compiler currently supports only limited use of structures. Pointers are quite limited as well, and must be resolvable at compile time to array references. As for global variables, these can be accessed using shared memories (using the Impulse C blockread/blockwrite functions) or by declaring a global array and accessing this array in multiple C hardware processes.

Is Impulse C appropriate for DSP applications?

Yes, Impulse C is being used today for a variety of DSP-related applications. The streaming programming model is ideal for such applications, and the support for fixed-width integers simplifies the creation of many types of DSP filters.

Can the Impulse C compiler take advantage of Xilinx DSP48 blocks?

Yes. The DSP48 blocks in the Xilinx Virtex-4 allow for the creation of a multitude of functions including multipliers, adders, counters, barrel shifters, comparators, accumulators, multiply-accumulates, complex multipliers and others. Current-generation synthesis tools can map multipliers, adders, multiply-adds and multiply-accumulates generated by Impulse C into the DSP48 slices. By observing certain rules when writing C code (in particular, paying attention to bit widths) it is possible to create inferred instances of DSP48 blocks. For even more control, Impulse C also allows external hardware functions written in HDL to be included in the C application. This allows lower-level control over generated hardware, including the explicit use of DSP48 blocks.

Can Impulse C applications be simulated before compiling to hardware?

Yes, Impulse C includes a simulation library compatible with standard ANSI C. This means that your applications (which may include multiple parallel processes written in C and communicating via streams, signals and shared memories) can be compiled in standard C development environments including Visual Studio and GCC/GDB. When executed in these environments, parallel behavior is emulated using multiple threads of execution which may be observed using a combination of standard debugging techniques and the Impulse Application Monitor.

Can I combine my own HDL with Impulse C?

Yes, you can make use of your own VHDL or Verilog as part of the design flow by merging design files at the time of synthesis or at the time of place-and-route. CoDeveloper generates synthesizable HDL (not low-level or obfuscated netlists) so you can use CoDeveloper as an HDL module generator alongside more traditional methods of design. The Impulse C process interface (data streams and signals) is easy to understand for the purpose of integration with other modules written in VHDL or Verilog. CoDeveloper Universal includes extended documentation and examples demonstrating how to connect Impulse C processes (written in C and compiled to HDL) to external HDL modules via the stream I/O interface. Sample HDL test benches and tutorials help you get started.

Does CoDeveloper support Verilog output?

Yes, both VHDL and Verilog outputs are supported in CoDeveloper. Note, however, that some Platform Support Packages (including the current support packages targeting Xilinx and Altera embedded processors) require that VHDL be used for hardware generation and synthesis.

Can I call external hardware components (or hard macros) from within an Impulse C process?

Yes, you can make reference to external components as C function calls, using the IMPLEMENTATION pragma supplied with Impulse C. This is useful for creating custom hardware functions optimized for specific applications. These functions may represent combinational logic operations, single-cycle operations or pipelined operations with defined latencies.

Can CoDeveloper pipeline loops?

Yes, CoDeveloper does support pipelining of loops. Loop pipelining is enabled for a given loop using a PIPELINE pragma. Examples supplied with CoDeveloper describe how to enable and control pipelining. Note that loop pipelining introduces additional hardware (for pipeline control) and should therefore be used carefully.

Can CoDeveloper unroll loops?

Yes, CoDeveloper supports the automatic unrolling of loops using the UNROLL compiler pragma. Loop unrolling can dramatically increase the performance of many types of algorithms, but can also result in large increases in the size of generated hardware.

Is floating-point math supported?

CoDeveloper supports floating-point types for Xilinx FPGA targets, and for certain Altera-based platforms as well. Contact us for details.

Is fixed-point math supported?

Impulse C includes fixed width integer data types which can be used to implement basic fixed-point operations, but does not include support for a complete fixed-point math library (which must include such things as saturation and rounding modes, etc.). Fixed-point math macros are provided, however, and additional fixed-point math features are being considered for a future release.

How does Impulse C compare to hand-crafted HDL code?

Just as assembly code programs are generally more compact than the equivalent code written in C, so is hand-crafted VHDL generally tighter than VHDL automatically derived from C. However, as a general rule the lower the level of abstraction (the form of the program), the longer it takes to write and the more costly it is to maintain. Furthermore, as the size of applications grows, the less practical it is to perform a complete manual optimization. This suggests that as design sizes grow, the practical result is that compiler-generated HDL outputs will begin to approach hand-written HDL in terms of size efficiencies and performance, assuming that the time available for hand-optimization of the hardware is finite. For smaller designs, the major advantage of Impulse C is dramatically shorter time to a working prototype, not design efficiency. CoDeveloper does, however, include extensive documentation that helps programmers understand how to write C code for efficient compilation to hardware.

How do I optimize a C design to improve performance and utilization?

By using appropriate C coding styles and through an understanding of the compiler tools it is possible to optimize for both performance and for utilization. The first priority of the CoDeveloper compiler is for performance, as measured in required clock cycles to complete a given task. A related, secondary priority is to reduce gate delays, which directly impact maximum clock rates. Because optimizing for speed can result in very large amounts of logic being generated, Impulse C allows certain optimizations (such as loop unrolling and pipelining) to be controlled via language-level pragmas. In a typical usage, Impulse C users are first concerned with getting a working prototype, which may operate at reduced rates but is sufficient to verify correct functionality (in simulation and in hardware) and to analyze dataflow at a system level. Later optimizations may include using modified C coding styles, specifying certain optimizer controls or re-partitioning the application to better take advantage of system-level parallelism and “tune” the application and its constituent algorithms to the target platform (FPGA device and/or embedded controllers). With nominal effort (e.g. days) Impulse C users have shown acceleration results of 100 to 300x through some relatively simple techniques, while at the same time reducing overall design size. If the performance of a given application is of paramount importance, then extra time should be budgeted for this optimization phase. If the smallest possible design size is a critical requirement, then the Impulse C user (perhaps working with an experience FPGA designer) should be prepared to replace certain portions of the generated hardware with hand-crafted HDL, using the generated HDL as an overall specification and functional benchmark.

How does Impulse C relate to System C?

SystemC is a publicly available, free-to-use library that a number of EDA vendors have embraced at various levels. These vendors include Forte, Celoxica, Synopsys and others. SystemC is slowly gaining momentum among higher-end ASIC designers for system modeling but at this writing has little or no traction (in fact no real awareness) among mainstream embedded systems designers. These embedded systems designers and programmers overwhelmingly choose standard ANSI C for their design activities. Impulse has positioned itself as a provider of embedded software/hardware development tools and is not in the traditional EDA or ASIC design tools business. Impulse has therefore chosen not to make use of SystemC as a key part of its strategy.

How does Impulse C compare to Celoxica's Handel-C?

Handel-C™ provides the ability to describe FPGA and ASIC hardware elements using a C-like language as an alternative to VHDL or Verilog programming. Handel-C provides direct control over parallelism by allowing the application developer describe such things as clocks and resets, and by specifying (through the use of "par" and other statements) how C code is parallelized when implemented as hardware. The specification of clock timing and statement-level parallelism is the most fundamental difference between Impulse C and Handel-C. Handel-C requires that clock boundaries be clearly specified by the programmer, while Impulse C does not. Impulse C is designed for software programmers who are familiar with C programming, but who may not be familiar with hardware design concepts. Impulse C therefore does not require the specification of clocks, resets or statement-level parallelism. Instead, Impulse C assumes that the compiler will automatically extract parallel behaviors from a given block of C code (such as in inner code loop) while giving the programmer the ability to describe system-level parallelism in the form of multiple communicating processes that use data streams for synchronization. Also, because Impulse C is based on standard ANSI C, any Impulse C application can be compiled and debugged using standard, widely available C development environments including Visual Studio™ and Eclipse™. There is no requirement for an Impulse-specific behavioral simulator or other such tool for verifying and debugging Impulse C applications.

How can Impulse C be used with MATLAB® Simulink®?

It's possible to use Simulink in conjunction with Impulse C, though some manual intervention by the programmer is required. First, you can use the C output from Simulink/MATLAB as a basis for porting existing algorithms to Impulse C. Practically speaking, some recoding of the generated C is involved, to allow the code to be compiled to the FPGA. For example, some usages of pointers and static variables in Simulink-generated code are not compatible with Impulse C. Second, it's possible to simulate an Impulse C process as an S-function, if you write an additional wrapper layer to convert between Impulse C streams (or other I/O) and the S-function interface. This allows you to simulate Impulse C components as part of a larger Simulink system, making incremental porting of an algorithm easier.

Can Impulse C be used for FPGA-based grid computing?

Yes. By combining one or more traditional processors (running one or more Impulse C processes) with FPGA processing nodes (also programmed using Impulse C) it is possible to create extremely high performance computing grids using a streaming programming model. Streaming may be accomplished using high-speed serial links that map directly to Impulse C stream interfaces. There are multiple research teams using Impulse C for this purpose today. In some cases these teams are making use of hand-crafted VHDL for critical processes and using the Impulse C programming model (and automatic generation of stream interfaces) as a system-level framework, in addition to making use of the C-to-hardware compilation features of CoDeveloper. Impulse C is highly applicable to such applications.

How long has Impulse been in existence?

 Impulse was formed in mid-2002, and formally incorporated in October of that year as a Washington State Corporation.