Richard, that's completely ridiculous.

I can do -- in fact, have done -- a state machine for, say, an SDRAM controller in a page of VHDL. Or a PCI interface in a handful of well-documented (i.e., real, useful comments) modules.

I wouldn't want to consider how to do such a thing in a schematic-based design, much less prove that it's correct.

Or maintain it.

There's a real reason why FPGA (and ASIC) design is almost 100% HDL these days, and it's not because "that's what the vendors are forcing upon the users" or "so software people can design FPGAs" or "synthesis results are nowhere near as good as I can get with a schematic" or any of the other arguments put forth by schematic-entry users.

Here's the reason: the users who do serious FPGA and ASIC development overwhelmingly prefer HDLs to schematics.

I don't want to be beholden to an FPGA vendor's schematic-tools format. (A lot of people were screwed when Xilinx dropped Aldec's schematic tools.) I can't use a real revision-control system (like subversion) with a schematic. If I need to add a signal to a schematic at the bottom of a hierarchy and have it bubble up higher, it's a lot easier to edit the text files than the schematics.

I can grep through source files, looking for signal names or other constructs.

If I need a bus size changed, I can change a top-level parameter/generic and have it ripple down through the hierarchy. In fact, I don't need to change the source code AT ALL--I just change a generic in the build script!

And the simulation tools provided by brand A and brand X for schematic-based simulation simply aren't powerful enough and offer nowhere near what a proper model-based HDL test bench give you.

I could go on, but I hope I've made my point.

-a