A Field Programmable Gate Array (FPGA) is a programmable logic device.

Typically faster and more complex than a CPLD. 

Typically programmed in VerilogLanguage or VhdlLanguage.

Many manufactors use FPGAs instead of custom ASICs.

Programming a FGPA is significantly different from programming a regular CentralProcessingUnit. Parallelism is used a lot more. What software practices would still apply? Programming these devices somewhat combines software engineering with hardware engineering.

End users won't use FPGAs directly. The inputs and outputs of an FPGA should be tightly defined. This should make it easy to make test cases for. However, directly testing is often/usually difficult. Simulation of the programs is usually done for comprehensive testing, then in real life, perhaps they aren't as comprehensively tested?
----
Why should direct testing be difficult? You have your inputs, you have your outputs - just as for any other ASIC or software.

Sure, you might have some internal state that is difficult to monitor - but you can make several custom "test versions" of your code, so that each one brings out a block of that internal state on one of the "extra" pins. Also, you can program the FPGA to include a custom "test signal generator" to toggle all the inputs to the rest of the design.

FPGAs typically have several complexities that must be addressed in testing. These include basic functional testing, propagation delay verification, and power and RF emittance testing. The suggestion above, creating alternate versions with different test pins exposed addresses only the functional testing. Additionally, in a design with high gate utilization, getting a single routing may be challenging. Doing multiple layouts may not be feasible. Alternatives here include pure software simulation and use of a standard test port. The test port requires the FPGA be put into a special test mode where all storage (i.e. flip-flops) is connected in series. An initial state can then be seriallly entered, often requiring in excess of 100 steps. The FPGA can then be returned to non-test mode and one or more production modes executed. The result can be deterimined either by analyzing external results or internal state can be examined by returning the FPGA to test mode and serially clocking out the contents of all internal registers.

Propagation delays can be problematic in FPGAs because connections have to pass through switching transistors. Correct operation depends upon adequate set up and hold times surround state changes [??]. Violation of these times causes synchronous gates to go into oscillation, leading to unpredictable results. Due to the large number of gates, manual analysis of the various paths is not practical. Software analysis is used to identify any critical paths and the affected area is rerouted, with resorting to manual routing not unheard of.  

One additional area of concern is with power consumption and RF emittance. Every time the FPGA changes state, it requires a current surge that also results in a power drop. Bursty power drops can cause nearby circuitry to malfunction. Periodic power drops create a frequency that is radiated by the circuit board's power and ground layers. For commercial equipment, the power and frequency of RF signals emitted is highly restricted. Without FCC approval, the equipment may not be able to be shipped.
----
Many people program (part of) the FPGA to act as a CPU - a FpgaCpu. Would it make any sense for that CPU to be a WritableInstructionSetComputer?
----
See: InstinctAsIntelligence

CategoryHardware