FPGA-FAQ    0024

Q. 

A.

You have 4 basic options: HDL, state machine, schematic, or FPGA editor. These roughly correspond to decreasing levels of abstraction.

HDL's excel in complex but well-defined designs, where you know exactly what it is that your logic must do, but what it needs to do is complex and involved. If you think in an "algorithmic" or software-like way, in other words, you view your logic as "code" that you need to execute, HDL's will be the tool you'll be most comfortable with. They let you describe your logic in a source-code-like manner, and they'll let you do some very involved stuff. The tools for HDL have extraordinary sophistication, with plenty of verification and simulation options, lots of different flavors of synthesis entry, and usually a great many options in the program itself. HDL's are also, oddly, very good for really quick, simple logic functions that you don't feel like taking the time to figure out how the hardware would have to be for them.

The downside of HDL's is that the abstraction isolates you very much from the details of what's going on in the hardware. Typically you don't have ultimate control over how the software will actually implement your design on the chip. Furthermore, although the range of functions you can implement is amazing, abstracting the functionality still means that at a certain level you limit your design to the kinds of logic functions and blocks that the designers of the software envisioned. In other words, HDL's aren't your best bet if you're looking to tweak the last inch of performance, or utilization from your FPGA, or if you're doing something so bizarre that it falls outside the boundaries of what the software writers assumed you might be doing. Finally, there's the risk, with such a high degree of isolation, that you may try to implement something either too complex or at least very expensive to implement on the hardware. This could either hamper your design or be an outright barrier to 
success. So HDL's are things you should use with care, mostly to design relatively mature logic functions.

State machine entry works well when your design is simple and has a linear flow. If you think in a sequential way, seeing your logic as a series of states that the system steps through, the FSM entry method will seem logical to you. You could perhaps get quite complex, depending on how big of a state machine you care to visualize. It's great for simple controllers, especially ones with feedback where a state-machine description is fitting and natural. Even relatively complex, closed-loop control systems are good with this kind of system. Nevertheless, it really comes into its own with semi-simple functions, ones that may be more clear with a visual representation, and where the source-code representation of an HDL might make it more opaque what's actually going on.

The tools, OTOH, aren't very sophisticated or thought through. Third-party support is rare at best, and you'll probably end up using Xilinx' simulation and verification tools. Furthermore, at some point the design may become very difficult to follow, when you have hundreds of states, and since this method still isolates you from the underlying logic, there's no benefit to displaying a complex design in this way. In many respects, FSM design opens up the same weaknesses as HDLs, although admittedly it's pretty clear if you've got a state machine description that you're not doing anything bleeding-edge, so a great deal of the penalty of abstraction is a nonissue. Nonetheless, state machine synthesis is really for a narrow application range, where you're doing something simple, well-defined, and probably control-system oriented.

Schematic entry gives you far more insight into what's happening at a gate-level. If you're a "hardware" person, this will be a natural way to design. You can actually see what the gate implementation is, and this will give you a better immediate feel for timing issues, data paths, and simply what's actually going on in your design. You can design very, very complex logic if you want, and it's easier to optimize the design for the specific device you have. It eliminates a lot of the associated abstraction problems of HDL's, simply because everything happens at a more primitive level. Also, you can instantly see how complex a function is *actually* going to turn out to be, so you can either eliminate or redesign the logic if it turns out to be too expensive. In a sense, you have more flexibility in what you can design, because the tool lets you create logic much more with a specific view to the hardware capabilities of the chip. It may help also to de-mystify what's happening at a hardware level.

The big downside of schematic entry is that it's very difficult to modify the design, still harder to port it to a different device. It basically locks you into the device and design you envision at the present. You should also expect a lot of debugging because it doesn't isolate you from implementation-level errors, i.e. your logic may be right, but how you implemented it in the schematic may be faulty, something you can avoid with HDL's. Worse, the verification and simulation capabilities are more limited, and third-party support is essentially nonexistent. Xilinx' tool furthermore has a whole set of frustrating, nonsensical limitations. You should therefore be very 
confident with your schematic capture capabilities before tackling a design this way. It's best for the more bleeding edge, oddball designs where you aren't overly concerned with design cycle time, and where you don't expect to be changing devices any time soon.

Finally, FPGA editor gives you ultimate control, giving you direct access to the physical layout and configuration of the device proper. Obviously, this means you can program any configuration the device is capable of implementing, no matter how bizarre or complex. You can see directly *exactly* what's going on, tweak your fitting down to the last detail, specify precisely what function blocks, connections, etc. implement which piece, etc.

The negatives are equally clear-cut, namely, you have *NO*: simulation, verification, portability, error-checking, or third-party support. Experts only need apply, and you'd better know hardware inside and out. Debugging will take a long time, and unless you're really careful, you may smoke a component or 2. So this is a tool to use only if you're an expert and have some freakish, ultra-high-end design where you can't tolerate any sort of compromise whatsoever.

Ray Andraka added:

My feeling on this is HDLs give you more flexibility when it comes to parameterizing your designs, and much better testbenches.  Also, an HDL doesn't require a proprietary view to browse the design (although it may need a specific version of the synthesizer to generate exactly what you intended).  Other than these points, I find that properly done schematics or HDL are appropriate.  For either, proper use of hierarchy plays a much bigger role in reusability, readability, documentation, and troubleshooting than does the choice of a design entry tool.  I actually like to discourage newbies to FPGAs and/or digital design using HDLs, as the abstraction tends to hide poor design practice, as well as the obvious architectural tailoring you can easily do in the design if you are close to the underlying chip architecture.  HDLs make it too easy to design something that is very difficult/expensive in hardware and many times the designer doesn't even realize it.

VHDL is a a powerful tool, but it does not make a lousy design magically good and since it tends to hide the details it may not be obvious the design is lousy.

Emanuel Stiebler added:

Mix it !
A top level schematic, the units below in VHDL, Verilog, etc.. It's amazing, already magic how easy it is to explain what you're doing to somebody else, when you can see all functional units, data flow on one sheet. And, sometimes you see your own design more clearly ;-) 

When you like to go to HDL only, just replace one sheet to a text page.

Muzaffer Kal added:

I think this distinction is completely arbitrary. Actually the ONLY difference between HDL and schematic entry is how they are visually presented. You can get an HDL text file which is completely identical to a schematic and that is how you link schematic entry to P&R anyway. You get an EDIF file from your schematic entry tool. Viewlogic's Viewdraw can even generate Verilog from your schematics. You can instantiate gates in Verilog and put constraints etc. which is what the schematic does. IOW, if you want to do gate-level structural entry HDL lets you do it unlike schematic which forces you to only that type of entry. In HDL you have a lot more freedom. You can design complex state machines for control blocks  easily and you can be as detailed and low level as you need for datapath blocks.

Neil Franklin added:

May I add a 5th option: JBits.

JBits also gives you FPGA Editor level control, but using an HDL like source code with all the advantages of replication structures (good for data paths).

I managed to get it to work despite being a beginner (previously only 74xx stuff) by simply reading *thoroughly* the Virtex data sheet and the JBits docs, plus a few mails to Xilinx JBits group. The JRoute component allows routing without danger of accidently killing chips.

Also runs on any machine with Java support. I develop on Linux, no NT or Solaris.

Negatives are: simulation is limited to DeviceSimulator, essentially step the clock through your design, whatching what it does. No protability (only Virtex, and Spartan-II of sizes that also exist in Virtex). And code is fairly verbose (you set everything), and you need to do 100% hand placing (routing is automated). So it is fairly time intensive.