FPGA C Compiler on sourceforge.net (TMCC derivative)

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 snipped-for-privacy@yahoo.com wrote in :

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

to open account

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

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.

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.

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?

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 ;)

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?

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.

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.

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

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.

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 ?

I presume a mixed-language design is possible ? - an example of that as well, would assist understanding.

Otherwise, it's all arm-waving.....

-jg

You have it backwards. The intent is not to use C for hardware design, but to use FPGA's for computing. There is a grey area in between, but the view point is from completely different ends of the problem design space.

Most applications of reconfigurable computing are not hardware design applications, so any pure HDL may be the wrong tool, as it's design focus is at the gate/register level.

Reconfigurable computing is about taking tranditional C/C++ applications and pushing the resource intensive parts into net lists for a performance gain ... frequenly as much as 200 times the fastest RISC/CISC processors by removing memory latency and ALU pipelines (both of which are serial resources) from the critical path.

Moving the front end of web servers, router/classifier logic and TCP/IP stacks into several large FPGA's ... VertexII-Pro's with rocket IO's and PPC backend engines is one example. These applications are already written in C, and get married to the external hardware with logic typically written in VHD/Verilog.

Likewise, most protocol converters which interface different fibre connections are freqently being pushed into fpga's to maintain wire speed operation.

Mixed C, VHDL, Verilog, and schematic are all very likely. C is just one more implementation tool.

Of those few hundred thousand that know C, very few have any clue how to design hardware. If you turn them loose with C as an HDL, you're going to end up with really crappy hardware, just like when programmers are thrust into Verilog or VHDL.

It's not knowledge of the syntax of a particular language that's the problem. The semantics of hardware design are fundamentally different from the semantics of sequential software design.

Are you claiming that test vectors and simulation aren't needeed when using C as an HDL? I'd be very skeptical of any such assertion.

What's that got to do with your choice of HDL? If you want to know what's going on inside your FPGA, that's not fundamentally any easier with C as your HDL than it is with Verilog or VHDL.

Eric

You're right, I wasn't aware of that distinction.

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.

Eric

Thanks. It is a pitty that C was chosen. The choice of C means some guys want to adhere to a standard, instead of flexibly adapt to the problems ahead. There should be a way to tell the compiler how quick I want to have an operation. Do I want a one cycle result with an enormous loockup table, do I want an N-digit multiply accumulate loop, do I want an NlogN solution or is it even less important. Is this being solved by a bunch of #pragma ?

I'd be interested in the first floating point unit coming out of such a compiler.

Rene

HDL has a benefit that you can include abstract ideas in your FPGA. That's why HDL is better.

I can also see the point of using C as a base language... But I can just imagine the latest windows.. instead of crashing once a week..it now crashes every mili second :-).. Poor software is still poor software... C isn't typed strong enough to use with out adding other tools, so it would be at the bottom of my list of recommended software. Also anything you create in C you will need to be able to verify. Failing to do so will only lead to hours and hair loss.

Pascal would have been a better choice IMO.

Simon

Or Modula-2, or IEC 61131, ... or even better, something like :

"AsmL is the Abstract State Machine Language. It is an executable specification language based on the theory of Abstract State Machines."

-jg

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

: Rene

Oee might ask the same question about hardware engineers and Perl - why is this such a commonly used tool? I'd venture to guess that after being forced to accept VHDL or Verliog as the prime language, the idea of using Perl or C derivatives for hardware proramming doesn't seem so twisted.

cds