Perhaps one of the most important rules in VHDL design is to define all conditions. Both Jens and I have noticed that when we define all possibly conditions on a bus that is used in the CASE-WHEN structure, the logic created is much smaller and faster. This occurs because additional flip-flops are necessary if not all conditions are defined. Since VHDL abstracts the designer from the design, it is sometimes very hard to consider all cases of conditional logic resulting in a less than optimal design.
Another important issue when dealing with VHDL and re-programmable device is the fact that asynchronous design does not yield itself very nicely to FPGAs or any other re-programmable devices. Although synchronous designs are more popular and easier to implement, asynchronous designs exhibit properties that are desirable in many digital systems. One major attribute of asynchronous designs is that handshaking between processing elements is more defined absolving the need for a centralized clock signal. Conversely, synchronous designs rely on a clock signal whose period must be greater than the longest combinatorial delay. Some other more prominent advantages of asynchronous designs are presented in [5]. However, asynchronous design have many disadvantages when considered in the context of FPGA design. As much as we would like to attempt a design of an (EC) digital system using asynchronous methodology, [3] suggests that such an approach necessitates elimination of all hazards, synchronization of events and very precise timing requirements of all functional blocks in the design. Timing glitches due to poor combinatorial design can be avoided with careful consideration. However, timing glitches produced by the place and route tools are, for the most part, very hard to control. It is these glitches that render asynchronous designs on FPGAs infeasible at this point. Few attempts have been made to develop reconfigurable devices capable of asynchronous operation [3,4]. Thus, until such devices become readily accessible, FPGA implementations are limited to synchronous methodology.
The means for implementing state machines in the XC4000 family devices is another consideration that needs some elaboration at this point. In particular the state machine encoding style has to be chosen to fully utilize the specific FPGA resources. In a conventional ASIC design, binary or gray code state machine encoding is preferred for efficient and minimal design [6]. Conversely, ``one-hot encoded'' state machines implemented in ASIC device exhibit relatively large area with minimal gain in performance. This is not the case with FPGA devices. As described in [2], one-hot encoding becomes feasible when mapped to FPGAs due to the large number of flip-flops available in the device. For many designs, the CLBs are used as LUTs leaving the flip-flops untouched. Consequently, these resources can be utilized when one hot encoded state machine is implemented [2]. The advantage of a one-hot encoding lies in the representation of each state with an individual bit (flip-flop) resulting in decreased logic complexity associated with each state [1]. However, any FPGA device has a limited number of routing and area resources thus implementing a one-hot encoded state machine is advantageous only in cases where there are enough resources for the state machine and the rest of the design. Once the state machine becomes too complex, [1] suggests that an external RAM may be required to store the control program leaving only the sequencing mechanism inside the FPGA.
Many FPGA manufacturers provide an array of arithmetic and storage macros that take advantage of specific features in a particular device. Xilinx provides a design-ware library filled with such macros in addition to LogiBlox components that can be tailored to the designer's specific need. Arithmetic functions such as adders use the fast carry chains available on the device. Also RAM/ROM elements mapped with available macros fully utilize the CLB structure to achieve the most performance out of a single CLB. In [2], many designs are analyzed to show the effectiveness of the available macro functions. Our implementation takes advantage of the LogiBlox functions for storage (RAM and registers) elements. Also, the design-ware library is invoked by Synopsys tools to implement arithmetic functions necessary for counters present in the control module.