Part 4
Optimizing Designs
In this part of the book we will introduce a number of ‘advanced’
topics. In the other parts of the book, the emphasis is on the
‘what’, however in this part is it more about the ‘how’. How can
we make designs synthesize? How can our designs be made smaller
or faster? How can we interface to mixed signal systems in prac-
tice? How can we develop verifiable designs? All of these design
challenges will be addressed in this part of the book.
Ch14-H6845.qxd 4/5/07 11:38 AM Page 169
This page intentionally left blank
14
Synthesis
Introduction
The original intention of VHDL was to have a design specification
language for digital circuits. The main goal of the work was to have
a design representation that could be simulated to test whether the
specification was fit for purpose. When VHDL was standardized as
IEEE Std 1076, the broader application of VHDL for not just simu-
lation but as an integral part of the hardware design flow became
possible.
The original method of designing digital circuits was primarily
through the development of schematic-based designs, using gate
libraries to effectively generate Register Transfer Logic (RTL)
netlists directly from the schematics. This is clearly a reasonable
technique when the designs are relatively small, however it quickly
becomes apparent that for designs of any size this approach is simply
not realistic for modern Field Programmable Gate Arrays (FPGAs)
that require millions of gates.
EDA companies realized fairly early on in the VHDL development
process that if there was a standard language that could represent a

data flow and a control flow, then the potential existed for automati-
cally generating the gate level VHDL from a higher level description,
and RTL was the obvious place to start. RTL has the advantage of
representing the data flow and control flow directly, and can be mapped
easily onto standard gate level logic. The resulting synthesis software
(such as the Design Compiler from Synopsys) quickly established an
important role in the digital design flow for both ASIC and FPGA
designs and have in fact provided to be the driving force in the explo-
sion of productivity of digital designers. The modern high density
designs would not be possible without RTL synthesis.
Ch14-H6845.qxd 4/5/07 11:38 AM Page 171
As such, modern day designers often simplify ‘RTL synthesis’
to just ‘synthesis’, however this is not the whole story. As designs
have continued to get more complex, there has been a push to ever
increasing behavioral synthesis however there is not the same sup-
port from the EDA industry for behavioral synthesis software.
VHDL supported in RTL synthesis
While VHDL is standardized, synthesis is not, and as such the
VHDL that can be synthesized is a subset of the complete VHDL
language. Another common problem for designers is the fact that
different synthesis software packages will give different output
results for the same input VHDL, even to the extent that some will
synthesize and some will not under certain conditions.
There are some standard VHDL techniques that cannot be syn-
thesized however and these are summarized in this chapter.
There are two types of unsupported elements in VHDL – those
that will cause a synthesis failure and those that are ignored. The
failure elements are in many respects easier to manage as the syn-
thesis software will provide an error message. It is the ‘ignored’ ele-
ments that can be more insidious as they can obviously leave errors

in the synthesized design that may not be picked up until the hard-
ware is tested.
Initial conditions
VHDL supports the initial condition being set for signals and vari-
ables, however this is not physically realized. In practice the initial
conditions in the synthesized design are random and so in a prac-
tical design a reset condition should always be defined using an
external reset pin. This is because during synthesis, the initial con-
ditions are ignored.
Concurrent edges
It is common to use a clock edge as a trigger for a model, so a sim-
ple VHDL model may have a process with VHDL something like
this to wait for the rising edge of a clock:
Process (clk)
If rising_edge(clk) then
Q <= q;
End if;
End process;
Design Recipes for FPGAs
172
Ch14-H6845.qxd 4/5/07 11:38 AM Page 172
Or in a similar way:
Process (clk)
If clk’event and clk = ‘1’ then
Q <= q;
End if;
End process;
What is NOT valid is to have more than one rising edge as the trig-
ger condition:
Process (clk1, clk2)

If rising_edge(clk1) and rising_edge(clk2) then
Q <= d;
End if;
End process;
This would fail the synthesis.
Numeric types
Synthesis is only supported for numbers that have a finite range.
For example, an integer type with an undefined range (infinite) is not
supported by synthesis software. In general terms it is often required
that designers specify the range of integers and other integer-based
numbers prior to synthesis (such as signed or unsigned).
This can be a subtle restriction as vectors that have a number as
the index, must have this number defined in advance, so busses
cannot be of a variable size.
Floating point (real) numbers are generally not supported by
synthesis software tools as they do not have floating point libraries
defined.
Wait statements
Wait statements are only supported if the wait is of the form of an
implied sensitivity list and a specific value. So, if the statement is
something like:
Wait on clk = ‘1’;
Then this is supported for synthesis. If the wait statement is
dependent on a specific time delay then this is NOT supported for
synthesis. For example a statement in VHDL such as this is not
supported:
Wait for 10 ns;
Synthesis
173
Ch14-H6845.qxd 4/5/07 11:38 AM Page 173

Assertions
Assertions in any form are ignored by the synthesis software.
Loops
The for loop is a special case of the general loop mechanism in
VHDL and synthesis requires that the range of the loop must be
defined as a static value, globally. This means that you cannot use
variables to define the range of the for loop ‘on the fly’ for synthesis.
If a while loop is implemented, then there has to be a wait state-
ment in the loop somewhere – otherwise it becomes a potentially
infinite loop.
Some interesting cases where synthesis may fail
Unfortunately, there are differences between synthesis software
packages and so care must be taken to ensure interoperability
between packages, particularly in multi-team designs or when using
third party VHDL cores. The cores may have been synthesized using
software different to the one you are using in your design flow, so the
advertised ‘synthesizable’core may not always be synthesizable for
you, in your design flow.
As such it is usually a good idea to keep the VHDL as generic as
possible and avoid using ‘tricks’ of a particular package if you plan
to deliver IP cores or use different tools. This may lead to slightly
less compact VHDL, but the reliability of the VHDL will be greater,
and potential problems (which could cause significant delays later
in the design process, particularly in an integration phase) can be
avoided.
One case is the use of different trigger variables in a process. For
example, if there is a clock and a reset signal, or a clock and an
enable signal, it is tempting to combine the logic into one expres-
sion such as:
If (clk’event and clk = ‘1’ and nrst = ‘1’) then

...
End if;
However, in some synthesis software this would cause an error. It
is always preferable to separate these variables into nested if state-
ments for three reasons: (1) the code will be more readable, (2) the
Design Recipes for FPGAs
174
Ch14-H6845.qxd 4/5/07 11:38 AM Page 174
chance of undefined logic states is reduced and (3) the synthesis
software will not have a problem with your VHDL!
What is being synthesized?
Overall design structure
The basic approach for synthesizing digital circuits is to consider
every design block as a combination of a controller and a data path.
The controller is generally a Finite State Machine (FSM), clocked,
and the data path is usually combinatorial logic, but there may also
be storage in there and so a clock may also be required. The basic
outline is shown in Figure 35.
Controller
The controller is producing the control signals for the data path
logic and may also have external control signals, so there are both
internal and external control signals in the general case. As this is
a FSM, the design is synchronous and therefore is clocked and
will generally have a reset condition.
The controller can be represented using a state diagram or bubble
diagram. This shows each individual state and all the transitions
between the states. The controller can be of two basic types: Moore
(where the output of the state machine is purely dependent on the
state variables) and Mealy (where the output can depend on the cur-
rent state variable values AND the input values). The behavior of the

state machine is represented by the state diagram (also sometimes
called a state chart) as shown in Figure 36.
Synthesis
175
Input data Output data
Data
Path
Logic
Controller
External control
Internal control
Clock
Figure 35
Synthesizable Digital
Circuit
Ch14-H6845.qxd 4/5/07 11:38 AM Page 175
The technique for modeling FSMs will be covered later in this
book, but the key elements to remember are that as this is a Finite
State Machine, there are a Finite number of states, and hence the
number of storage elements (D types) is implicit in this definition.
Also, the VHDL allows the definition of the state names as an enu-
merated type, which makes the VHDL readable, easy to understand
and also easily synthesizable.
For example, take a simple example of a two state machine,
where the states are called ON and OFF. If the on off signal is low
then the machine will be OFF and if the on off switch is high, then
the state machine will go into the ON state.
To implement this simple state machine in VHDL, we can use a
new type to represent the states:
Type states is (OFF, ON) ;

Signal current_state, next_state : states;
Notice that in the FSM VHDL we have defined both the current
and the next state. The main part of the FSM can be easily imple-
mented using a case statement in VHDL within a process that
waits for changes in both the current_state signal and any external
variables or control signals:
Process (current_state, onoff)
Begin
Case current_state is
When OFF =>
If onoff = ‘1’ then
Design Recipes for FPGAs
176
S0
out1 ϭ 0
S1
out1 ϭ 1
S3
out1 ϭ 3
S2
out1 ϭ 2
rst ϭ ‘0’
rst ϭ ‘1’
choice ϭ ‘0’
choice ϭ ‘1’
Figure 36
Basic State Machine
Ch14-H6845.qxd 4/5/07 11:38 AM Page 176
Next_state <= ON;
End if;

When ON =>
If onoff = ‘0’ then
Next_state <= OFF;
End if;
End case;
End process;
Elsewhere in the architecture, the current_state needs to be
assigned to the next state as follows:
Current_state <= next_state;
Data path
The data path logic is the logic (as the name suggests) to process the
input data and generate the correct output data. The functionality of
the data path logic will usually be divided into blocks and this offers
the possibility of optimization for speed or area. For example, if area
is not an issue, but speed is the primary concern, then a large design
could be constructed to generate the output in potentially a single
clock cycle. If the area is not an issue, but throughput is required,
then pipelining could be used to maximize the overall data rates,
although the individual latency may be high. Finally, if area is the
critical factor, then single functional blocks can be used and regis-
ters used to store intermediate values and the same function applied
repeatedly. Clearly this will be a lot slower, but potentially take a lot
less space.
In the basic data path model there are blocks of combinational
logic separated by registers. Clearly there are options for optimizing
Synthesis
177
Register
Combinational
Logic

Register
Combinational
Logic
Register
Clock
Figure 37
Data Path
Ch14-H6845.qxd 4/5/07 11:38 AM Page 177
the data flow by considering how best to move the data between
the registers for speed or area optimization.
It is important to ensure that some simple rules are followed to
ensure robust synthesis. The first is to make sure that each signal
in the combinational block is defined for every cycle, in other
words it is important not to leave undefined branches in case or if
statements. If this occurs, then a memory latch is inferred and
therefore a latch will be synthesized and as this is not linked to the
global clock, unpredictable behavior can result.
Summary
This chapter has introduced the concept of synthesis, both from a
designers point of view and also the implications of using certain
types of VHDL with the intention of synthesizing it. The assump-
tions and limitations of the various approaches have been described
and some sensible practical approaches to obtaining more robust
designs defined.
Design Recipes for FPGAs
178
Ch14-H6845.qxd 4/5/07 11:38 AM Page 178
15
Behavioral Modeling in VHDL
Introduction

There is a real need to abstract to a higher level in many designs to
make the overall system level design easier. There is less need to
worry about details of implementation at the system level if the
design can be expressed behaviorally, especially if the synthesis
method can handle any clock, partitioning or implementation
issues automatically.
Furthermore, by using system level, or behavioral, analysis,
decisions can be made early in the design process so that poten-
tially costly mistakes can be avoided. Preliminary area and power
estimates can be made and key performance specifications and
architectural decisions can be made using this approach, without
requiring to have detailed designs for every block.
How to go from RTL to behavioral VHDL
The abstraction from RTL (Register Transfer Level) VHDL
to behavioral is straightforward in one sense, in that the VHDL
is actually simpler. There is no need to ensure that correct clock-
ing takes place, or that separate processes are implemented for
different areas of the architecture, or even separate components
instantiated.
It is useful to consider an example to illustrate this point by
looking at the difference between the RTL and behavioral VHDL
in an example such as a cross product multiplier. In this case we
will demonstrate the RTL method and then show how to abstract
to a behavioral model. First consider the specification for the
model shown in Figure 38.
Ch15-H6845.qxd 4/5/07 11:38 AM Page 179
Design Recipes for FPGAS
180
This has the data path model as shown in Figure 39.
The first task is to define the types for the VHDL for the entity

of the model and this is shown below. Notice that we have defined
a new type sig8 that is a signed type and a vector based on this for
the cross product multiplications.
library ieee;
Use ieee.std_logic_1164.all;
Use ieee.numeric_std.all;
Package cross_product_types is
subtype sig8 is signed (7 downto 0);
type sig8_vector is array
(natural range<>) of sig8;
End package;
The entity can now be put together and this is shown below.
Notice that for RTL we require both a clock and a reset.
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
use work.cross_product_types.all;
entity cross_product is
port(
a,b : in sig8_vector(0 to 7);
clk, reset : in bit;
result : out signed(15 downto 0)
);
end entity cross_product;
i
8
a
0
7
a_reg

8
i
8
b
0
7
b_reg
8
ϩ
16 16
0
Result
sum
16
Figure 39
Data Path Model
X
a (signed 7:0)
b (signed 7:0)
Result (signed 15:0)
Figure 38
Cross Product
Multiplier
Specification
Ch15-H6845.qxd 4/5/07 11:38 AM Page 180
The basic architecture can be set up that has the basic internal
signals defined, and the processes will be explained separately.
architecture rtl of cross_product is
signal I : unsigned (2 downto 0);
signal ai, bi : sig8;

signal product, add_in, sum, accumulator : signed (15
downto 0);
begin
control: process (clk)
begin
if clk’event and clk = ‘1’ then
if reset = ‘1’ then
i <= (others => ‘0’);
else
i <= i + 1;
end if;
end if;
end process;
a_mux: ai <= a(i);
b_mux <= bi <= b(i);
multiply: product <= ai * bi;
z_mux: add_in <= X”000” when i = 0 else
accumulator;
accumulate: process (clk)
begin
if clk’event and clk = ‘1’ then
accumulator <= sum;
end if;
end process;
output : result <= accumulator;
end;
Notice that there are two processes, one for the accumulation and
the other to handle the multiplication. One important aspect is that it
is not immediately obvious what is going on. Even in this simple
model it is difficult to extract the key behavior of the state machine.

In a complex controller it verges on the impossible unless the struc-
ture is well known and understood, which is an important lesson when
using any kind of synthesis tool using VHDL or Verilog at any level.
Now reconsider using behavioral VHDL instead. The model
uses the same packages and libraries as the RTL model, however
notice that there is no need for an explicit clock or reset.
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
use work.cross_product_types.all;
Behavioral Modeling in VHDL
181
Ch15-H6845.qxd 4/5/07 11:38 AM Page 181
entity cross_product is
port(
a,b : in sig8_vector(0 to 7);
result : out signed(15 downto 0)
);
end entity cross_product;
In this model, the architecture becomes much simpler and can be
modeled in a much more direct way than the RTL approach.
architecture behav of cross_product is
begin
process
variable sum : signed(15 downto 0);
begin
sum := to_signed(0,16);
for i in 0 to 7 loop
sum := sum + a(i) * b(i);
end loop;

result <= sum;
wait for 100 ns;
end process;
end architecture;
Notice that it is much easier to observe the functionality of the
model and also the behavior can be debugged more simply than in
the RTL model. The design is obvious, the code is readable and the
function is easily ascertained. Note that there is no explicit con-
troller, the synthesis mechanism will define the appropriate mech-
anism. Also notice that the model is defined with a single process.
The synthesis mechanism will partition the design depending on
the optimization constraints specified.
Note the wait statement. This introduces an implicit clock delay
into the system. Obviously this will depend on the clock mecha-
nism used in reality. There is also an implied reset. If an explicit
clock is required then use a wait until rising_edge (clk) or similar
approach, but retaining the behavioral nature of the model.
Consider a another useful example: a Finite Impulse Response
(FIR) filter. Ignoring the entity and declarations, how can we
model an ideal FIR filter behaviorally in VHDL?
The specification of the interface is as follows:
Input : signed (15 downto 0)
Output : signed(15 downto 0)
Coefficients : array(natural range<>) of integer...
Design Recipes for FPGAS
182
Ch15-H6845.qxd 4/5/07 11:38 AM Page 182
And the resulting VHDL code would be something like the
following:
for I in samples’right downto 1 loop

samples(I) := samples(I-1);
end loop
samples(0) := input;
sum := to_signed(0,32);
for j in 0 to samples’right loop
sum := sum + (to_signed(coeffs(j),16) *
samples(j));
end loop;
output <= sum(30 downto 15);
wait for 1 us;
This is easily parameterized, modified and clear to understand.
Summary
Behavioral VHDL is a useful technique for both initial design
ideas and also the starting point for an RTL design. It is important
to remember, however, that quite a lot of behavioral VHDL cannot
be synthesized and is therefore purely for conceptual design or use
in test benches. In order to make this a practically useful design
tool, the designer can take advantage of the ability of VHDL to
have numerous architectures and by using the same test bench val-
idate the RTL against the behavioral model to ensure correctness.
In summary, we can use behavioral modeling early with high
impact to:
•
carry out fast functional simulation,
•
make performance criteria/design trade-offs,
•
investigate non-linear effects,
•
look at implementation issues,

•
carry out topology evaluation.
Behavioral Modeling in VHDL
183
Ch15-H6845.qxd 4/5/07 11:38 AM Page 183
16
Design Optimization
Introduction
The area of design optimization is where the performance of a
design can be made drastically better than an initial naïve imple-
mentation. Before discussing details of how to make the designs
optimal for the individual goals of speed, area and power, the ‘big
three’ for design optimization generally in digital design and par-
ticularly for Field Programmable Gate Arrays (FPGAs), it is
useful to discuss some principles of what happens when we syn-
thesize a function into hardware.
There are two main areas for optimization of the design when
working with VHDL for FPGAs and these are in the optimization
of the Register Transfer Level (RTL) VHDL which is leading
to an optimal description of the VHDL in terms of logic expres-
sions. The second key area is in the basic logic minimization prior
to the mapping of low-level functions to the individual technology
gates.
Techniques for logic optimization
There are two approaches to minimizing the logic in a design,
one that maintains the hierarchy and the other that flattens it.
Often a synthesis tool will allow the user to choose which option
is required. Clearly the advantage of flattening a design is that
the logic can be considered as a whole, whereas if the logic hierar-
chy is maintained, then there may be structural aspects of the

design that will be of benefit to the behavior of the circuit as a
whole.
Ch16-H6845.qxd 4/5/07 11:38 AM Page 184
Design Optimization
185
The basic approach of the logic minimization is to reduce
the logic equation set to a two level form (otherwise known as
sum-of-products). The most common approach for simple designs
is to use a Karnaugh map to show the input and output variables
graphically and then produce an output expression that can pro-
vide the same outputs but using a smaller amount of logic than the
original Boolean expressions.
For example, consider the basic 4 input Karnaugh map shown in
Figure 40.
When a logic expression is described using a logic equation,
we can select all valid outputs by circling all the required output
‘1’s and this defines the basic logic behavior. The basic technique
is to make the circles as large as possible to encompass as many
output ‘1’s with as few input variables as possible. For example,
if a basic logic equation was defined as Z ϭ AиBиC
—
ϩ A
—
иBиD ϩ
A
—
иBиD, then the resulting Karnaugh map would be as shown in
Figure 41.
Currently, with this basic implementation this would require 3, 3
input AND gates, a 3 input OR gate and several inverters. We can

Z
0
Z
1
Z
2
Z
3
Z
4
Z
5
Z
6
Z
7
Z
8
Z
9
Z
10
Z
11
Z
12
Z
13
Z
14

Z
15
AB
CD
00 01 11 10
00
01
11
10
Figure 40
Basic 4 Input
Karnaugh Map
0
0
0
0
0
1
1
0
1
1
0
0
0
0
0
0
AB
CD

00 01 11 10
00
01
11
10
Figure 41
Specific Karnaugh
Map Example
Ch16-H6845.qxd 4/5/07 11:38 AM Page 185
Design Recipes for FPGAs
186
see from the Karnaugh map however that if we define only two of
those logic functions, that there is redundancy in the original def-
inition, and we can reduce this to the same output for two logic
combinations of the input in Figure 42.
We could therefore define this model using the simplified
expression defined as Z ϭ AиBиC
—
ϩ A
—
иBиD which has clearly
reduced the size of the logic by 1, 3 input AND gate and the OR
gate has reduced to a 2 input gate.
Improving performance
Consider a simple example of an addition x ϭ a ϩ b ϩ c ϩ d,
where all the variables are digital words. We could implement this
using adders taking two numbers at a time and then adding the
answer to the next input. This would give the following data flow
diagram in Figure 43.
0

0
0
0
0
1
1
0
1
1
0
0
0
0
0
0
AB
CD
00 01 11 10
00
01
11
10
Logic Expressions
Implied Function
Figure 42
Functions Identified
on Karnaugh Map
؉
a b
؉

c
؉
d
x
Figure 43
Naïve Dataflow
Diagram for Addition
Ch16-H6845.qxd 4/5/07 11:38 AM Page 186
Design Optimization
187
This implementation requires 3 adders and takes 3 cycles to get
the answer. If we were more systematic with the same resources,
we could reduce this to two cycles by adopting a different struc-
ture shown in Figure 44.
This is a classic case of an expression tree being reduced so
that the control path can take fewer cycles, but achieving the
same data path result. We could also the visage the case where
we only use a single addition block, but use registers to store
the intermediate sums and then ‘pipeline’ the sums until we com-
plete the expression. This would potentially take the longest,
however would result in the smallest area requirement – as there
would only be the need for a single addition block (however of
course this would be a trade-off with an increased number of
registers).
Critical path analysis
Another approach to logic optimization is to analyze the critical
path through a design from a timing perspective. This is often car-
ried out automatically by the synthesis software, for example the
Synopsys Design Compiler software automatically generates a
synthesized schematic that highlights the critical path through the

design for timing and as such the designer can concentrate their
efforts on that area of the design to improve the overall throughput
in that case shown in Figure 45.
؉
a
b
؉
x
؉
c d
Figure 44
Reduced Cycle
Implementation
Ch16-H6845.qxd 4/5/07 11:38 AM Page 187
Design Recipes for FPGAs
188
Summary
This chapter has discussed some techniques for improving the per-
formance of VHDL designs on FPGAs and how they work. Much
of the actual optimization is taken care of in the synthesis soft-
ware, however it is useful to understand the processes involved so
that of a specific target is required for optimization this can be
achieved in a reasonable time in a controlled manner.
Figure 45
Critical Path Analysis
Ch16-H6845.qxd 4/5/07 11:38 AM Page 188
17
VHDL-AMS
Introduction
With the increasingly high level of system integration it is becoming

necessary to model not only electronic behavior of systems, but
also interfaces to ‘real-world’ applications and the detailed physical
behavior of elements of the system in question. The emergence of
standard languages such as VHDL-AMS has made it possible to
now describe a variety of physical systems using a single design
approach and simulate a complete system. Application areas where
this is becoming increasingly important include mixed-signal elec-
tronics, electro-magnetic interfaces, integrated thermal modeling,
electro-mechanical and mechanical systems (including micro-electro-
mechanical systems, MEMS), fluidics (including hydraulics and
micro-fluidics), power electronics with digital control and sensors
of various kinds.
In this chapter, we will show how the behavioral modeling of mul-
tiple energy domains is achieved using VHDL-AMS, demonstrating
with the use of examples how the interactions between domains
takes place, and provide an insight into design techniques for a vari-
ety of these disciplines. The basic framework is described, showing
how standard packages can define a coherent basis for a wide range
of models, and specific examples used to illustrate the practical
details of such an approach. Examples such as integrated simula-
tion of power electronics systems including electrical, magnetic and
thermal effects, mixed-domain electronics and mechanical systems
are presented to demonstrate the key concepts involved in multiple
energy domain behavioral modeling.
The basic approach for modeling devices in VHDL-AMS is to
define a model entity and architecture(s). The model entity defines
Ch17-H6845.qxd 4/5/07 11:39 AM Page 189
Design Recipes for FPGAs
190
the interface of the model to the system and includes connection

points and parameters. A number of architectures can be associated
with an entity to describe the model behavior such as a behavioral
or a physical level description. A complete model consists of a sin-
gle entity combined with a single architecture. The domain or tech-
nology type of the model is defined by the type of terminal used in
the entity declaration of the ports. The IEEE Std 1076.1.1 defines
standard types for multiple energy domains including electrical,
thermal, magnetic, mechanical and radiant systems. Within the
architecture of the model, each energy domain type has a defined
set of through and across variables (in the electrical domain these
are voltage and current, respectively) that can be used to define the
relationship between the model interface pins and the internal
behavior of the model.
In the ‘conventional’ electronics arena, the nature of the VHDL-
AMS language is designed to support ‘mixed-signal’ systems (con-
taining digital elements, analog elements and the boundary between
them) with a focus on IC design. Where the strengths of the VHDL-
AMS language have really become apparent, however, is in the
multi-disciplinary areas of mechatronic and MEMS. In this chapter,
I have highlighted several interesting examples that illustrate the
strengths of this modeling approach, with emphasis on multiple
domain simulations.
Introduction to VHDL-AMS
VHDL-AMS is a set of analog extensions to standard digital
VHDL to allow mixed-signal modeling of systems. The VHDL-
AMS language was approved as IEEE Std 1076.1 in 1999; how-
ever, it is important to note that IEEE 1076.1-1999 encompasses
the complete digital VHDL 1076 standard and is not a subset.
The standard does not specify any libraries for analog disciplines
(e.g. electrical, mechanical, etc.). This is a separate exercise and is

covered by a subset working group IEEE 1076.1.1, which was
released as an IEEE Std 1076.1.1 in 2004.
In order to put the extensions into context it is useful to show
the scope of VHDL, and then VHDL-AMS alongside it and this is
shown in Figure 46.
The key extensions for VHDL-AMS is the ability to look upward
to transfer functions (behavioural and in the Laplace domain) and
downwards to differential equations at the circuit level.
Ch17-H6845.qxd 4/5/07 11:39 AM Page 190
VHDL-AMS
191
The extensions to VHDL for VHDL-AMS can be summarized as
follows:
1. A new type of ports called TERMINALS – basically analog
pins.
2. A new type of TYPE called a NATURE that defines the rela-
tionship between analog pins and variables.
3. A new type of variable called a QUANTITY that is an ana-
log variable.
4. A new type of variable assignment that is used to define ana-
log equations that are solved simultaneously.
5. Differential equation operators for derivative (‘DOT) and
integration (‘INTEG) with respect to time.
6. IF statements for equations (IF USE).
7. Break statement to initialize the non-linear solver.
8. STEP LIMIT control for limiting the analog time step in the
solver.
Analog pins: TERMINALS
In order to define analog pins in VHDL-AMS we need to use the
TERMINAL keyword in a standard entity PORT declaration. For

example, if we have a two pins device that has two analog pins (of
Level Content
System Specification
Chip Algorithms
Register
Truth Tables
State Tables
Logic
Boolean
Equations
Circuit
Differential
Equations
System Transfer Function
VHDL
VHDL-AMS
Figure 46
Scope of VHDL-AMS
Ch17-H6845.qxd 4/5/07 11:39 AM Page 191
Design Recipes for FPGAs
192
type electrical, more on this later), then the entity would have the
basic form as shown below:
LIBRARY IEEE;
USE IEEE.ELECTRICAL_SYSTEMS.ALL;
ENTITY model IS
GENERIC();
PORT(
TERMINAL p : electrical;
TERMINAL m : electrical

);
END ENTITY;
Notice that as the VHDL-AMS extensions are defined as an
IEEE standard, then the use of a standard library such as electrical
pins requires the use of the electrical_systems.all; packages from
the IEEE library.
Notice that the pins do not have a direction assigned as analog
pins are part of a conserved energy system and are therefore solved
simultaneously.
Mixed-domain modeling
In order to use standard models, there has to be a framework for
terminals and variables which is where the standard packages are
used. There is a complete IEEE Std (1076.1.1) which defines the
standard packages in their entirety; however, it is useful to look at a
simplified package (electrical systems in this case) to see how the
package is put together.
For example, electrical systems models need to be able to handle
several key aspects:
•
Electrical connection points
•
Electrical ‘through’ variables (i.e. current)
•
Electrical ‘across’ variables (i.e. voltages)
The electrical systems ‘package’ needs to encompass these
elements.
First, the basic subtypes need to be defined. In ALL the analog
systems and types, the basic underlying VHDL type is always
Ch17-H6845.qxd 4/5/07 11:39 AM Page 192
VHDL-AMS

193
REAL, and so the voltage and current must be defined as subtypes
of REAL:
Subtype voltage is REAL;
Subtype current is REAL;
Notice that there is no automatic unit assignment for either, but
this is handled separately by the UNIT and SYMBOL attributes in
IEEE Std 1076.1.1. For example, for voltage the unit is defined as
‘Volt’ and the symbol is defined as ‘V’.
The remainder of the basic electrical type definition then links
these subtypes to the through and across variable of the type,
respectively:
PACKAGE electrical_system IS
SUBTYPE voltage IS real;
SUBTYPE current IS real;
NATURE electrical IS
voltage ACROSS
current THROUGH
ground REFERENCE;
END PACKAGE electrical_system;
Analog variables: quantities
Quantities are purely analog variables and can be defined in one of
three ways. Free quantities are simply analog variables that do not
have a relationship with a conserved energy system. Branch quan-
tities have a direct relationship between one or more analog termi-
nals and finally source quantities are used to define special source
functions (such as AC sources or noise sources).
For example to define a simple analog variable called x, that
is a voltage (but not related directly to an electrical connection
(TERMINAL), then the following VHDL could be used:

QUANTITY x : voltage;
On the other hand, a branch between two electrical pins has a
through variable (current) and an across variable (voltage) and this
requires a ‘branch’ quantity so that the complete description can
be solved simultaneously. For example, the complete quantity dec-
laration for the voltage (v) and current (i) of a component between
two pins (p & m) could be defined as:
QUANTITY v across i through p to m;
Ch17-H6845.qxd 4/5/07 11:39 AM Page 193