( DAC 03 Item 9 ) ----------------------------------------------- [ 01/20/04 ]
Subject: Celoxica DK Handel-C
ODD FELLOW: The one odd bird in the entire odd family of C based EDA tools
is Celoxica. Instead of standardizing on SystemC, Celoxica DK supports
their own weird "Handel-C". Instead of focusing on the big ASICs that most
architects are tasked to design, DK is mostly an FPGA tool. Regardless,
like those weird old men who obsess over miniture model train villages,
Celoxica does have its own quirky cult following. Hear them roar here.
I did not attend DAC, but I invited Celoxica to our facility to present
their DK technology to our engineers. Our engineers gave Celoxica an
interesting test, which they performed quite well.
- Bruce Fette of General Dynamics
This is what I know from using Celoxica DK. DK installed seamlessly and
worked very well in conjunction with Microsoft Visual Studio. It even
configured the compiler for me, which being mostly a hardware guy I
really appreciated.
DK appears to me to be about a 3 to 1 improvement in the amount of
functionality I can generate vs Verilog. I don't know if this is unique
to Celoxica, or just an improvement using a higher level language.
Celoxica generates a netlist targeted specifically to the target device,
optimized for the internal features like block RAM and adders /
multipliers and such. I found it extremely straightforward to envoke
the use of these devices and very few suprises in the implementation
chosen. I know some tools go through an intermediate stage of VHDL or
Verilog. Celoxica can do this to, but something gets lost in the
translation. I think this direct to target hardware is a valuable
feature.
The resulting implementation using the Xilinx P&R tools resulted
in functional densities and speeds I'd expect using a tool like
Verilog. And DK did not require a lot of "horsing" to get it to come
out as I would expect. My experience with Verilog and the Xilinx tools
was that you have to "work the language" to convince the tools to create
the implementation as you would envision. Celoxica's DK didn't require
any of that.
I was also pleased with Celoxica's documentation and help files. I was
a "demo" user which means I didn't get the training that comes with a
purchased suite. In my spare time in the evenings, I was able to pick
DK up and get started. I have not done anything really sophisticated,
nor tried any of the embedded processor stuff yet, but I've been really
suprised with how easy it was to do some things.
The only "weakness" I can see is that I don't know how portable any of
this is. This SystemC/Handel-C doesn't seem to be all that universal
yet. Of course that's the way it has been anyway. Once you add in just
the right Verilog to get it to use the adders in a Xilinx chip, it turns
to crap if you just dump it into an Altera chip. I'm not sure anything
is truly portable.
- Charles Hill of Motorola
I have been guiding several student projects that attempt to get to
grips with the Celoxica technology. I selected DK after rave reviews
from WindRiver and Xilinx, and also because I have known several of the
originators behind Handel-C for many years since becoming
attendant/participant of the WoTUG conferences on parallel programming.
I liked the CSP background behind the Celoxica tools, being used to
thinking in that way. Also, from a software point of view it is easier
to recode algorithms in pseudo code in Handel-C than to do the same in
VHDL. I could see the benefits of being able to describe a system in
Handel-C, where deciding on implementation in hardware or software can be
put off until later.
Working for the software company that Philips TASS is, I considered this
the easiest route to success. I did visit one or two workshops on
SystemC, but found it less attractive. This may be my ignorance, but
for people that know little about hardware, the Celoxica route of just
sticking to Handel-C is sufficient to do interesting things on a
Spartan-II 200K gate device on Celoxica's RC-100 board. So far we have
done 6 student projects, and the results get better and better.
The project about to end (2 polytechnic students, 5 months project)
implemented 128-point FFT on 16-bit PCM audio data, coefficient
manipulation, followed by inverse FFT, together with real-time VGA
display of input waveform and spectral contents, all in real-time on
this chip. Also the ADC and DAC are inside the chip.
Using 4 windows over the 128-sample input data gets smoother results. I
didn't have to explain anything to them other than where the PC was with
the DK and Xilinx Alliance to process the EDIF output of DK. They did
use almost all slices of the device, but still feel comfortable enough
that they should be able to squeeze some more functionality into it. So
from the point of ease of use it really is easy to use.
I recently saw a talk about PrecisionC, and was intrigued by its
possibilities, but I was also afraid that it would be quite too much for
students to deal with in just a few months time.
- Herman Roebbers of Philips
Celoxica sells a tool that translates their own version of C (Handel-C)
into RTL VHDL or Verilog or into EDIF for Xilinx or Altera. They also
have a tool that helps with hardware/software partitioning.
- John Weiland of Intrinsix
I saw the Celoxica DK demo at DAC and it was fairly impressive. They
demonstrated their co-development tool in a PowerPC application; it
basically targeting the PPC405 embedded in the Xilinx V2Pro). Their
demo essentially used function calls to partition the design between
hardware tasks and software tasks.
The example had a specific task being performed by hardware in one
simulation, then they inserted a PPC405 model and partitioned the same
task to the processor by using a different parameter in a function call.
The results would then come together in a common simulation environment.
Celoxica also showed the basic development process of the Celoxica tool
suite. Taking C based designs and inserting "par" statements to infer
parallelism. The design can then be taken to RTL or to an FPGA tool
suite for place & route. The RTL option was demonstrated and the
readability was less than good. I would hate to have to debug or use a
design that came from generated RTL.
Our company does quite a bit of ASIC and FPGA designs. I can see the
use for DK in FPGAs for test equipment or fast prototyping but I suspect
that ASIC design using this tool would be more challenging. If you go
through the ASIC flow you're forced to use the machine generated RTL. I
can see instances where low level design changes will be necessary to
resolve ASIC backend closure issues, and I question whether there is
sufficient control at the high order C level to make low level (gate,
buffer, fanout) modifications that are needed to resolve ASIC backend
issues. If not it will force the designer to make the changes at the
RTL level and thus break the one-to-one relationship between source C
code and final design.
In general, Celoxica's tools look powerful for fast prototyping in FPGAs
for demos or test equipment. Especially for algorithms that already
exist in C. They also have the ability to create Program Abstraction
Layer (PAL). This is like a board support package that can be created
for a specific board architecture. Makes interfacing to external
resources easier on the designer. Their tool was certainly the most
mature that we've seen. Maybe it was their good cookies but we ended up
buying a seat. Talk to me in about 3 months and I'll probably be able
to give you more scary details of our PAL development effort.
We also reviewed Mentor PrecisionC and Synopsys SystemC.
PrecisionC was very interesting. More of an automated tool that finds
parallelism from the design rather than leaving it up to the designer to
find it. It had a very impressive dependency plot (similar to a Gantt
chart) that showed the timing dependence of each element of the design.
PrecisionC was also very powerful in showing the resources and
performance of a specific design to help the designer try to balance
performance versus area. What we didn't see is what troubled us. From
what we could tell there was no way to define C functions and call them
out in routines. It defeats some of the purpose for using C in the
first place.
I also believe, and I may be wrong, a user would have to create RTL
wrappers around each module to connect them together. We did not see
the ability to create a board support package either. The software is
also immature and has a price tag in the 6 figures. A little too scary
for my taste.
Synopsys SystemC was interesting from a simulation speed standpoint, but
that's about the only thing going for it. The fact that you still need
to code at the RTL level in order to synthesize a design makes it
unattractive for what we were looking for. On the upside, Synopsys
definitely had the best food!"
- Paul Murray of SEAKR Engineering
Here is a list of strengths/weaknesses of Handel-C we have found at
Tarari. Disclaimer, we are business partners with Celoxica.
Strengths
* Shorter time to convert algorithms to working hardware
* Integrated simulation/synthesis tool
* Shorter ramp-up time for inexperienced HW or SW engineers
* Signed/unsigned integer manipulation is usually easy
* Recursive macros are pretty powerful
* Register/bus width inference sometimes makes generic code easy
to write
Weaknesses
* Proprietary language
* Difficult to describe low level operations
* Difficult to optimize for timing
* No clear path from FPGA to ASIC
- Tom Trela of Tarari, Inc.
I don't know my company's legal requirements as far as my making
recommendations or suggestions on a private company's products.
What I will say, because this is factual and not based on subjective
opinion or bias, is that we are not renewing our DK1 license this year.
- Neall Doren of Sandia National Laboratories
I was not impressed with Celoxica's DK. The floating-point library they
told me was working was in fact quite a mess and did not work. For the
amount of money they were asking, it's overpriced by a factor of 10. I
will not be investing any more time or money into that tool.
- [ An Anon Engineer ]
|
|
