Another developer joined the FpgaC project today to cleanup some of the yacc/lex design issues as a C compiler (like variable scope).
This, structures, unions, typing, and unsigned variables are on the near term list of things to fix in this compiler so it will take a cleaner subset of traditional C.
Longer term I would like to add direct support for bit serial distributed arithmetic to be able to support multiply, multiply-accumulate, divide and mod (%) operations. Plus add direct support for threads by using some compiler primatives that know about fork(), exec(), along with library primatives for MPI and posix-threads so that parallelism would remain expressed the same way in FPGA and RISC/CISC testing environments.
Anybody else have pet ideas, suggestions, or wish-list items that a C based HLL/HDL tool should handle?
I had a quick play the other day and I noticed that the counter example generates it's own set of lookup-tables for the increment logic, creating an enormous VHDL file. I imagine the code generator could be simplified somewhat to take advantage of modern synthesis... writing a process with x:=x+1 in!
My personal wishes for it would be
a) you can "simulate" the code with a suitable wrapper using a normal C-compiler
b) you can explicitly parallelise stuff within a given function
c) some form of communication is provided between processes, that also simulates in boggo-C. Something like Occam channels or FSL ports would be my preference
Cheers, Martin
--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.trw.com/conekt
I had a similar experience and mind set for a while, but I'm not so sure after spending a few hours hacking on the code to preserve bit vector naming last spring. The VHDL netlist output is called after all the optimizations have been done in FpgaC, and it more or less then attempts to build the same circuit structures in VHDL that it would in XNF.
Internally TMCC/FpgaC does not save statements while parsing, it goes straight to building internal netlists for the operations. As a result using FpgaC for a C to VHDL translator is more than a bit of work and would radically interfer with the compiler C to netlist functions. It would effectively require breaking FpgaC into two parts, which would probably be better done by stripping the backend off FpgaC and making a second tool for a C to VHDL translator that would preserve statement level syntax.
Since the long term goal is to produce good XNF/EDIF netlists that are tightly integrated to a set of RPM's and cores for reconfigurable computing, it has not been clear if VHDL output is the best way to get there, or a diversion.
That is already the goal for FpgaC. I've already done some of this as I've hacked the original TMCC work. Implementing the rest of the C native types, moving the port definitions to pragmas, and starting the move to using bit field syntax is all part of that goal. The current bit field size hack isn't precise C, as FpgaC doesn't have structures. One of the next changes is to introduce structures, unions, and enums into Fpga so that bit fields in a structure will be the same as bit fields in standard C. Adding some pragmas which guide enum, counter, and state machine generation by suggesting one-hot, grey coded, and traditional counter types is somewhere in the long term road map.
Typedef also needs to be added, but that will probably happen sooner as we fix the symbol table scoping rules in the next group of changes that will overhall the entire symbol dictionary code.
While other C to netlist tools are generally trying to make C an HDL, and are willing to make radical changes to the language departing from std C, I'm looking to target FpgaC as an HLL to netlist tool, less concerned with having it compete directly with VHDL/Verilog. The intent here is to make FpgaC a very good C to netlist tool for reconfigurable computing, which preserves std C execution expectations on a traditional compiler and cpu.
Thus, it should always simulate correctly on a cpu, unless you work hard to break it by using some HLL specirfic feature (if any remain), or the word size choice in the netlist target can not be represented in the CPU you are simulating on and there are some word size or endan problems as a result.
This breaks a).
The goal is to do a) in the most parallel way that can be done transparently. Much as multiissue super scalar CPU's do .... IE exploit as much parrelism as exists in the sequential specification. This is actually quite a bit, and frequently much more than a super scalar processor can muster.
Currently, every statement block is allowed to become a flattened combinatorial netlist. So a single statement loop, doesn't have much parallism, unless it's a pretty complex statement with a lot of subexpression operations. There we win, as the entire expression can be flattened to a single combinatorial net list.
Later to improve this I plan to add loop unrolling guided with a pragma as a space time tradeoff.
This doesn't break a), and preserves the ability to use a traditional cpu as an effective simulation environment.
In a traditional multiple processor environment, MPI and PVM provide the communications standards that are widely used. The intent is to create some intrinsics that the compiler uses to build mailboxes and FIFO's for IPC needs, and then provide an FpgaC set of libraries and header files that do most of std libc, MPI, PVM and posix-threads.
This addition to FpgaC is needed to handle PCI to host communications, as well as inter-FPGA communcations in multiple FPGA platforms.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.