FPGA C Compiler on sourceforge.net (TMCC derivative)

Project released a beta based on an enhanced TMCC, and is looking for
help
to bring FpgaC up to a production stable level.

Home page at http://fpgac.sourceforge.net/
Project page at http://sourceforge.net/projects/fpgac

air_bits@yahoo.com wrote:

> Project released a beta based on an enhanced TMCC, and is looking for
> help
> to bring FpgaC up to a production stable level.
> 
> Home page at http://fpgac.sourceforge.net/
> Project page at http://sourceforge.net/projects/fpgac
> 

Why are those guys so keen on C ? Suggesting
compatibility with something while having least
readability ?

Rene

On a sunny day (2 Nov 2005 07:56:39 -0800) it happened air_bits@yahoo.com
wrote in <1130946999.695784.287900@g14g2000cwa.googlegroups.com>:

>Project released a beta based on an enhanced TMCC, and is looking for
>help
>to bring FpgaC up to a production stable level.
>
>Home page at http://fpgac.sourceforge.net/
>Project page at http://sourceforge.net/projects/fpgac
>
Interesting.
here is something to think about from the libc.info from gcc C.
maybe you already support these?
I recently found out it is better to use these in C then 'int' and 'short',
as some programs I wrote stopped working when compiled on AMD 64....
(header file structures with 'int' and 'short' and 'BYTE' ).

Integers
========

   The C language defines several integer data types: integer, short
integer, long integer, and character, all in both signed and unsigned
varieties.  The GNU C compiler extends the language to contain long
long integers as well.

   The C integer types were intended to allow code to be portable among
machines with different inherent data sizes (word sizes), so each type
may have different ranges on different machines.  The problem with this
is that a program often needs to be written for a particular range of
integers, and sometimes must be written for a particular size of
storage, regardless of what machine the program runs on.

   To address this problem, the GNU C library contains C type
definitions you can use to declare integers that meet your exact needs.
Because the GNU C library header files are customized to a specific
machine, your program source code doesn't have to be.

   These `typedef's are in `stdint.h'.

   If you require that an integer be represented in exactly N bits, use
one of the following types, with the obvious mapping to bit size and
signedness:

   * int8_t

   * int16_t

   * int32_t

   * int64_t

   * uint8_t

   * uint16_t

   * uint32_t

   * uint64_t

_________________________________________
Usenet Zone Free Binaries Usenet Server
More than 140,000 groups
Unlimited download
http://www.usenetzone.com to open account

Rene Tschaggelar wrote:
> Why are those guys so keen on C ? Suggesting
> compatibility with something while having least
> readability ?
>
> Rene

The description at the project page pretty much says it all:

"C provides an excellent alternative to VHDL/Verilog for algorithmic
expression of tasks targeting FPGAs for reconfigurable computing."

Project page at http://sourceforge.net/projects/fpga

The object is to use FPGAs as computing engines, and less concerned
about how to describe circuits in an HDL for synthesis, as most
hardware designers would with VHDL or Verilog. VHDL and Verilog are the
rough equivalent of programming in assemenbly language, as the
implementation languages are directly expressing clocks, registers and
wires which adds a tremendous design state factor and skill level in
their use.

Simplifed C to netlist compilers, such as FpgaC are attempting to hide
most of synthesis details, to ease the design burden for hardware
implementations of applications which have rich algorithmic complexity.
These applications range from doing network stacks in FPGAs for wire
speed performance at gigabit rates, to richly parallel algorithms such
as searching which are performance limited by the serial nature of
traditional CPU/Memory architectures.

FPGAs in this decade are simply building blocks for high performance
computing,
not just a dense PLD to express hardware funtions for the logic
designer.

Jan Panteltje wrote:
> Interesting.
> here is something to think about from the libc.info from gcc C.
> maybe you already support these?
> I recently found out it is better to use these in C then 'int' and 'short',
> as some programs I wrote stopped working when compiled on AMD 64....
> (header file structures with 'int' and 'short' and 'BYTE' ).

The native types, including long long as 64 bit, are in the parser and
emit the expected word length. The current net list generator only
builds signed values which are width+1 in size. Properly implementing
unsigned is part of the next pass work at bring FpgaC inline with
expected normal C implementations.

One of the interesting parts of FpgaC is that

     int VeryWideInt:512;

will build a 512 bit plus sign integer ... which doesn't make a very
fast counter, as the carry tree is pretty slow, but you get the
precision asked for.

typedef is also currently missing from FpgaC's parser, and will be
added soon so that standard header files can also be imported into an
FpgaC project.

Rene Tschaggelar wrote:
> Why are those guys so keen on C ? Suggesting compatibility with
> something while having least readability ?

air_bits@yahoo.com writes:
> The description at the project page pretty much says it all:
> 
> "C provides an excellent alternative to VHDL/Verilog for algorithmic
> expression of tasks targeting FPGAs for reconfigurable computing."

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?

air_bits@yahoo.com writes:
> One of the interesting parts of FpgaC is that
> 
>      int VeryWideInt:512;
> 
> will build a 512 bit plus sign integer ... which doesn't make a very
> fast counter, as the carry tree is pretty slow, but you get the
> precision asked for.

Why is that any better than

	VeryWideInt: unsigned (511 downto 0);

in VHDL?  I expect that this can just as easily be expressed in Verilog,
too.

Eric Smith wrote:
> air_bits@yahoo.com writes:
> > One of the interesting parts of FpgaC is that
> >
> >      int VeryWideInt:512;
> >
> > will build a 512 bit plus sign integer ... which doesn't make a very
> > fast counter, as the carry tree is pretty slow, but you get the
> > precision asked for.
>
> Why is that any better than
>
> 	VeryWideInt: unsigned (511 downto 0);
>
> in VHDL?  I expect that this can just as easily be expressed in Verilog,
> too.

I can build them at a schematic level too, so why is any HDL better?

I can even wire them out of TTL so why is using an FPGA better?

Heck, I can even wire them out of diodes or vacumn tubes, ....

So why waste people time bitching about others preferences, and the
tools
they use to implement them. If you like VHDL, certainly use it.

have a nice day ;)

air_bits@yahoo.com writes:
> I can build them at a schematic level too, so why is any HDL better?
> I can even wire them out of TTL so why is using an FPGA better?
> Heck, I can even wire them out of diodes or vacumn tubes, ....
> 
> So why waste people time bitching about others preferences, and the
> tools
> they use to implement them. If you like VHDL, certainly use it.

I'm not the one claiming that any particular HDL is better than
another.  But I'm trying to understand the hype about using C as
an HDL.  Where is the actual benefit?

Eric Smith wrote:
> Rene Tschaggelar wrote:
> > Why are those guys so keen on C ? Suggesting compatibility with
> > something while having least readability ?
>
> air_bits@yahoo.com writes:
> > The description at the project page pretty much says it all:
> >
> > "C provides an excellent alternative to VHDL/Verilog for algorithmic
> > expression of tasks targeting FPGAs for reconfigurable computing."
>
> 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 a few hundred thousand engineers on the planet that can
express large complex algorithms in C, and a few tens of thousands of
engineers that can express large complex algorithms in VHDL/Verilog,
and probably a few thousand that can actually grasp the test vector
space and simulation effort necessary to actually get a large
VHDL/Verilog design working for large complex alogoritsms. So access to
design talent is one.

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.

The embedded logic analyzer cores are a very poor subsitute when
debugging complex algorithms with lots of state and data.