One explanation involves the feedback loop between design entry and verification. In the traditional ASIC flow, designers capture the design at the register-transfer level (RTL) using, inappropriately, behavioral-level languages such as Verilog or VHDL. The restriction to RTL is necessary, first because of the limitations of synthesis technology, which require the formalism of RTL, and second because it is impractical to work at a level of abstraction much higher than RTL using existing simulation tools. Given the speed limitations of simulators and their limited ability to derive abstracted data, the information coming back from the verification process is more easily interpreted at the RTL than at the behavioral level.

Consequently, when practiced ASIC designers have evaluated C or Java design-capture tools and synthesis tools, a big complaint has been the gap between the behavioral view they create and the need to visualize the design at the RTL before synthesis and during verification.

The FPGA design flow is different. The architecture of most FPGAs is not well-expressed by RTL, and so most FPGA users aren't particularly bound to thinking about their designs in that way. Nor is RTL the underlying framework for FPGA synthesis, which must work with the logic cells as they are, rather than try to reduce them to the wrong abstraction.

More important, the primary verification technique for FPGAs is not simulation: It's to program up the parts and try them. This technique gives back information not at the gate level or RTL, but at the behavioral level. It's relatively easy to see how the whole chip responded to a test program, but a real pain to ascribe behavior to individual registers or logic blocks. So, paradoxically, design capture at the behavioral level fits better with the way FPGA users must visualize their designs and is more friendly to the data they get back from verification. It may well succeed for FPGAs before it does for ASIC flows.