The Adventure Begins...

Well, let's assume that you've taken the tips on writing synthesizable VHDL to heart.  You still
have to know about how to use and deal with the synthesis tools.  They aren't really all
that friendly when it comes down to it but it could be worse - you could be designing your system
with TTL chips exclusively...

Before you start synthesizing, make sure you do the following (assuming you work under Unix):

• Go to a directory that contains all of your VHDL files.  Then create a subdirectory within

this directory called "default" or "working" or whatever.  You may already have a directory
called "work" because of QHSIM simulation.  That's ok - you can use this if you like.  Just
remember that QHSIM has to find your compiled files later.  Whether it's your present
working directory or whatever, you'll have to refer to the name later.

Then, within your top level file, you'll need to create references to this directory so that
Actmap can find them.  For example, let's say you have a component for your top level file
called "display", and you're using the "work" directory to compile into.  In the "for-use"
section of your file, you'd type:
    for all: display use entity work.display(behaviorarch);
This tells the Actmap compiler to use the pre-compiled entity "display" with its associated
architecture "behaviorarch", located in the "work" directory.  You then do this for all of the
rest of the components you include in your top-level file.
Note:  "display" does not refer to the file name but to the entity name within the
file you want to include!

• Make a backup of your files, either by zipping or tarring them somewhere, or just copying

them in a directory, just in case they get overwritten or other chaos happens.
• Eventually, you will need to refer to the Act 1 macro libraries when you compile a VHDL

file extracted from the synthesis.  To do this, open a text editor and type the following:
   qhmap act1 /opt1/actel/lib/vtl/95/qhdl/act1
(or whatever the equivalent directory on your system is).  This allows Mentor to find the
files for compilation and simulation.  Save this file as "act1link" and then at the shell
prompt type:
    chmod u+x act1link
This allows the file to be executed under Unix much like a batch file in DOS.  You'll get
a message after you type "act1link" that tells you it's done the linking.

Another way of doing this is to set environment variables manually (assuming you have a
proper quickhdl.ini file).  In the CEB531 labs (and I believe elsewhere too), at the
command line, type:
    setenv QUICKHDL /opt1/actel/lib/vtl/95/qhdl/quickhdl.ini
    ln -s $QUICKHDL
This links the "quickhdl.ini" file to your directory.  However, you may need to substitute
the path in that statement with:
    setenv QUICKHDL /opt/actel/lib/vtl/95/qhdl/act1/quickhdl.ini
I'm not sure about this however.  I personally prefer the first method, though you have to
type "act1link" in to get things going right.

• Ensure you have access to the following programs on your system:

        Actmap
        Designer (or Designer Lite which handles parts up to the Act2 series)
        edn2vhdl
        Design Architect or qvhcom (from Mentor Graphics)
If not, contact your system administrator and have him/her tell you where to find them.
You likely won't be able to go follow what I'm talking about unless you have these.
• Ensure that you set the libraries in your VHDL file to std_logic_arith.all as opposed to

std_logic_unsigned.all; the latter doesn't work with Actmap.
• Have a copy of the databook for the FPGAs.  You can get a free copy from Actel if

you don't have one already.  You can also get a copy of Actmap and Designer.

Tools Overview

The diagram below represents the general design flow that may be used with the tools.
Depending on what you're trying to do, you take a different route.

Starting Off With Actmap

Start up a terminal or shell window, and type:
    actmapw&
which starts the Actmap program.  You'll see a large text screen come up with Actmap in the
menu bar.  Click on:
    File -> VHDL Compiler
and a new window will come up.  There's lots to look at here, but don't worry - it's all fairly
straightforward.

In the "Source" box, you type the complete file name and path of the individual components
you're using.  Going back to the "display" example, you'd type:
    /ceb531/users/studentlogin/VHDLfiles/display.vhd
within the box (or simply use the "Browse" button to search within your directory).  If you leave
the "Target" box blank, you'll have a file name automatically generated with the .edn extension
as the compiler runs.  But you want your files to compile inside the "work" directory.  Copy
the above path into the "Target" box and modify it to read:
    /ceb531/users/studentlogin/VHDLfiles/work/display.edn
That will generate the .edn file within the directory.  A .edn file is an EDIF format file, so make
sure that the generated file type is set to EDIF in the select box (as opposed to Verilog or
whatever other choice it gives you).

There are other compile options which I'll go over here:

• Map Style - there are three options here:  Area, Speed, and Noopt.  Area compiles

VHDL code so that it takes up less space.  Speed  compiles the VHDL code for
faster operation, but usually takes up more space.  I say "usually" because sometimes
compiling for speed makes the design faster and smaller.  Don't ask me why, but it
does.  The speed-area tradeoff is the biggest battle when dealing with FPGAs, so be
aware of this as you go along.
• Family - select the chip family you're using.  In this case, it would be the "Act1"

family, but you could also choose Act2, Act3, 3200DX or whatever else it has in there
if you're using those parts (and I'm not covering anything but Act1 here).
• State Encoding - there are a lot of options here.  I usually leave it at "Compact", but

you may need faster encoding, such as "One-hot".  Read the help file if in doubt.
• Effort - Everything from "Low" to "High" is here.  Always set this to "High", because

there's no sense in sacrificing a few seconds of processor time for a larger design.  Of
course, if you're running Actmap under Solaris on a 486/25SX...
• Mode - this one is important.  Choose "Block" when you are compiling components

that are not in the top level of your design.  Choose "Chip" to compile the top level
VHDL file after you've compiled all of your components.  If you forget to compile
your components first, Actmap won't compile your top level.  If you forget to compile
the top level as a chip, Designer will bark at you complaining there are no pads
connected to the I/O.

You may also want to use "Chip" if you are testing a particular component for
behavior and to extract the delays, but beware - the input and output buffers will add
delays that won't be included when your whole design is compiled.

• Max Fanout - Actel FPGAs can have an internal signal fanout of up to 16 without

affecting the performance.  Above a fanout of 16, signal driving can be weak and
cause excess delays.  The maximum allowed fanout is 24, because the FPGA will
not necessarily work with such a large fanout (too little current driving too many
inputs).

If you have a signal that exceeds a fanout of 16, you have two options:  modify your
VHDL code to map the signal to two different signals and assign them equally
among the destinations, or manually insert a number high enough to accommodate
the signal with the highest fanout.  You can't find this out until after you've run your
Actmap compilation, but the entire process is iterative.  Designer will not deal with
your design if the maximum specified fanout is less that the fanout generated in the
.edn file from Actmap.

• Flatten - not too sure about this option.  I leave it at the default value of "No", and

it hasn't caused me too many problems.

Remember, you can only have 295 modules for the A1010 part, and 547 modules for the
A1020 part.  You can't exceed this under any circumstance, so if tit happens just minimize
your design by modifying the VHDL code or using the Netlist Optimizer (see below).

Beware:  you cannot have more than one clock buffer for the Act1 FPGAs.  If
you compile your code and you have 2 or more ClkBufs in your design, Designer
will not be able to do its job properly.  This can happen because of multiple
processes with event triggers from signals other than the system clock.

To run the Netlist Optimizer, close the Compile window and select:
    File -> Netlist Optimizer
from the main Actmap window.  It should bring up a window similar to the VHDL
compiler window.  It also should fill in the "Source" with the name of the EDIF file you
just created (the .edn file), and in the same path.  Modify this accordingly if it isn't, and
just leave the "Target" blank.  Set your options as you did before with the compiler
and run.  You can compare your optimized file (a .edo file, same EDIF format) to the
previous file and see the changes in timing and modules, if any.

The best way to familiarize yourself with this process is to experiment with the options and
find what best works for you.  Ultimately, your goal with Actmap is to compile your top
level file so it meets the constraints as indicated above, and obtain a .edo file from that top
level (which I will refer to as toplevel.edo).
 

Fun With Designer

Now that you have your top level compiled as an EDIF file, you can use Designer to
lay out pins, specify delay targets, extract timing information and write a fuse file.  The nice
thing about Designer is that there is a quasi-flowchart that's clickable, so you're not totally
lost.  In fact, it's fairly intuitive.

First, click on "Compile".  Designer will ask you whether or not you want to start a new
or existing design.  Just click on "New".  You'll then be presented with a new window that
contains several options.  Make sure the "Netlist Type" is set at "EDIF".  Also make sure
that the style parameters are both set at "Generic".  Then use the browse button to find the
toplevel.edo file.  Load this and click on "Ok".

A window will appear which has a list of the available Actel parts on the left, and the
possible packages for each.  So, say you have a 270 module design for your toplevel.edo
file.  You can choose an A1010B with a 44-pin PLCC, or an A1020B with a 68-pin
PLCC.  As long as the design fits both in modules and available I/O pins, you'll have no
problems.  Note: the 44-pin packages have 34 I/O pins, while the 68-pin packages have
57 I/O pins.  Make sure that your top-level entity doesn't have more I/O than you need.

Click "Ok".  Yet another window will pop up, called the Operating Conditions,
which contains Speed Rating, Temperature Grade and Operating Voltage.  Unless you
have something different than the standard, just leave these alone and click on "Ok".  The
design will compile and indicate any errors or warnings about the design.  If there are any
errors, you have to go back and remodify your code, recompile the toplevel.edo file in
Actmap and try again, or modify some of the Actmap compile options.

Once this process is finished, you can do two things - edit timing specifications with the
DTEdit tool, and edit pin assignments with PinEdit.  I'm not going to cover DTEdit since
I've never needed to use it, but PinEdit is very useful...

If you click on PinEdit after compiling, you'll be presented with a window that has a
symbol of the FPGA you're compiling for on the left, and two lists of pins:  assigned and
unassigned.  If, for example, you want to keep pins for an 8-bit wide signal together,
you just drag the unassigned pin names to each of the empty I/O pads.  Once you've
assigned your pins, you can click on:
    File -> Commit
to commit those pin assignments.  You can also print the diagram you've created by
using:
    File -> Print
and save the diagram image as a Postscript file (.eps format).  There are two important
points to remember in this step:

• Routing pins according to wiring "convenience" may make routing more difficult

for Designer in the final stage.  You may instead want to accept the defaults that
Designer generates, because additional delays may be accumulated.
• You can only assign certain signals to certain places.  So, if you have a system

clock, it must be on the "Clk" pin.  If you want to use the probe pins "PRA" and
"PRB", the assigned signals must be inputs.  And you can't move the power and
ground pins around or assign signals to them.

Now you've come to the final step.  Almost.  Sort of.  You can either write a fuse file
with the Fuse button, or extract your timings for back-annotated simulation with the
"Extract" command.  If you want a fuse file to burn, click on "Fuse" and a small window
will pop up with a prenamed fuse file in .afm format.  Click on "Ok" and you'll get the
fuse file to use with the FPGA burner.

The "Extract" command is extremely important.  What it allows you to do is extract the
delays created by the FPGA implementation of Designer, so that they can be used to
simulate the actual design, as it would behave, with all delays accounted for.  To get
this file, click on the "Extract" button.  A small window appears, which lists the target
directory (should be "." or the current directory), the "CAE" and the file name.  If you
want, you can change the file name to something other than what it gives you.  But the
important point is to change the CAE format to one compatible with the simulation
tools you use.  The default format is "Generic", but for Mentor's QHSIM, you should
change this to "SDF" (not SDF1.0).  Click on "Ok" and you'll generate a file in .sdf
format (which I'll assume to be called toplevel.sdf).  Then close Designer and, if you
wish, save the project when prompted.
 

Back-Annotated Simulation

Before you can run a back-annotated simulation, you have to prepare several files.
First, copy your toplevel.edo file to another name, for example:
    cp toplevel.edo toplevel_final.edn
It's important to copy to a file with a .edn extension.  Now, providing you ran your
library mapping program, you can convert this copied edn file (which is actually your
optimized EDIF file from Actmap) to a structural VHDL file again by issuing the
command:
    edn2vhdl fam:act1 toplevel_final
Don't use the .edn extension with the file name, or edn2vhdl won't find the file.  This
generates a file called "toplevel_final.vhd".  You can compile this either under Design
Architect or with qvhcom.  Assuming that the libraries are properly referenced, you
will get a compiled design.  If you open toplevel_final.vhd in a text editor, you'll see
that your entity is basically unchanged, but that your architecture is totally different.
This is because it uses standard Actel macros for gates and flip-flops.  And note that
the architecture is now called DEF_ARCH.

Now, to use the .sdf delay file with your design, you start QHSIM by typing at the
command line (not through Design Architect, which you can close):
    qhsim -sdftyp toplevel.sdf &
QHSIM will come up with designs in the work directory, or modify the quickhdl.ini
file if this isn't the case.  Click on the "toplevel" entity, and choose the DEF_ARCH
architecture if not selected.  Then QHSIM will load the .sdf file and all of the
libraries it needs to simulate your top level design.  You can use a command file to
simulate all of your signals.  I personally prefer the command file to the test bench,
unless I have extremely detailed test cases.
 

So Is That It?

Well, not quite.  You may find that your design doesn't run properly under QHSIM
when back-annotated.  Sometimes things don't synthesize properly, and sometimes
they may synthesize into "black boxes" or modules that are never intended to be
used in the way you want them to be used.  It's important to back-annotate your
simulation, or at the very least simulate your extracted VHDL file from your .edo
file.  I've found in my EE552 project that our design worked perfectly in behavioral
simulation, only to have problems when back-annotated.  No evidence of anything
bad ever came to me while going through the procedure.  Yet, had I burned the
FPGA with the fuse file before simulating it, I would've used my chip for nothing.

My most sage piece of advice when it comes to FPGA design is don't assume that
a design works because its simulation works.  It's reassuring to see that I have
setup time violations on my flip-flops when I run my clock frequency too fast, and
that I don't find this out after I've implemented my design.  It's a lot easier to change
a piece of code or modify a technique than it is to waste money and silicon.

Click here to see some miscellaneous items not covered above for our project.

Copyright 1997 Mike Daskalopoulos and Ishfaqur Rahman.  All rights reserved.
Read this legal notice before using any information contained in this document.