|
马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。
您需要 登录 才可以下载或查看,没有账号?注册
x
本帖最后由 cjsb37 于 2013-4-29 08:55 编辑
在DSP和FPGA的设计中常常听到HANDEL-C这一工具,下面简单介绍一下Handel-C的特点:
Celoxica’s Handel-C is probably the best known way to cover the wide area of converting C language programs to hardware, co-simulation and co-verification. The development kit DK has been shipping since 2001. But how does Handel-C work? The background is CSP (Communicating Sequential Processes), an approach used a long time ago with transputers to run software as parallel processes where communication between different processes was taken care of automatically. As all of the “inputs”, “outputs” and “connections” of any piece of code were connected via a special communication protocol, it was not important where the code was running.
Handel-C is based on the same CSP approach and the tool DK converts C functionality to logic blocks in hardware, connected via latches, and optimizes the resulting network to generate an EDIF output directly for FPGA tools from Altera / Xilinx. Additional Register Transfer Logic (RTL) in VHDL or VERILOG can be generated to feed into an existing design chain for ASIC or FPGA implementation.
The most important fact is that Handel-C is fully synchronous, there is only one master clock (see table 1 for some of the constructs). Changes propagate at each rising clock from block to block. Between two clock cycles there is time for the data to settle, until the next clock cycle propagates the data further. The whole design is by definition fully synchronous. All of the code is translated into blocks that execute based on this clock, where latches make sure that everything is running in lock-step. On the basic level this executes like sequential execution (similar to software but faster).
par
define the following pieces of code to run in parallel
delay
delay data for one clock cycle
chan x define channels for communication between blocks of code
? read from a channel
! write to a channel
seq
define the following code for sequential ececution
ram/rom define various types of internal memory
interface
define connections to external hardware, e.g. I/O, RAM/ROM
width
define the width of a path/ register, from 1=wire to n
pragma
for specifying certain timed behaviour
The real speed-up comes with the PAR statement, which defines pieces of code that will switch blocks of gates in parallel. The designer will first define the obvious independent functions to execute in parallel and refine if the required speed cannot be achieved.
If the speed required for the design is not achievable with a single clock domain (one master clock) then multiple clock domains have to be used, where the output of one clock domain will trigger another block of gates. The same approach has to be applied, if peripheral functions are tied to specific clocks.
The general design approach can be compared to software development in C and Assembler: First, design and verify the algorithm/application. If execution time in C is then not fast enough, find critical code and optimize in Assembler (which means introduce more parallel execution of Handel-C). The aim in Handel-C is not necessarily to find the fastest implementation from the beginning, but to achieve a working debugged and tested solution as quickly as possible and then optimize until the required execution speed for the application is achieved with an acceptable amount of gates.
A main advantage of Handel-C is that a top down design can be used from the beginning, but implementation of code in FPGA is possible from the beginning as well (figure 1). FPGA boards and integration tools with all the necessary support software are available, so a designer can start with a standard solution without having to build their own boards or interfacing code. As result the design team can get an impression very early in the design cycle about speed of execution in software or hardware.
Partitioning into hardware and software will be a lot easier, as code that took long to simulate will have been ported and debugged in FPGA already, so “hot-spots” are known. It is important to understand, that the Handel-C code will basically stay the same all the time. EDIF for FPGA tools of Altera and Xilinx can be generated directly from Handel-C and recoding into a Hardware Description Language like VHDL is not necessary, unlike the normal route from C through VHDL to FPGA. The same approach applies to the application code and to any test benches that have to be generated for software and for hardware.
|
|