VHDL System Design: schematic editor or structural code?

Being new to digital design, I'm finding it a tedious task to read through structural VHDL code. This applies to top-level core designs. I was wondering, with respect to readability, which approach would manage a large design better? Writing your structural designs in VHDL or using a proper schematic editor to design the system?

When I first started out, I was afraid of VHDL and used schematics; now I never use schematics. As far as the design process, what I do (and that doesn't make it the right or proper way) is kind of a mix of top-down and bottom-up design. I first block out the major functions of the system and how they interconnect to the other functions. I then design each low-level block(which is generally made up of OTHER blocks). This way, you can look at your top-level module and see the overall function of the system without having to absorb the entire complexity. Most of the FPGA tools have functions for generating block diagrams from your VHDL code (although they don't always work so well).

I usually use behavioral, rather than structural, design as it makes things easier to understand. I see no reason to define an adder with a bunch of gates when I can just write: SUM<=A+B, and let the synthesis tools figure it out.

I don't know of this makes any sense, or if I even answered your question. Your question actually made me think about how I really DO design. I don't get bogged down in thinking about "structural" or "behavioral" or "RTL" or "Data Flow"; maybe that's wrong, I don't know. But my designs work, so I guess that's kind of important, too

@Barry, I absolutely agree with you & your design practice. I was about to give somewhat similar answer.
When I started my career in VLSI, I was a big fan of writing structural code (as it gives me all the control of design rather than giving it to synth tool). However as designs grow, it becomes nearly impossible to have a structural code. Mostly behavioral is the best, without giving much consideration to what type of code you are writing (It should be 'good' code off-course, just don't worry if it is struc or behav etc ). Tools these days are very very mature & optimize behavioral code to a very high degree. Only thing to remember is that you are using a HDL and NOT a programming language. HDL is a 'Description' language for the HW you want to make & you should clearly know what HW you want to design. Best is to have on paper what your blocks/sub-blocks should be & how they'll be connected. (Though with increasing silicon area & intelligent tools, this practice is fast becoming obsolete).

PS: BTW, in my opinion, schematic entry is a big no-no (thats just my opinion & could be completely wrong). Even if you use a schmetic entry, make sure you use it to generate structural code & THOROUGHLY check the generated code. (I somehow, always have a difficulty in trusting generated code except synthesized netlist, I know that's a irony after all schematic entry tools should be much simpler than synth tool)

I can see why it makes sense to write sub-components in behavioral VHDL. The current design I'm working is designed like this. As you go higher up in the hierarchy however, these components are instanced in a structural fashion. For example, the micro-controller consists of an ALU, timers, bus-controllers etc., and all are written in behavioral code. These components are then connected together using structural assignments. Furthermore address decoding and memory mapping is then performed around the micro-controller, written in behavioral VHDL and instanced using structural assignments. When evaluating the entire system by just looking at the code, it's hard to get a clear picture of the flow. Is there a more elegant way of approaching such a design? Can one use behavioral design on a higher level in the hierarchy?

Yes, you can use behavioral or structural or whatever you want anywhere you want. "They" suggest you keep behavioral and structural elements separated, but it's all kind of just nomenclature anyhow. I'm sure some academic-types will be clutching their chests reading that.

It sounds like you want a block diagram, so draw a block diagram (or use the block diagram tool in your software). One picture is worth a thousand words, and all that. I'm starting to lose understanding of what you really want. You could just draw a big square with an arrow on one the left labelled "INPUT" and another arrow on the right labelled "OUTPUT" and you'd have a nice, simple to understand drawing; but it's not going to tell you much.

What do you want to convey? You've got a complex system, how simple a representation do you want? A top-level diagram (or code module) with your blocks (ALUs, etc) connected together is probably as simple as you're going to get.