But what about your customer?

No question, there are some things that work out in a page of code that would take longer to enter in a schematic. One popular example is a HEX-to-7-segment encoder. Then, of course, a decoder would probably be just as much trouble. I'm not totally in disagreement about what's workable or easier. I just have to work around the question of, "easier for whom?" all the time.

It's all about the documentation from where I sit. I have to have documentation that actually represents what the customer agreed to buy. As a consequence, I have to present it in a form that my customer, normally a very senior engineer, now in a management position, can readily see addresses his initial requirements, and can understand, at least to his own satisfaction. He doesn't want to become an expert on my particular implementation, but he was already an expert on what he wanted before my work started, and he wants to be assured, formally, that what he's been sold is what he agreed to buy.

If you don't do post-fit or post-PAR timing simulations, you've no idea whether the circuit will perform as claimed. Routing delays can vary considerably. Most of the time spent on making FPGA's work is spent on making the routing work out so that the timing isn't all fouled up by the time it's done. Yes, you can simply say, "The $20 FPGA is too slow, so we have to use the $120 one..." but that won't please anybody, except perhaps the guy who demanded the upgrade.

The issue with which I'm constantly confronted is that young engineers (the ones under 40) are not really dedicated to doing the job. They're interested in (a) getting the job, (b) keeping the job, and (c) moving on to a "better" job. They don't care whether their design works well over the long haul, since they've then collected their bonus and moved on to another company that wants the technology someone has already paid to have developed. That's why the managers don't like the HDL-only presentation, because they have to hire someone to translate it into terms they can understand and believe. They know they can't rely on those youngsters who were taught HDL and for whom schematics are less interesting. They know they will find omissions in the documenatation, skipped simulation efforts, and slight of hand in the presentation. They know they can't trust 'em. That's why they, the senior engineers and managers, want to get their hands around what's really been done.

Yes, there are some things that are more briefly expressed in HDL. In those cases, one puts the HDL module in a schematic symbol, presents the logic as a thoroughly simulated component, so everybody understands what it is, and uses it in the upper level block diagrams. That way, it isolates those who don't know or don't care about HDL's don't have to.

They (the managers) seldom have trouble accepting what the device manufacturer provides as library components or IP, as-is. I'm not sure why that is, since I tend to distrust 'em, having found more than one with inherent defects, but they do. That allows me to use a block representation of the library SDRAM controller or ethernet MAC, or whatever, as needed.

It's all about giving the customer what he wants. If he wants a presentation and documentation that's understandable by his own senior colleagues, he has to have schematic presentation. It doesn't always demand that each component be created or presented in schematic form, but it does require that the top level and perhaps the level or two below that be presented in schematic/block form so he's comfortable with what's being presented and reviewed.

Post-fit/post-route route simulations are always presented in combination with logic analyzer pictures of the actual circuit behavior. This makes them feel comfortable with what's being presented.

RE