FPGA C Compiler on sourceforge.net (TMCC derivative)

Jim Granville wrote:
>   How about some examples, of some real applications, that can be coded
> in either, and the resulting source examples, and the FPGA resource
> mapping that results ?

Here's a reference that was posted here a while ago and I'm just following
up just now:

"Survey of C-based Application Mapping Tools for Reconfigurable Computing"
http://klabs.org/mapld05/program_sessions/session_c.html

On p14, the C-based implementation performs faster than the VHDL
implementation, despite the VHDL being developed after 'semester-long
endeavor into algorithm?s parallelism'.

They point to one of their own references that describes the 
implementation, but I guess you'd probably need to ask them for the
resulting source.

I guess Celoxica can probably give you some references to C-based examples
too.

Note that this sort of example is a more likely application in the HPC
community rather than the hardware design community per se.

Martin

I think we have to accept that high-level languages are going to be the
future for FPGAs. Not to say that HDLs will be replaced entirely, but
they'll be largely supplanted by the HLLs. Algorithms are easier to
verify: testing can be done using a software compiler and, providing
you can trust your tools and hardware infrastructure, you shouldn't
need to do extensive hardware testing of the implemented algorithm. Why
should we want to know what's going on inside of the FPGA? Development
time too is vastly reduced.

I think C has been selected as the starting point for most HLL-to-HDL
tools not because of its eminent suitability for the task, but because
it decreases the pain in switching to the new tool. C syntax is
familiar, it's a good jumping-on point. However, my experience in using
these tools tells me that hopes for massive re-use of legacy code are
still very much a pipe-dream. You will still have to understand the
underlying hardware. You will have to understand the spatial, temporal
and memory tradeoffs, and understand how to infer the pipelining and
parallelism that is most suitable. What HLLs free you up from is the
need to fiddle about with the timing on pipelines and other such
details. I can change the mix of ALUs in a complex pipelined algorithm
easily and painlessly. I don't need to go and manually re-time my
pipeline to account for the changes (and so know I won't make an
off-by-one error, introducing a fiendish bug).

First generation tools are far from perfect, but they will see use
because they significantly decrease development time. Your HLL-designed
system may not be as efficient as the best possible VHDL design, but if
it's good enough and you get to market months before the competition,
you'll come out on top.

Once the user base has been built up, I see the tools maturing and
becoming less and less C-like. New languages will be demanded to better
express parallelism and pipelining and to account for heterogeneous
processing units and memory structures.

Sorry if I've gone on a bit... :)

Robin

air_bits@yahoo.com schrieb:
> Eric Smith wrote:
> 
>>That doesn't explain *why* it's an excellent alternative.  I can just
>>as easily state that "C provides a terrible alternative to VHDL/Verilog
>>for algorithmic expression of tasks targetting FPGAs for reconfigurable
>>computing".  So why is their statement any more accurate than mine?
> 
> 
> There are probably a few hundred billion statements of C/C++ IP for
> designs which
> contain easily reusable code segments (IE cores) in nearly every
> application
> area. Probably a few trillion, when you include privately held IP in
> addition
> to what is on SourceForge and other open source depositories.
Ok, you want to map GUIs, database engines, programming languages a.s.o.
directly on an FPGA. Perhaps it makes sense to map 1% of all
application to an FPGA.FPGAs offer massive parallelism, therefore only
application/problems which utilize this parallelism should be
implemented in FPGAs. They are all a kind of communication system or
signal processing system.

> 
> I suspect, the total IP coded in VHDL/Verilog is three to four orders
> of magnitude less.
May be, but it uses the hardware very efficiently
> 
> So that is three reasons why C can be an excellent althernative for
> reconfigurable computing projects, and for the home hobbyist that
> already knows C and would like to use an FPGA for a reconfigurable
> platform for their robotic or other project.
Never, since most of them think in sequential algorithms and don't
understand the advantages of hardware.

Bye Tom

>Never, since most of them think in sequential algorithms and don't
>understand the advantages of hardware.

What are you saying? That people who don't understand hardware don't
make good hardware designs? Why would that make VHDL better than a
HLL-to-VHDL tool?

I could just as easily say that people who've never heard of algorithms
don't understand the advantages of a microprocessor, therefore
assembler is better than C. It's a non sequitur...

Thomas Reinemann wrote:

> FPGAs offer massive parallelism, therefore only
> application/problems which utilize this parallelism should be
> implemented in FPGAs. They are all a kind of communication system or
> signal processing system.

All?  Perhaps you should read these for other high-performance computing
applications that can be accelerated using FPGAs:

@MISC{compton00reconfigurable,
  author = {K. Compton and S. Hauck},
  title = {Reconfigurable Computing: A Survey of Systems and Software},
  year = {2000},
  text = {K. Compton, S. Hauck, Reconfigurable Computing: A Survey
         of Systems and Software, submitted to ACM Computing Surveys, 2000.},
  url = {http://citeseer.nj.nec.com/compton00reconfigurable.html},
}

@ARTICLE{hauck98roles,
  author = {Scott Hauck},
  title = {{The Roles of FPGAs in Reprogrammable Systems}},
  journal = {Proceedings of the IEEE},
  year = {1998},
  volume = {86},
  number = {4},
  pages = {615--638},
  month = {Apr},
  url = {http://citeseer.nj.nec.com/hauck98roles.html},
}

>> I suspect, the total IP coded in VHDL/Verilog is three to four orders
>> of magnitude less.

> May be, but it uses the hardware very efficiently

Isn't that what people said about assembly language?  And GOTO statements?

>> So that is three reasons why C can be an excellent althernative for
>> reconfigurable computing projects, and for the home hobbyist that
>> already knows C and would like to use an FPGA for a reconfigurable
>> platform for their robotic or other project.

> Never, since most of them think in sequential algorithms and don't
> understand the advantages of hardware.

Yawn.  I wonder when people from traditional hardware design backgrounds
will get over this kind of attitude.

So what if some hobbyists don't 'get' it at first?  People aren't born
hardware designers, nor software programmers.  Are you really saying you've
never made any mistakes while you were learning?

It's not like using a HLL for FPGA design is only useful for hobbyists
anyway.

Martin

Martin Ellis wrote:
> Thomas Reinemann wrote:
> >> I suspect, the total IP coded in VHDL/Verilog is three to four orders
> >> of magnitude less.
>
> > May be, but it uses the hardware very efficiently
>
> Isn't that what people said about assembly language?  And GOTO statements?

Isn't that what people said about Schematic based designs when HDLs
popped up?

The reality is the HLLs targeting reconfigurable computing on FPGAs get
very good
fits already, just as HDLs do simply because the back end optimizers in
the tool
chains for space/time traceoffs, partitioning, mapping, and routing
yield the same
benefits for HLLs.  The biggest differences is that most HLLs hide
implementation
details that create design risks, which are considered expert tools for
HDL users, thus
allowing coders with less hardware experience the ability to realize
functional designs
with a small performace penalty. Given that the speed ups from a
RISC/CISC architecture
CPU to FPGAs that can be obtained where there is parallism, are often
one to three
orders of magnitude, this small efficiency loss is completely mouse
nuts. To gain that
extra effieciency would require an experienced HDL coder and sigificant
delays in the
development schedule, each of which have marginal cost benefit gains in
comparison
to the huge gains made by using reconfigurable computing with FPGAs.

Heck, Impulse C is said to use VHDL as the netlist technology to
optimize the fit.
FpgaC even has some experimental code that uses Verilog as the netlist
technology
instead of XNF. Even the XNF outputs allow for respresenting the output
design as
basic gates or packed LUTs with equations allowing the user to decide
which will
do the best technology mapping. Each of these choices gives the backend
tool chain
considerable room to optimize the HLL produced netlist for the target
technology, just
as VHDL and Verilog designs expect.

> It's not like using a HLL for FPGA design is only useful for hobbyists
> anyway.

Celoxica C and Impluse C are becoming thriving products with expensive
high
value tool chains. Others are likely to become successful as well, and
it's very
likely that Xilinx or Altera or other FPGA company will offer a C
HLL/HDL as their
flagship tool chain as reconfigurable computing takes off and drives
the high end
FPGA revenues.  Some expect that may be in the form of System C if that
techology
really takes off as a system level design specification tool.

Doesn't matter. There are few low cost C HLL/HDL tools available for
students,
hobbyists, and low budget design shops. The total cost of the Celoxica
tool chain
for a modest sized development team can easily run the cost of several
engineers
for the multiple licenses needed. Small 1-10 man shops like mine simply
can not
afford Celoxica licenses, so I've used a mix of TMCC and Verilog for
several
projects to meet my budget.

There are several interesting specialty C HLL/HDL research tools that
knock your socks
off. Several data flow C compilers have been presented at conferences
that would be
awesome for some projects if they ever became a real product that was
affordable or released GPL (search for ROCCC and PiCoGA projects, and
work by Oskar Mencer). Sarah's
partial evaluation C compiler called HARPE generates some awesome logic
optimizations
which coupled with her Async work would make a killer tool to add to
ones tool chain for
certain types of projects (see
http://findatlantis.com/syncpe_paper.pdf). And Mihai Budiu's
research at CMU which produced the ASH tool chain (see
http://www.cs.cmu.edu/~mihaib/research/research.html ) Other projects
like SA-C at ColoState.edu (see http://www.cs.colostate.edu/cameron/)
and Spark at UCSD (see
http://mesl.ucsd.edu/spark/) and a few dozen others are all exploring
and showing good solid gains in how to map HLLs to FPGA and win big.

C as an HLL to netlist toolchain is here to stay, and probably only get
better with time.
C as an HDL (in the form of Handel-C by Celoxica) is clearly here.

Robin Bruce wrote:
> >Never, since most of them think in sequential algorithms and don't
> >understand the advantages of hardware.
>
> What are you saying? That people who don't understand hardware don't
> make good hardware designs?

That's essentially it.  Let's define "good" hardware designs: best use
of hardware resources with highest performance (clock speed).

> Why would that make VHDL better than a HLL-to-VHDL tool?

Because VHDL and Verilog are designed from the ground up to take
advantage of the parallelism inherent in hardware designs.  Sequential
programming languages such as C are not, and much hackery has to happen
for C to map well to hardware.

As an example, think about how you could implement a FIR filter in C
for a DSP, and then think about how you could implement the same filter
on an FPGA.  I suppose one could write a tool that's smart enough to
translate the C description of a FIR filter into efficient hardware but
one presumes that sufficient restraints would need to be put into the
"hardware C" for the tools to work well.  But if the intent is to take
high-level C developed by a software guy and have it map to hardware as
well as it runs on a DSP, well, I just think you'll leave a lot of FPGA
peformance on the table.

> I could just as easily say that people who've never heard of algorithms
> don't understand the advantages of a microprocessor, therefore
> assembler is better than C. It's a non sequitur...

You could, but the statement is irrelevant.

-a

Martin Ellis wrote:
> Jim Granville wrote:
> 
>>  How about some examples, of some real applications, that can be coded
>>in either, and the resulting source examples, and the FPGA resource
>>mapping that results ?
> 
> 
> Here's a reference that was posted here a while ago and I'm just following
> up just now:
> 
> "Survey of C-based Application Mapping Tools for Reconfigurable Computing"
> http://klabs.org/mapld05/program_sessions/session_c.html
> 
> On p14, the C-based implementation performs faster than the VHDL
> implementation, despite the VHDL being developed after 'semester-long
> endeavor into algorithm?s parallelism'.
<snip>

Thanks, very interesting link.

I like this oxymoron, on p5 :
" * Companies create proprietary ANSI C-based language
   * Languages do not have all ANSI C features
and this very important point
   * Must adhere to specific programming &#4294967295;style&#4294967295; for maximum optimization
"

  The benchmarks are usefull - and show the choice is very much a lottery.
  One benchmark they did not give, was just what results were if Generic 
C, from a generic graduate, was thrown at these tools.

  Source snippets are important, because these solutions are not C, but 
C-based.  The devil is in the details....

-jg

I'm afraid if you throw generic C at these tools, it won't compile...

Andy,

firstly, you've misunderstood my post. The previous poster seemed to
suggest that there was some kind of link between people not
understanding hardware and HLLs being inferior to VHDL. I didn't see
what the level of experience of people who use HLLs has to do with
whether or not HLLs are superior to HDLs. This was what led to my
intentionally fatuous comment:
> I could just as easily say that people who've never heard of algorithms
> don't understand the advantages of a microprocessor, therefore
> assembler is better than C. It's a non sequitur...

OK, as for your other comments:
>> much hackery has to happen for C to map well to hardware.

well, much 'hackery' obviously has happened, as there are tools that
map C well to hardware. We're not talking about what might happen,
we're talking about what is happening.

>I suppose one could write a tool that's smart enough to
>translate the C description of a FIR filter into efficient hardware but
>one presumes that sufficient restraints would need to be put into the
>"hardware C" for the tools to work well.

Check slide 13 of Brian Hollands presentation from MAPLD, you'll find
all 3 HLL tools tested beat the VHDL for FIR implementation:

>But if the intent is to take
>high-level C developed by a software guy and have it map to hardware as
>well as it runs on a DSP, well, I just think you'll leave a lot of FPGA
>peformance on the table.

Who said that's what we're trying to do? We're talking about high-level
languages not so we can compile legacy code. We're doing it so we can
rapidly infer reliable hardware using a more concise expression than
that achieved using HDLs while paying a minimal price in lost potential
performance.