FPGA C Compiler on sourceforge.net (TMCC derivative)

Jim Granville wrote:
> I like this oxymoron, on p5 :
> " * Companies create proprietary ANSI C-based language
>    * Languages do not have all ANSI C features

I don't think that's an oxymoron.  Just because a language is proprietary,
it does not mean it can't be based on ANSI C.

Sure it might read a bit funny - but we've all tried to cram too much onto
slides before.

> and this very important point
>    * Must adhere to specific programming ?style? for maximum optimization

Yes.  That's a very important point.

>   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.

I think you've got the wrong end of the stick there.

This isn't about taking arbitrary C code and compiling it to an FPGA.
You simply can't do that.  

Reason:  It's possible to write architecture specific code (that is, code
specific to a particular ISA) in C.  Self-modifying code and dynamic code
generation are examples of this.

For example, linkers and JIT compilers modify code which is then executed. 
You couldn't compile that efficiently to an FPGA - it would need the
re-synthesis every time code was modified..

Another reason is that a compiler can't guess which inner loops are program
'hot-spots', and thus good candidates for synthesis.  Such information is
application-domain specific.

Concisely:  the aim isn't to be able to take a program written by someone
who knows nothing about hardware (at least, not yet).  The aim is to be
able to develop hardware acceleration for a given algorithm.  

One advantage of C-based languages is that when trying to accelerate an
algorithm, it might not be clear which parts to synthesise - this requiring
some trial-and-error for difficult problems, and also being dependent on
some rather arbitrary parameters.  It's easier to move a computation unit
from software to hardware, or vice-versa, if the languages are similar.
There's also a whole raft of software based optimisations that can be
applied before the hardware optimisations even get a look in.

Another, is that for some projects, a C simulation is developed to check the
algorithms anyway.  For example, Timothy Miller did a software model for
the OpenGraphics project.  The practise isn't uncommon.

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

For the reasons above, it is - in general - necessary to provide a compiler
with some pragmas or other hints that describe what code would be a good
candidate for synthesis.

However, the solutions are often close enough to C that it's possible to
execute the program entirely in software, as well as compile to a
object code/bitstream target.  That's useful for the intended applications.

Nobody's pretending C-based synthesis is a complete replacement for HDL,
only that for some applications/projects it's a very compelling
alternative.

Martin

Eric Smith wrote:
> Still, if you're going to use reconfigurable computing, surely each
> configuration is a hardware design, and much better expressed in a
> language optimized for hardware design, rather than a language optimized
> for strictly sequential operation.

Actually, Handel-C (Celoxica), Impulse-C (derivative of StreamsC), ASH,
SA-C, HarPE, Spark, and even FpgaC all take a subset of the language
and to various degrees present extensions to the language to be a
language optimized for hardware design, some much more rigorous than
others.

Celoxica's long term goal is to compete 1 on 1 with VHDL/Verilog and
they are doing pretty well at it so far.

Impules-C with it's VHDL backend is ment to take communication based
designs (AKA RPC or MPI or other cluster based communication library)
and use FPGA's as computing nodes with clearly defined streams to build
pipelined system designs. The use of the VHDL backend leaves lots of
room to optimized the resulting design at a low level.

SA-C and ASH are clearly targeting high performance designs, actually
large high performance designs, with the intent to get as good a
hardware fit as VHDL/Verilog or better by picking a specification
language higher than VHDL/Verilog and lower than a full C/C++ which is
highly optimizable to give a better design yield than mid-level
experienced coders would get with VHDL/Verilog. Actually all the C HLL
offerings pretty much share this goal of trying to do better than the
average VHDL/Verilog coder.

ASH and HarPE go after optimizations that even a skilled VHDL/Verilog
coder are likely to miss, or even decide to avoid in the effort to
leave the VHDL/Verilog code readable and maintainable.

Martin Ellis wrote:
> This isn't about taking arbitrary C code and compiling it to an FPGA.
> You simply can't do that.

Actually you could, and in the future when a few million luts are
cheaper
than a fairly fast CPU, some people probably will by using mixed
technologies
inside the FPGA ... a combination of application specific cpu cores and
generic netlists. Already Xilinx is targeting that market with PPC
cores and
micro blaze cores as an addition to the FPGA logic synthesis.

> Another reason is that a compiler can't guess which inner loops are program
> 'hot-spots', and thus good candidates for synthesis.  Such information is
> application-domain specific.

Actually, that is only partially true. It's been common for some time
to use
profiler input from actual runs to guide the compiler optimations for
later builds.
This happens to be one sweet spot that lcc exploits to beat gcc and pcc
executables. See
http://www.cs.princeton.edu/software/lcc/doc/linux.html

> However, the solutions are often close enough to C that it's possible to
> execute the program entirely in software, as well as compile to a
> object code/bitstream target.  That's useful for the intended applications.

Actually, it's very easy to write C to the subset implemented by a
particular
C to netlist HDL, that with a few #ifdef's is usable in either
environment, and
can accellerate development testing and debugging by doing most, if not
all,
the high level debugging in a well structured source code debugging
environment.

Others take it a step farther, and use rigourous type checking combined
with
super "lint" tools that provide verifiable correct construction
checking. In a
lot of ways, the original C++ development was exactly that, and was
implemented
as a front end preprocessor for standard C which was specifically ment
to be
only lightly typed so that it was a productive low level systems
programming
language only marginally higher level than PDP-11 assembly language.

It's actually fairly easy to code in C++ with abstract types that
directly implement
(IE emulate) the abstract hardware types that would result after
synthesis to
yield a strict HLL development environment with strict typing and
verifiable
designs and still translate to a subset dialect of C (or Verilog) for
synthesis.

> Nobody's pretending C-based synthesis is a complete replacement for HDL,
> only that for some applications/projects it's a very compelling
> alternative.

Choke, cough .... ummmm ... Celoxica, ASH, and a few other projects
really have
that goal. Celoxica has very clear guidelines, just as VHDL and Verilog
have, to
allow the coder to understand just what registers and logic will be
instantiated.

When you stop and think about it ... there is very little difference
between the
coding syntax of Handel-C and a subset of Verilog.

air_bits@yahoo.com wrote:
> Martin Ellis wrote:
>> This isn't about taking arbitrary C code and compiling it to an FPGA.
>> You simply can't do that.
> 
> Actually you could, and in the future when a few million luts are
> cheaper than a fairly fast CPU, some people probably will by using mixed
> technologies inside the FPGA ... a combination of application specific cpu
> cores and generic netlists. Already Xilinx is targeting that market with
> PPC cores and micro blaze cores as an addition to the FPGA logic 
> synthesis. 

Um.  Go back to the self-modifying code example and you'll see that it can't
always work.  To some extent, I agree with you, but the programs *have* to
be sensible and well behaved (type safe to some extent).

And that excludes *arbitrary* C.

>> Another reason is that a compiler can't guess which inner loops are
>> program 'hot-spots', and thus good candidates for synthesis.  Such 
>> information is application-domain specific.

> It's been common for some time to use profiler input from actual runs to
> guide the compiler optimations for later builds.

Yes, I know about this technique, and I thought about mentioning it here,
but didn't for brevity.  I don't call that fully automatic though.  You
need to seed it with some appropriate test data.

>> However, the solutions are often close enough to C that it's possible to
>> execute the program entirely in software, as well as compile to a
>> object code/bitstream target.  That's useful for the intended
>> applications.
> 
> Actually, it's very easy to write C to the subset implemented by a
> particular C to netlist HDL, that with a few #ifdef's is usable in either
> environment, and can accellerate development testing and debugging by
> doing most, if not all, the high level debugging in a well structured
> source code debugging environment.

That's exactly what I'm arguing.  Why are you arguing with me?

<!-- Snip further stuff about type-safety and C++ -->

>> Nobody's pretending C-based synthesis is a complete replacement for HDL,
>> only that for some applications/projects it's a very compelling
>> alternative.

> Choke, cough .... ummmm ... Celoxica, ASH, and a few other projects
> really have that goal. Celoxica has very clear guidelines, just as VHDL 
> and Verilog have, to allow the coder to understand just what registers and 
> logic will be instantiated.

As far as I know, Celoxica's products and similar offerings only target
digital designs for FPGAs.  

I'm not aware of any C-based language that was intended to cover ASIC
manufacture, or that would cover, say the 'Standard VHDL Analog and
Mixed-Signal Extensions' for example.

I could be very wrong there, and I'd be interested to know if they do intend
to target those aspects of HDLs though, if you can point me at any
references.

> When you stop and think about it ... there is very little difference
> between the coding syntax of Handel-C and a subset of Verilog.

Sure.  The syntax is very similar, but syntax is normally the least
interesting part of a language.


Martin

Robin Bruce wrote:

<snip>
> 
>>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.

Which has a lot in common with the ASM-HLL debates on microcontrollers.

The best solutions will come from a mix of tools
- but the sad reality is marketing dept drive is to push the hot new 
thing, as a silver bullet, and any suggestions or examples of mixing 
HLL/HDL, might be seen as admitting that their hot-new-thing is not 
actually the universal new tool....

There is another, more recent shift in FPGA's, which means
a 'Sea of DSP' deployed in the FPGA, and that is missing from
this link:
"Survey of C-based Application Mapping Tools for Reconfigurable Computing"
http://klabs.org/mapld05/program_sessions/session_c.html

  The HLL -> HDL path, misses the alternative of HLL -> FPGA Running HLL
amd the best tool set, will be one that allows a softer migration
between Opcodes and Registers.

  The next generation FPGA will be interesting to watch, as we are
steadily getting more coarse & complex blocks, in BlockRAM and
DSP-able blocks, with each release.
  This may outflank the efforts to create C -> registers ?

-jg

Robin Bruce wrote:
> 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

<snip>

> 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.

Or cynically speaking, we may just get bigger, faster and cheaper FPGAs, 
so that it doesn't really *matter* how efficient you are, merely that 
you're in the ballpark.  I think this has happened to a certain extent 
in the software world anyway...

Jeremy

Robin Bruce wrote:

>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.
>
>  
>
What tools would those be?  I've yet to see a tool that will take C 
code  that has not been so badly bastardized that it no longer looks 
much like C code and turn out even half decent hardware.  All of them 
require proprietary extensions to the C language to sufficiently 
describe hardware, as well as a very specific and stilted programming 
style that is as foriegn to C programmers as VHDL or verilog is.

-- 
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  

 "They that give up essential liberty to obtain a little 
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759

Ray Andraka wrote:
> What tools would those be?  I've yet to see a tool that will take C
> code  that has not been so badly bastardized that it no longer looks
> much like C code and turn out even half decent hardware.  All of them
> require proprietary extensions to the C language to sufficiently
> describe hardware, as well as a very specific and stilted programming
> style that is as foriegn to C programmers as VHDL or verilog is.

Which is very true, Celoxica being a prime example as code written for
their target as an HDL would be very tough to get to run on a RISC/CISC
machine and do anything meaningful.

You have to move up the food chain to a C++ design with heavy operator
overloading before you can get close to having the same source target
both enviroments if you are going to introduce HDL features into C. Std
C
just lacks the native types that get introduced with HDL features in
Handel-C.

SO, that leaves two distinctly different camps each tring to use the
same or
similar tools for two opposite goals ... the HDL guys designing
hardware, and
the reconfigurable computing guys just trying to gain a faster
computing platform
with FPGAs.

Personally, I'm comfortable with using VHDL/Verilog for HDL and a
fairly generic
C to netlist tool (FpgaC) for general reconfigurable computing, and a
mix of tools for gluing
projects togather (SoC's).

The which HDL is better debate is pretty much preference and
requirements based,
and impossible to win as a general case.

I do think we will see HLLs that target particular techologies that are
well defined and
difficult to easily code ... the whole pipelined data path problem for
distributed arithmetic
and filters is already shaping up that way with core generators (which
are in fact simple
forms based HLLs).

On 3 Nov 2005 12:15:30 -0800
air_bits@yahoo.com wrote:

> 
> Martin Ellis wrote:
> > Nobody's pretending C-based synthesis is a complete replacement
> > for HDL, only that for some applications/projects it's a very
> > compelling alternative.
> 
> Choke, cough .... ummmm ... Celoxica, ASH, and a few other projects
> really have that goal. Celoxica has very clear guidelines, just as
> VHDL and Verilog have, to allow the coder to understand just what
> registers and logic will be instantiated.

If by ASH you mean the application specific hardware project run by
Seth Goldstein and Mihai Budiu (until he graduated) at CMU, then you
have gotten the wrong impression.  I spent a semester in that research
group, and they most certainly do not intend to replace HDLs with C.
They have developed some very interesting compiler technologies that
can generate surprisingly efficient circuits from nearly arbitrary C
code, but even they wouldn't claim that C is an appropriate
replacement for HDLs in all cases.  They are spinning their compiler
as a tool that can be used by many more people than traditional HDL
synthesis tools, but the quality of the circuits they produce is still
far from optimized HDL-based designs.

Benjamin

Ray,

OK, maybe I should rephrase what I said, reading it again myself I
don't quite agree with it :). What I meant was that there are tools out
there that can map HLL well to hardware. I didn't mean to suggest that
they are ANSI C. I realise it's a bit of an abuse of the language to
describe these things as C, but I tend to describe the C-inspired
languages of these tools as C, and talk about ANSI C when I want to
make it clear I'm talking about canonical C.

It does seem that most of the tools out there are extensions to C. I
should say at this point that I've never used any of the tools that
have been discussed so far on this board, so I'll leave it to someone
else to talk about how close they are to C. I'm a research engineer
based in Nallatech, and I've been working with a tool being developed
there, DIME-C. I can safely say that DIME-C is to all intents and
purposes a subset of C, so everything you do in it can be compiled with
a gcc compiler. You can't have pointers, and you have to go round the
houses sometimes to avoid breaking your pipelines, but it's definitely
recognisable as C. If anyone is particularly interested, I could send
them some examples of the code. I don't want to bring DIME-C into the
debate though, I'm interested in finding out more about what's out
there, rather than in doing marketing :)

Cheers,

Robin