Electronic – Can FPGAs dynamically modify their logic

Yes, it is possible to do high level logic (HLL) design using C or C-like languages. Here is a list of the more popular software tools:

• C-to-Hardware (Altera)
• C-to-Hardware Compilation Technology (Altium)
• C-to-Silicon Compiler (Cadence)
• C-to-Verilog (Nadav Rotem, free and open sourced)
• Cascade (CriticalBlue)
• Catapult-C (Calypto)
• Comrade (Hagen Gädke)
• CyberWorkBench (NEC)
• Daedalus (Leiden University and University of Amsterdam, free and open-source)
• DIME-C (Nallatech)
• DK Design Suite (Mentor Graphics)
• eXCite (Y Explorations)
• FpgaC (John Bass, free and open-source)
• GAUT (Philippe Coussy, free and open-source)
• Impulse CoDeveloper (Impulse Accelerated Technologies)
• Mitrion SDK PE (Mitrionics)
• NISC (University of California, free)
• ROCCC (University of California, free and open-source)
• SPARK (University of California)
• SpecC (University of California)
• Synphony (Synopsys)

Keeping track of them is made difficult by the fact that these companies regularly swallow each other whole, change names or discontinue products entirely.

It looks like for all tools, the C code needs to go through an intermediary HDL stage. So the design will be translated into Verilog or VHDL, and these tools facilitate the transition before it is finally put into hardware. But remember, Verilog and VHDL themselves are intermediary stages. Even the netlist is intermediary. The final stage will be a proprietary binary file which reconfigures the FPGA. Designing in C will have its own challenges and trade-offs. But the answer to the question is a resounding yes, logic design in C can be done.

A nice introduction to C-to-FPGA was written way back in 2005. Wikipedia has a nice list of HDLs and tools. Currently, there are also tools for languages similar to C, C++, Java, Python and Ruby. Please comment if I missed a tool and I will add it to the answer.

You should assume the clock input to your flip-flops is toggling unless you can prove otherwise (by a guaranteed power on or post configuration delay). All the flip-flops on a given clock domain are not guaranteed to start on the same clock edge based on GWE or GSR. Both act like an asynchronous reset and cause potential problems for some logic (counters, one-hot state machines, etc).

Specifically a one-hot state-machine that transitions immediately after configuration WILL (eventually) FAIL (transition to an invalid state). The frequency of failure will depending on the clock period compared to the device (and place and route) specific skew for your design.

Another simple experiment to see this behavior initialize a relatively fast count down counter with 10000000 and look at its behavior immediately after configuration. Some bits make the transition to 01111111 and some bits miss that first transition but the subsequent counting sequence will be correct.

The white paper mentioned by Krunal Desai talks about this very problem and is a great reference. Any SRAM based FPGA will most likely have a similar issue.

There is no need to reset the registers to get a known value. If you have logic that is sensitive to all starting on the same clock edge will need to add synchronization logic (this can consist of a synchronously de-asserted reset or other synchronous logic). Xilinx AR44174 talks about the issue a little more. I would add a third method of mitigation which is to guarantee clocked logic is not changing/transitioning during the first several clock cycles after startup.