FPGA C Compiler on sourceforge.net (TMCC derivative)

Jim,

I agree with you about the value of mixing and matching HLL and HDL
solutions in your system. You might want to design the core of your
algorithm using an HLL tool, then link it up to control and memory
systems that you've designed using HDL.

I also can see the constant changing of the underlying hardware as
being a challenge to those who are developing C-to-hardware tools. I
think perhaps it favours those who target their systems at a single
architecture, like SRC with their Carte programming environment.
HandelC has seen a lot of real success, the most notable in my mind is
it being used in an effort by Lockheed Martin to create a space system
to dock with Hubble
(http://klabs.org/mapld05/presento/220_feifarek_p.ppt). My
understanding of HandelC is that the basic package contains generic HDL
routines for the common operations (data array storage and retrieval,
fixed-point multiplication etc.) bu the user is given the option to
supplement this with implementation specific routines. So in Xilinx
V-II this would be BRAMs for data array storage and use of the 18x18
multipliers for the fixed-point stuff.

With each new generation of FPGA, you'll need to update your underlying
library routines. As I recall Peter Alfke saying at this year's FPL, to
get the best out of FPGAs, you need to target your architectures,
generic just won't cut it (apologies to Peter if that's not what he was
getting at).

So I guess I agree with you Jim, in that C -> registers is not the best
approach.

Apologies for my ignorance, but can I ask you to expand on "alternative
of HLL -> FPGA Running HLL amd the best tool set". I wasn't sure what
you meant.

Cheers,

Robin

air_bits@yahoo.com schrieb:
> There are a few hundred thousand engineers on the planet that can
> express large complex algorithms in C, 
Yes, but Java and C# have essentially the same syntax without any of the
defunct side effect issues that make C so damn hard to synthesize but do
not have any real use anyway.

But instead of using an existing standard lagnuage that can be
synthesized they define a new language of their own and call it "C, but
you are not allowed to use this and that"

BTW, VHDL has the same issues.

> There are clear advantages to being able write, test, and debug large
> complex algorithms on a traditional processor with a source code
> debugger and moving the nearly finished product to FPGAs for deployment
> and performance. So access to advanced software development tools is
> two.

Yes, but it also is a clear advantage to have a language that allows for
explicit parallelism, processes, signals and events on a finer grain
that threads.

Such languages exist for traditional processors for a long time now.
Algol comes to mind as a very old example.
You know, it is very easy to map explicit parallelism on a serial
machine. But it is very hard to extract parallelism from a serial
description.

I am a big fan of high level synthesis from algorithmic descriptions
that do not describe the hardware details, but I am sure that C is "A
Really Bad Choice (TM)".

Heck, C is a really bad choice for serial CPUs to begin with. If you
build hardware, you want your compiler to do as many compile time checks
as possible. There's not much that you can catch at compile time with
plain C.


Kolja Sulimma

Benjamin Ylvisaker wrote:
> 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.

I was not suggesting that C syntax HDL's will obsolete VHDL/Verilog
and other technology specific HDL's, but just as you clearly state the
goal is to produce "efficient circuits from nearly arbitrary C" which
from
the presentations by the group are very very close to that of a good
HDL
with a good to excellent coder. With FPGAs increasing in size at
roughly
the same Moore's Law rate, and similar performance increases, the end
result is that "surprisingly efficient circuits from nearly arbitrary
C" is more
than good enough to replace VHDL/Verilog for the majority of
algorithmic
and systems level designs to allow faster time to market, with a larger
pool of talent (being able to draw on C coders), with good enough
performance
and fit so that expensive fine tuning and coding in VHDL/Verilog will
NOT
be required.

The clear intent is to produce acceptable circuits with a less talented
engineers for a variety of target applications ranging from full
systems to
reconfigurable computing.

Kolja Sulimma wrote:
> Yes, but Java and C# have essentially the same syntax without any of the
> defunct side effect issues that make C so damn hard to synthesize but do
> not have any real use anyway.

The issue is having to subset a language and it's expected runtime
environment.
Both Java and C# barrow heavilty from the same subset of C syntax, and
both
have similar problems of porting arbitrary code from a traditional
sequential
execution environment to FPGA's. The lack of "real addressable memory"
results in difficulties in dynamic allocation, and runtime
architectures that
expect pointers to create and manage data objects.

Starting a "my language is better than your language debate" is really
non-productive,
as the real test is does it exist in a usable form today for this
application, and the
assumption or assertions are in the end only validated by availability
and use as the
true test of what is the best for target applications. One clear
standard is access to
trained labor pools, as frequently the "best" tools for briliant
experienced engineers
create unmanagable complexities for less talented, skilled, experienced
engineers
that will have to maintain the project over it's life. Managing
concurrency has always
been a tough one for less skilled engineers unable to grasp global
system architecture
and state enough to protect from the hazards and deadlocks.

There is a lot of room in this new HLL to netlist market ... we would
ALL like to
see affordable usable tools that do a better job. Bitching that C tools
are not
to some higher standard is pretty non-productive, when the existing
broadly used
tools are at even a lower standard.

There are few affordable open source tools for students, hobbiests, and
small
development shops for FPGAs .... I don't see any that meet your minimum
requirements, maybe your talents will make them available?

>With FPGAs increasing in size at roughly the same Moore's Law rate, and similar >performance increases, the end result is that "surprisingly efficient circuits from nearly >arbitrary C" is more than good enough to replace VHDL/Verilog for the majority of >algorithmic and systems level designs to allow faster time to market, with a larger pool >of  talent (being able to draw on C coders), with good enough performance and fit so >that expensive fine tuning and coding in VHDL/Verilog will NOT be required.

Wow, that's a long sentence :) and one I broadly agree with. I'm not so
sure about the phrase "nearly arbitrary C". I don't know all the tools
though, so I'm presenting my limited experiences here, not what I think
is universally true... So no flaming. :)

Is there any tool out there that can produce code that rivals good VHDL
when written by a "C coder"? I'm currently working with a very bright
undergrad who has never used VHDL before, and I've got them using a
C-to-VHDL tool. To effectively use the tool, they're having to
understand why they need shortcuts that avoid "/, % and *" as much as
possible. They need to think about memory management in a very new way,
in a land where BRAM is not limitless. They're also having to consider
the differences between BRAM, SRAM and registered values and their
effects on performance. They need to understand what will break the
pipeline and what won't, what will result in big pipeline latency and
what won't. They need explanations as to why a few small changes can
quarter the final slice count. To work effectively you need to
understand what kind of hardware that you are inferring by what you
write. Two functionally equivalent statements can compile to  two very
different VHDL projects. In my experience, HLLs free you up from the
drudgeries of HDLs, but they don't yet free you up from the need for an
understanding of the underlying hardware. With nothing but a C
knowledge you can get something big and slow, but for small and fast,
you need to know what you're inferring.

Cheers,

Robin

Robin Bruce wrote:
>Two functionally equivalent statements can compile to  two very
> different VHDL projects. In my experience, HLLs free you up from the
> drudgeries of HDLs, but they don't yet free you up from the need for an
> understanding of the underlying hardware. With nothing but a C
> knowledge you can get something big and slow, but for small and fast,
> you need to know what you're inferring.

That's a clear problem, even with C coders and doing any kind of device
driver on a traditional system. The pool of C coders that understand
hardware
enough to write drivers is a small percentage of actual coders. The
difference
is that it's relatively easy to teach the high level aspects of
hardware from a
systems perspective to train new device driver writers and maintainers,
and
one good low level engineer can mentor some half dozen others with less
skill
and maintain the quality level necessary for production work. I've done
so on
several cross architecture porting projects with undergrad students.

I believe there is a similar leverage in using C coders for FPGA work,
you do
not need EE's with logic level design skills to develop fpga projects,
but you do
need to teach C coders about the hardware architecture models that the
HLL
is going to produce after synthesis. Even today it's necessary to teach
C coders
about cycle counting, as assembly language coding is no longer a basic
skill.
Performance sensitive designs require teaching about working sets,
cache
performance issues, CPU pipelines, and a number of issues that a
typical
C++ or other object oriented coder remains clueless about. There is a
continuous
design space:

   BitLevelLogic<===============================>AbstractAlgorithms

Schematic designs on the left, VHDL/Verilog somewhere left of center, C
based
HLLs somewhere just right of center, with better HLLs to come even
farther right
of center. EE's tend to design to the left of center, and HLL coders to
the right of
center under this model, and the better the HLL effieciently hides the
hardware, the
farther to the right we move.

So the bottom line, is that just as EE's were the entire computer
development staff
in the 50's, today EE's are a fraction of the product development team.
With FPGAs
becoming common along with HLLs we will see that same trend.

During the 70's we saw a lot of old salt EE's and Systems types crying
about HLLs
and computer performance, which is nearly a moot point today. Ditto for
EE's and
systems types that will be crying about large commodity FPGAs similarly
not being
effieciently used by HLLs generating FPGA designs from abstract
language tools.

Robin Bruce wrote:

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

Simple code examples and synthesis results is what is
missing from the web sites and discussions I have
seen. If you've got some, consider posting
a link so that all interested can have a look.

   -- Mike Treseler

Robin Bruce wrote:
> I'm a research engineer
> based in Nallatech, and I've been working with a tool being developed
> there, DIME-C.

For those that haven't looked at this stuff, it's the next generation
HLL
FPGA environment, two steps above C with a cute GUI based system level
abstraction tool .... very cool :)

http://www.nallatech.com/mediaLibrary/images/english/4063.pdf

Robin Bruce wrote:
> Jim,
> 
> Apologies for my ignorance, but can I ask you to expand on "alternative
> of HLL -> FPGA Running HLL amd the best tool set". I wasn't sure what
> you meant.

Jim Granville wrote:
>>  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. 

"FPGA Running HLL" is a terse way of saying a SoftCPU (can be DSP 
enhanced) running opcodes (ex HLL), on the FPGA. ie a FPGA CPU

eg NIOS has an interesting Opcode extension scheme - you can
code in C, run in C, and then grab ONLY the tight stuff for
expansion into hardware, and call with an opcode.

The FPGA vendors seem to be favouring the 'sea of DSP' and std
tool flows, over 'sea of programmers' approach :)

-jg

air_bits@yahoo.com schrieb:
> Kolja Sulimma wrote:
> 
>>Yes, but Java and C# have essentially the same syntax without any of the
>>defunct side effect issues that make C so damn hard to synthesize but do
>>not have any real use anyway.
> 
> 
> The issue is having to subset a language and it's expected runtime
> environment.
> Both Java and C# barrow heavilty from the same subset of C syntax, and
> both
> have similar problems of porting arbitrary code from a traditional
> sequential
> execution environment to FPGA's. The lack of "real addressable memory"
> results in difficulties in dynamic allocation, and runtime
> architectures that
> expect pointers to create and manage data objects.

You are perfectly right. As I wrote in my post I think that you need
some features like explicit parallelism that none of the mainstream
languages offer, albeit there are languages available that would be
suitable.

But apparently all those highly trained clever software engineers can
not be bothered to learn another language. At least this argument
allways comes up at that point. (Maybe I can find an engineer in india
that is still capable of learning?)
So if your really need C-syntax as many believe - I don't - at least use
a modern C derived language that is easier to compile.
With java essentially only the "new" operated is a problem. With C, well
look at the System-C restrictions.

On the other hand: What's so hard about dynamic allocation? Tell the
designer that it will be slow, and if he uses it simply synthesize to a
microblaze implementation. You will not meet the timing constraint, but
it can be synthesized.
Or even use profiling to find a typicall number of allocated objects and
create them in hardware. If more are used halt execution. That is
exeactly what a sequential processor would. You can't call malloc a
billion times in C and maybe you can not call it 16 times in hardware C.
It is the same type of constraint that is not imposed by the language
but by the implementation fabric and the designer needs to know the
capabilities of his system before implementing.


Kolja Sulimma