VHDL Methodologies for Effective Implementation on FPGA

Devices and Subsequent Transition to ASIC Technology

I. Stamolis*, N. Ford, G. J. Dunnett, M. White, P. F. Lister

Centre for VLSI and Computer Graphics

School of Engineering
University of Sussex
Brighton, BN1 9QT,
UNITED KINGDOM
*
I.Stamoulis@Sussex.ac.uk

Abstract:
This paper investigates the efficient use of VHDL for targeting Field Programmable Gate
Array Architectures (FPGAs) in order to match constraints in area or timing critical designs.
We will question the effectiveness of technology-independent VHDL, and show methodologies
for mixed, low-level and VHDL integration that allow optimum results while maintaining the
flexibility of VHDL designs.
We will show how optimisations can be applied to algorithms, not only at the synthesis
level, but at an algorithmic level as well. We will also discuss the necessity of manual versus
automated floorplanning as performed by vendors back end tools.
However, as FPGAs are often used for ASIC emulation, such device-specific
implementation would not be beneficial if it prohibited the transition to an ASIC process. In
this context we show methodologies that will allow FPGA-optimised designs to migrate to ASIC
processes, and take advantage of both architectures.

Another popular application of FPGA devices is

1. Introduction
Until recently Field Programmable Gate
Arrays (FPGA) devices were relatively small and
they were used as a sophisticated alternative to
PLDs. The recent introduction of FPGA chips with
large gate counts from many manufactures has
given rise to a number of new applications that were
previously only feasible with ASIC technology.
Also, the newest generation of FPGA devices
feature very sophisticated internal architectures
which help designers to make better use of the
available resources.
Hardware description languages are
becoming increasingly popular in designing large
scale integrated circuits. VHDL is a popular
Hardware Description Language (HDL) supporting
many of the features available in high level
programming languages.
2. VHDL synthesis for FPGAs
The flexibility of FPGA and the much smaller
Non-Recurring Engineering (NRE) costs, allows
FPGAs to be used in final products as alternative
solutions to ASICs. This is especially true in small
scale productions where these NRE costs are the
dominant factor.
for prototyping ASICs. Usually in this case, the
technology-independent VHDL is targeted towards
the chosen FPGA architecture. This approach
makes use of FPGAs as an ASIC emulator that
usually runs at a much lower speed.
However, in the following sections we will show
that designs can be engineered to take advantage of
the target FPGA and exploit its architectural
features. We present here the VHDL methods that
will take advantage of FPGAs but still maintain the
flexibility that will allow the transition to an ASIC
process.
2.1. Design of Finite State Machines (FSM)
A key issue in effective use of FPGA is to balance
the designs logic and registers to match those of
the target FPGA. The generation of FSMs is
another area where conventional ASIC synthesis
and FPGA synthesis differ [7]. The balance of logic
resources and registers on FPGAs means that the
most efficient state machine realisation results from
using one-hot encoding of the FSM.
Due to this fact, One-hot representation of FSMs
in FPGAs is not only the fastest implementation,
but the most compact as well [8].
Typically, binary representation of FSMs require
a lot of decoding logic and consumes more logic
cells than One-hot encoding. Furthermore, most of
the registers in those decoding cells are wasted. In
small and simple FSMs, the decoding logic may be
minimal and in this case, a binary state machine
may be slightly more efficient.
Most synthesis tools, including Synopsys, support
extraction of the State Machine. Alteras MaxPlus2
will by default One-hot encode the FSM. Other
tools, such as Synplify, will automatically use one-
hot or binary encoding according to certain
constraints.
2.2. Design of Adders
Most FPGA architectures have special carry chain
logic that allows very fast and compact design of
adders. Although this uses a ripple carry method,
the very fast routing makes it much faster than a
LUT implementation, and definitely a lot smaller.
All synthesis tools, such as Synopsys, will use a
DesignWare Library with adders and subtractors to
take advantage of such hardware.
2.3. Multipliers
A very common module in digital circuits is an
integer multiplier. The optimum architecture for an
integer multiplier varies significantly with the
architecture of the target technology. Although
synthesis tools can minimise the logic and take
advantage of special technology, they can not
optimise a circuit at the algorithmic level.
In this section we will investigate three
alternative methods for implementing such circuits.
The FPGA-based designs were targeted at Lucent
ORCA devices. The Lucent ORCA architecture is
ideal for implementing multipliers because the logic
cells (PFUs) can be configured in a 4x1 multiply
and sum mode with a partial product. This greatly
reduces the amount of logic required for a
multiplier. In this example we compare three 9 by 8
multipliers.
The multiplier options are:
a. Synopsys1 generated
b. One generated by SCUBA, a Lucent Tool
that generates FPGA specific modules.
c. A design that uses Orca DesignWare
Components and VHDL.
a. Synopsys
Synopsys can generate signed and unsigned
multipliers using logic gates. These are then
minimised and packed into Look Up Tables (LUT).
This gives the best results in ASIC processes.
However, this architecture doesnt take advantage of
any technology specific features and therefore
results are bound to be sub-optimal. For small
multipliers, this method gives acceptable results, but
1
Design Analyser 3.5a
as the size of the operands increases, the amount of
logic cells required are too large for practical
implementations. A 9 x 8 multiplier was
synthesised and the resulting size was 43 logic cells
with a speed of 12 MHz.
b. SCUBA generated multipliers:
SCUBA is a tool provided by Lucent that can
produce common designs such as Multipliers,
Adders/Subtractors, Comparators, and RAM/ROM
components using ORCA specific macro files. This
usually yields improved performance and area for
such devices. However, it can only produce
unsigned multipliers. In this example a 9 x 8
unsigned multiplier was produced. Inputs and
outputs were registered in order to get accurate in-
system results. Such a multiplier occupies 19 PFUs,
which is roughly equivalent to 700 logic gates, and
can be clocked to 20 MHz. SCUBA only generates
unsigned multipliers, and so cannot be used for
signed multipliers.
c. Hand-made ORCA multiplier
A hand-made multiplier was implemented. This
was created for a particular graphics application,
hence the strange sizes for multiplicand and
multiplier. This multiplier is a signed 9 bits by
unsigned 8 bits, and the result is a signed 17 bit
product. We implemented it as a tree of adders,
which follow a stage of a 9 x 2 multipliers. ORCA
specific cells such as ANEB4 or FMULT41 were
extensively used in order to get the best
performance and area compromise.
unsigned[7:6] unsigned[5:4] unsigned[3:2] unsigned[1:0]
9-bit signed
9x2 9x2 9x2 9x2
Multiplier Multiplier Multiplier Multiplier
Registers Registers Registers Registers
13-bit Adder 13-bit Adder
Registers Registers
Optional
Pipeline
Registers 17-bit Adder
17-bit signed product
Figure 1
This particular design was placed and routed in
an OR2C04A-4 device where it occupied 34 PFUs,
and it could be clocked up to 28.8 MHz. As
expected, a 3-stage pipeline as shown on Figure 1
can be clocked at least to 60 MHz without
increasing in size at all, as all pipelining registers
can be hosted in the same logic cells as the
preceding addition and multiplication logic blocks.
From our results it is obvious that the method of
choice is to use SCUBA because of the small area,
and if pipelined they are very fast as well. Also,
SCUBA can produce any size of multipliers, which
reduces development time. If signed multipliers are
needed, then an alternative method will have to be
used.
If speed performance were a concern, then a
hand-made version would achieve even better
performance at the expense of a slightly bigger area.
If signed multipliers are required then Synopsys can
be used.
With VHDL the designer can have all
architectures under the multiplier entity and choose
the desired architecture ( w.r.t. target technology)
using the configuration statement.
Using this method, the design can take advantage
of the low-level architecture features whilst
maintaining the flexibility and ease of simulation
that VHDL provides.
Furthermore, in applications such as the Fast
Discrete Cosine Transform, the designer can choose
the algorithm that has the best balance between
adders and multipliers to meet his constraints in
terms of area, speed and latency.
2.4. Multiplexing
There are two ways to perform multiplexing in
FPGA devices. One of them is using LUTs, where
the inputs are the select and input signals.
A Output
22-to-
-to-11
MUX
MUX
B There are two distinct styles of on-chip RAM.
Sel
Output
A portion of static RAM, usually between 32 and 64
B
Sel
Figure 2
The VHDL code for figure 2 would be simply:
Output <= A WHEN Sel=0 ELSE Z;
Output <= B WHEN Sel=1 ELSE Z;
Another method is to use the available three-state
buffers. Three-state buffers consume no logical
resources and therefore help designs to be more
compact.
A
Output
22-to-
-to-11
B MUX
MUX
Sel
A
Output
B 44input
input
Sel LUT
LUT
Figure 3
VHDL code to infer the structure in figure 3
would be:
Sel <= A WHEN Sel=0 ELSE B;
In some of the current FPGA architectures, three-
states are connected only to special long routing
resources, and their extensive use will severely
affect the routing of the design.
The designer can choose either the LUT or the tri-
state implementation according to the target
architecture. The flexibility of VHDL means that
one needs only to change the configuration to
switch between the two architectures.
2.5. Distributed or local On-Chip RAM.
Currently most FPGA manufacturers have
architectures with on-chip memory. This satisfies
the designers need for integrated memory to
implement FIFOs and other memory structures.
The first style, which appears to be the most
common, is distributed RAM. In this case, a small
bits, is available in all Logic Cells. This gives the
best flexibility to the designer to use the available
logic cells in the way that best suits his design, e.g.
as logical or storage functions. Moreover, this
arrangement simplifies the routing complexity.
The alternative method is to have the entire RAM
locally in much bigger chunks. This method is used
in Altera FPGAs. The main problem with this
method is that the design is often limited by the
amount of RAM that is available and not by the
number of available logic cells. Synthesising logic
to dedicated SRAM structures can be laborious, as
usually synthesis tools are not aware of these
structures and targeting them is left to the Back End
Tool.
2.6. FIFOs
Fifos are not generally implemented in FPGAs as
the resources that are needed for the memory cells
are restricted. The increasing availability of on-chip
memory in FPGAs means that small FIFOs can be
implemented in the same FPGA as the design. This
can significantly increase the performance of many
applications where maintaining the flow of data is
important. The on-chip memory is usually dual-
ported and this significantly simplifies the
complexity of the support circuits and increases
substantially their performance
The diagram in figure 4 shows a typical FIFO
structure based on dual ported memory. The
pointers can be implemented using fast adders that
use carry chains. The Flags and Control logic is a
purely combinatorial circuit. The Dual Ported RAM
can be either Distributed or local depending on the
target FPGA target architecture. Both methods work
well and consume a relatively small amount of
logic.
Logic
Data In
Data Out
Read
ReadPointer
Pointer
On
OnChip
Chip
Write
WritePointer
Pointer Memory
Memory
Flags
Flagsand
and
Control
Control
Input Output
Req Ack Req Ack
Figure 4
The integration of the FIFO on the same piece of
silicon as the design does not only mean increased
performance but also a decrease in the number of
external components. This saves board space and
decreases manufacturing costs.
2.7. Comparators
Another common component in logic circuits is
the comparator. This is a component found in
many address decoding designs such as PCI targets
where the base address must be compared very
quickly with the base address registers of the
allocated memory space.
Three designs were implemented to compare 24-
bit values. One designed by Synopsys that produces
a tree of LUTs. The other is the SCUBA design,
which cascades comparator cells and another design
that was hand-made and was a combination of the
two above mentioned methods.
a. A comparator Using LUT, as produced by
SYNOPSYS. This was implemented as a tree
of Look Up Tables.
b. A comparator produced by SCUBA by
cascading comparator (ANEB4) cells and
interconnecting them using the carry chains.
c. A hand-made comparator, a combination of
the two methods using individual comparator
cells and logic cells configured as six input
LUTs.
Table 1 summarises the results of the three
methods.
Table 1
Area (PFUs) Speed (MHz) Prop. Delay (ns)
Synopsys 15 70 14.3
SCUBA 19 56 17.8
Hand-made 19 87 11.4
The area number includes registered inputs and
outputs. The look-up table approach gives better
area results, mainly because the LUT can be
combined with registers in the same PFU. However,
when speed is the main concern, a hand-made one
that uses the comparator cells gives the optimum
results.
As seen in this example careful examination of
the target architecture can give enough information
to the designer to optimise the design either for area
or for speed.
2.8. Pipelining
A popular method to increase the rate at which
valid results are produced by the design, i.e. the
throughput, is pipelining. The pipelining technique
partitions blocks of combinatorial logic into n stages
of equal delays with each stage separated by a bank
of pipeline registers [6]. A fully balanced pipelined
design can be clocked up to n times faster and
therefore will have n times bigger throughput. The
penalty for pipelining is the n times increased
latency of the design.
The introduction of register banks in the design
will inevitably have as a direct result an increase in
the gate count. However, the architecture of the
most popular FPGA logic cells has both logical and
register resources.
The introduction of pipeline registers in such
technology will have minimal impact to the gate
count, as most of the flip-flops will be hosted in the
same logic element as the combinatorial logic 2. In a
best case situation, the size of the design would
remain the same.
2.9. Design partitioning
In many cases, the design will not fit in any of the
available FPGA devices. In this case, the designer
will have to partition the design into multiple
FPGAs.
Some of the popular back-end tools will do this
2
This is not usually the case for placing registers after three-state
buffers.
automatically and go even further by proposing the
particular devices to be used.
However, it is usually better if the designer, who
has knowledge of the functionality of his design,
partitions it manually.
In many cases, particularly in timing critical
designs it may be better to replicate logic in more
than one FPGA. This is often the case for a
Program Register Set (PRS), where many sub-
modules may want to have access to the same data.
When timing partitioned designs, the delays
introduced by the pads must be taken into account
to correctly balance the registers and time the
design.
2.10. Floorplanning in FPGAs
A Design coded in VHDL is transformed into
gates by synthesis tools such as Synopsys. The gates
and registers are then packed into Look-Up-Tables
(LUT) and flip-flops. The design is then imported
into the back-end mapping tools, which identifies
LUT and flip-flops in the same region and packs
them into the same logic cells. It also orders
register flip-flops to make sure that related
registered bits lie on the same logic cell (i.e. bits
0,1,2,3 of a register will be packed on the same
logic cell if it has 4 registers). Also, at this stage a
further Design Rule Checking (DRC) takes place,
which checks for fan-out, etc. errors and modifies
the netlist accordingly. Some further optimisation
can take place at this point as well.
The result of the above procedure is a netlist of
logic cells that is still unrouted. The designer is
then faced with two options for placing the logic
cells on a given FPGA. He can either use the Place
and Route tool to automatically place the logic cells
on the FPGA. This is based on a reasonably clever
iterative cost based algorithm that will try to place
the logic cells in an efficient way on the available
cells. Alternatively, he can manually place and
route.
2.11. Manual placement of Components
Here the designer has to manually try and place
the unrouted Logic Cells on the available cells of
the device. On small devices, the automatic place
and route tool can be both faster and more efficient
than manual routing. Experimentation in small
circuits has shown that the circuit produced with
automatic placement and routing is faster and uses
the routing resources more efficiently.
The main problem in manually placing the cells
of a netlist is that the shortest distance is not
necessarily the fastest. The latest generation of
FPGAs has typically three types of routing
resources, pin-wires, short-wires and long-wires.
Connecting adjacent cells may require use of a
number of short-wires and switches, which in many
cases is slower than connecting a wire from a cell
that is far away where connections can be
implemented with a long-wire. Although it may be
argued that very careful examination of the delays
and routing resources may provide enough
information to the designer to make a marginally
better design, this is only feasible in very small
designs. In larger designs, (more than 2,000
equivalent ASIC gates) it is practically impossible.
A number of Universities are engaged in research
on routing methodologies and the development of
algorithms that are more efficient than standard
cost-based methods that are used by propriety
software [4,5].
However, most FPGA vendors do not publish
enough information that would allow a third-party
placement and routing tool to be implemented.
Placement and routing of pre-routed hard-wired
macros is an option that must be closely considered
as it may simplify the routing process and improve
system performance. However, the existing tools do
not offer the desired flexibility and they are far from
user-friendly. It is expected that as FPGA placement
and routing tools mature they will offer increased
control over the floorplanning of a design [2].
However, automatic placement and routing
algorithms will become more clever and understand
more of the structure of the design and will provide
better results as well.
For high-density devices, one may floorplan
specific parts of the designs to improve the
performance of Place and Router (PAR) software.
On large designs (more than 30,000 gates or 85% of
the available resources ) the placement and route
tool has a hard time placing the design and routing
all the nets. In many cases, it has taken up to
50-70 hours on a Sparcstation-20 to completely
route the design. Due to the complexity and size of
larger designs, PAR tools are limited by their ability
to recognise structures. A design may not route at
all (usually the case on designs that use more than
95% of the resources of the FPGA), or will not meet
the timing-constrains (as some routes are slower
than 50-60 ns on their own).
However, designers have direct knowledge of the
designs structure and its critical paths. Using this
information they can improve the placement of the
design [2]. Designers have the option to specify the
design constraints with allowances for paths that are
not timing-critical (e.g. reset) and let the automatic
PAR work harder on the critical paths. The other
option is to pre-route blocks (e.g. a multiplier) and
let the placement tool place those hard-wired
macros on the available area [1]. However, this is
not as flexible as real ASIC floorplanning as it is
not possible to orient (rotate, flip, etc.) the macros.
2.12. Routing Designs
Again the designer has two options, he can either
let an automatic Place And Route tool do the
routing or route the design himself using a
floorplanning tools (e.g. Lucents Epic). However,
as complex designs have tens of thousands of wires,
it is practically impossible to route a design
manually, let alone optimising it.
The only reasonable method is to give weights to
the various routes, in order to force the PAR tool
spend more time improving the timing critical-
paths. Many of the paths may be considered not
timing critical, and can be given less weight than
other more timing critical paths.
Another issue often overlooked, is the pin
assignment. Careful assignment of pins has proved
that it can help the PAR tool place the design more
quickly, and in many cases give better results than
fully automated placement and routing. Pin
positions, however are also part of the PCB and
system level partitioning, but in most cases careful
pin assignment is beneficial for both internal
placement and external PCB routing.
3. Transition to ASIC
FPGA devices are increasingly being used as
prototypes for ASIC Devices. This allows a design
to be verified in a system environment before the
company commits to an ASIC process. Another
reason that this approach is becoming popular is
that an early prototype allows drivers and software
related activities to be initiated at earlier stages thus
reducing significantly the design-to-market time.
Potential bugs and system incompatibilities can be
detected at a very early stage, and the design team
can have robust hardware.
FPGAs are a very attractive solution for designs
where specifications are evolving and the time-to-
market must be very small. Features such as
reconfigurability can even allow users to update the
version of their hardware using software methods.
But, when the specification has been finalised and
high volume production is needed, then cost is a
significant issue. The transition to an ASIC
technology is essential to meet these requirements.
A vital advantage of VHDL is its device
independent nature. The designs source code can
be targeted to any technology without changes. But
in our designs, many blocks were substituted for
lower-level FPGA dependent components. For the
ASIC synthesis, those blocks will be substituted
back to the RTL version for the synthesis.
Using extensively the VHDL configuration
structures, the user can change the VHDL
architecture of each component.
The registers of the design should also be re-
balanced to take into account the different
propagation delays of the two technologies.
The designer may use mischievous techniques in
the FPGA implementation to fulfil tight constrains.
But these methods can not be used in an ASIC
process as this may introduce race conditions,
glitch-prone clocks and improper initialisation of
the device that must work across all process
variations [9].
The previously proposed methods of using
different VHDL architectures: a general purpose
and FPGA specific architecture, allows the designer
to use every trick in the book to use most of the
FPGA architecture, while still maintaining the good
design methodologies on the ASIC version. This
would also allow testability and safe timing.
It is often desirable that the ASIC is pin for pin
compatible with the prototype FPGA that was
designed first. This would allow the ASIC to be
used as a drop-in replacement and the exact same
board to be used in both implementations. Special
consideration must be given for the FPGA
configuration pins and also for ASIC testing pins.
4. Conclusions
In the first section, we investigated different
design methodologies that give optimum results in
FPGA implementations. Then we showed that
knowledge of the target architecture could give the
designer important information that can be used to
change the structure of the design to make the most
of the target architecture. It was also shown that
although synthesis tools are aware of the target
architecture they are not currently intelligent
enough to make these optimisations. Furthermore,
the designer can make optimisations, not only at the
low logic level, but even at an algorithmic level,
something that is impossible for synthesis tools.
It has been shown that placement and routing are
a very important part of the FPGA design and the
routing delays contribute to the total delays in most
cases by almost as much as the combinatorial
delays. Careful pin assignments and floorplanning,
although more time consuming, pay off in reduced
routing time and improved system performance.
FPGAs are often used as an emulation of the final
ASIC during the development time and for early
impact in the market. When high volume quantities
are needed, the production can be switched to an
ASIC technology.
Seeking the peak performance in both the FPGA
and ASIC versions of a design, one can use dual
VHDL architectures of the critical components and
combine them in the same design. However, good
design principles must be maintained in the
common components to allow smooth transition
from FPGAs to ASICs. Further considerations must
be given if the ASIC is destined to be a drop-in
replacement.

5. References
[1] Lucent Epic manual and Data Book
[2] Xilinx, "HDL synthesis for FPGAs design G uide",
http://www.xilinx.com/appnotes/hdl_dg.pdf , chapter 4
[3] Michael Gschwind and Valentina Salapura, VHDL
design methodology for FPGAs, Technische
Universitat Wien
[4] Michael J. Alexander and Gabriel Robins, New
performance driven FPGA Routing Algorithms,
University of Virginia
[5] Stephen Brownm, Jonathan Rosem and Z. Vranesic,
"A Stochastic model to predict the routability if
FPGAs, University of Toronto
[6] Synopsys, Pipelining Designs , Synopsys
Application note
[7] Michael Gschwind and Valentina Salapura,
Optimizing VHDL for FPGA targets, Technische
Universitat Wien
[8] Peter Alfke and Bernie New, Implementing state
machines in LCA devices, Xilinx PLD Book, 1994
[9] Ron Modo, FPGA Design Practices that help ensure
good Migration, IDSMAG, April 97