When to break down VHDL?

226 views Asked by At

Although I'm somewhat proficient in writing VHDL there's a relatively basic question I need answering: When to break down VHDL?

A basic example: Say I was designing an 8bit ALU in VHDL, I have several options for its VHDL implementation.

Simply design the whole ALU as one entity. With all the I/O required in the entity (can be done because of the IEEE_STD_ARITHMETIC library).

--OR--

Break that ALU down into its subsequent blocks, say a carry-lookahead adder and some multiplexors.

--OR--

Break that down further into the blocks which make a carry-lookahead; a bunch of partial-full adders, a carry path and multiplexors and then connect them all together using structural elements.

We could then (if we wanted) break all of that right down to gate level, creating entities, behaviours and structures for each.

Of course the further down we break up the ALU the more VHDL files we need.

Does this affect the physical implementation after synthesis and when should we stop breaking things up?

1

There are 1 answers

0
AudioBubble On BEST ANSWER

You should keep your VHDL at the highest level of abstraction, so don't ever "break it down" as you described. What you are proposing is that you do the synthesis yourself (like creating a carry-lookahead adder) which is a bad idea. You don't know the target device (FPGA or ASIC library) as well as the synthesizer does and you shouldn't try to tell it what to do. If you want to do an addition, use the + operator and the tools will figure out the best structure that fits your design constraints.

Dividing the design into many modules will often make it more difficult to optimize your design, since optimizations between modules are generally harder to do than optimizations within modules.

Of course, major functional blocks that have well defined interfaces between them should be in separate modules for the sake of maintaining the design and readability. The ALU can be one module, the instruction ROM another, and so forth. These modules have distinct, well-defined functions and there is not much opportunity for intramodule optimization. If you want to get the last possible bit of optimization available, just flatten the design before optimization and let the tools do the work.