The source and/or object code (subsequently referred to as code)
presented in this and subsequent lessons is the property of
saxelec.com and owner who retains copyright protection. This code in
whole or in part is licensed only for single copy per user,
non-commercial use; except in the case of educational institutions,
where a license of single copy per student, only as part of course
curricula, is permitted.
Donald Gerard Polak (owner)
Starting an ISE Project
Let's start by debugging our project using the Xilinx ISE tool.
We will use a low cost device, the Spartan 3, XC3S200AN, in a FBGA,
256-pin package that will fit in the width profile of the
original 40-pin DIP package; i.e. it can be placed on an adapter
assembly to build a drop-in replacement.
We start by launching the ISE tool. If there is no current project,
you can just select the "New Project" button. Otherewise
select the "File" pulldown menu on the top bar and then
select "New Project" from the pull down list.
When the new project dialog box opens, assign a name to your project.
This is usually the top level module name, so we enter s8085d_r. When
you are using ISE, there are no particular restrictions on the project
name, but many other synthesizers require the project name to match
the name of the top level module. Get into the habit of naming your
projects after the name of the top level module to avoid future
issues. You will notice that as you fill in the project name, it is
automatically appended to the location and working directory names.
This is an effect particular to ISE, and some designers prefer it that
way. However, if you let ISE create these new directories, it will
impede updating the original source and re-synthesizing. I usually go
to the location and working directory names and removing the
concatenated project name.
ISE New Project Dialog
You may also write a comment about you IP in this window. When you
are finished, click the next button to proceed to the assignment
The assignment dialog allows you to set the target device, simulation
tool, language, and cerain other values. We are not using an
evaluation board, so we set that value to "None". To get
to the Spartan3AN family you can either set the "Product
Category" to "All" or "General Purpose".
Set the device family to "Spartan3A and Spartan3AN". Now
set the device to "XC3S200AN". This device is only
currently available in the FTG256 package, so it should default.
We wnat to select the fastest speed grade, "-4".
There is only one synthesis option, "XST (VHDL/Verilog)"
so you don't have to worry about it. I also let the simulator default,
but if you wish to use it, set this value to "ModelSIM-SE
Verilog". Obviously you need to set the preferred language
to "Verilog". Property specification may be defaulted to
"Store All Values". We want "Manual Compile
Order" and "Message Filtering" turned off.
The current ANSI VHDL standard is VHDL-93 so, therefore, this is
what we have selected for the VHDL analysis standard. For this project
this value is meaningless, so you can just choose the default.
ISE Assignment Dialog
Once you have completed making your assignments, click the
"NEXT" button. a project summary box will then appear. If
you are satisfied with the summary, click the "FINISH"
button to create your project.
Adding Source Files
Before we add our source to the project, we want to enter a line
into it so it will automatically load our definitions file. Although
ISE can process the definitions separately, some synthesis tools
will not process files that do not contain any RTL code.
We need to enter the following line into our source file, prior
to the first module declaration :
Now that we have our source code ready, we need to include it in
our project. To add files to a design, you may click on the
design tab in the lower portion of the left hand window and the
click on the second icon from the top in the sidebar tools.
ISE Add File to Design
As an alternative, you may select the "Project" pull down
menu on the rop menu bar, and then selct "Add Source" from
the menu options.
Either method opens a standard window "Open File" browser
dialog. Using the file browser, selct the directory wher you placed
your files, and then add your source file to the design. For our first
synthesis, we are nor adding any constraints, so this is the only
file you need to add at this point.
Setting ISE Synthesis Options
Before we can begin synthesis, we need to set certain ISE options.
Because we are using coded fields and direct output signals in
our state machines, we need to set FSM encoding to "User".
ISE also has a tendantcy to build mux trees out of certain Verilog
constructs, so I generally turn off automatic mux extraction.
On the left hand menu. right click over "Synthesis - XST".
When the pull down menu appears, select "Process
Properties". The synthesis options dialog will appear with
"Synthesis Options" selected. Set "-opt mode" to
"Speed$quot; and "-opt level" to "High". To
assist in debug, we want to set the "-keep hierarchy"
option to "Yes". You may let all the other options
We now select the "HDL Options" category from the option
menu on the left hand side. We set the "-fsm_extract,
-fsm_encoding" property to "User" and the
"-safe_implementation" style to "No". The
"-vldcase" option should be "Full - Parallel" and
both "-mux_extract" and "-decoder_extract" set to
"No". All other properties may be defaulted.
To prevent certain untraceable errors, we must also go to the
"Xillinx Specific Options" and disable equivalent
register removal. Once you have set the process properties properly,
click on "OK" to update the values and close the dialog.
ISE HDL Options
Now we can run our first synthesis and start removing synthesizer
errors. First we select the "Project" pull down menu on
the top bar. From the pull down menu select "Design
Summary/Reports". Now we cursor over "Synthesize - XST"
on the left hand menu, and double click.
Oh oh, we have some errors, Who would have guessed that we would have
synthesis errors in 13,000 lines of code? Anyhow, let's look at them.
ISE has several methods to view these errors. You may scroll the
console window at the bottom of your screen and look for them. This
method is handy when you are trying to locate the particular module
where the error occurred. You may also click on the "Errors"
tab at the bottom of the left hand window. There are also two
separate links in the design summary report window to look at
these errors. If you require the full information concerning the error
you can look at the synthesis report under "Detailed
Reports". You should try every method so you are familiar with
When we look at the errors using the "Errors" tab from
the bottom of the left hand menu; and view the following:
ISE First Synthesis Errors
We can see a couple of signals that don't appear in the module
declarations. We must first examine the module itself, to see if
we are still using that signal in the module. If we aren't then
remove that signal from the input or output signal list and make sure
that no module instantiations include it in their instantiation
signal list. If we are, then we need to add it to the module
declaration, and make sure that it also connected in any module
On line 3346, "addend1" is an artifact of the movement
of that signal to "source_sel_r" in
module 3, lesson 1. We simply
want to remove that signal from the output declarations in
We see something similar going on with the "sel_inc" signal
on line 6130 in "sequencer_r". Signal development was
moved to "inc_log_r" in module 2, lesson 2, bit, again, we left an
artifact. Just as in the former case, we want to remove it from the
When we make these corrections and rerun synthesis, we get the
following errors and warnings:
ISE Second Pass Synthesis Warnings
When we start analyzing at these errors and warnings, we see that
we have intp in the output list in "aequencer_r". Even
though it is not tied to any output logic, the synthesizer will
tie it to ground and drive it as an output anyway. Therefore we
need to transfer it to the input list and remove the "wire"
declaration for "intp" in "sequencer_r".
We also observe that we accidently duplicated the mux for temp
upper source in the lower source mux portion of
"source_sel_r". We have to remove this extra occurrence.
There were some duplicated case statements in the microcode state
machine. These extra cases also have to be removed.
"int_trap" appears as an input to module
"int_xlat_r", but is not needed, since this is the
default vector. It can be removed from this module port list,
input list, and the module instantiation.
We see that "add_of" is missing from the carry calculations
in "flag_logic_r". We need "add_of" to calculate
the carry for sixteen-bit add and subtract operations.
"sel16" is used to choose between "add_cy" and
"add_of" for carry calculations.
We brought all eight of the current flags into "alu_r" and
"flag_logic_r". However, we are only using the auxiliary
carry flag, the carry flag, and the negative operation flag. All
the rest are left dangling. Therefore we need to only bring in the
flags taht we are actuallly using. This involve creating additional
input signal names to attach the flags, and changing the module port
lists, the module input lists, and the module instantiations for
all affected modules.
In this fix, remember to apply the conditional compiles to
the negative operation flag, because it is only used for the
S8085C and S8085D models.
This same scenario is present in "sequencer_r" and
"flags_r". The "pmatch" signal equations
use all flags, except the auxiliary carry and negative operation
flags. In addition, we did not use the flag position parameters to
denote the flags we do use. This is poor coding practice. Therefore,
we just create new signal names and bring in only the flags we do use
and rewite the equations appropriately.
The signal "multplicand" was a spelling error. The remainder
of the connectivity warnings were artifacts of earlier architectures.
Once we correct these warnings, we are left with the following source
Updated project source file.
Now, when we rerun the synthesis, we get the following warnings:
ISE New Synthesis Warnings
Although these are warnings, they concern combinatorial loops.
Combinatorial loops discovered during synthesis are particularly bad.
Although ISE could potentially handle these loops correctly, The
routing of these loops could cause unacceptable delays in all other
logic, logical errors, and/or propagation glitches. They must be
Eliminating Combinatorial Loops
We can see from these warnings that the sources of these loops
originate for modules "serial_r" and
"dest_sel_r"; but not much else. We also need to look
at the signals involved. On the center pane of the ISE screen
look for the box next to "Detailed Reports" and click
on it until the minus sign ('-') appears in the box. You should
now see "Synthesis Report" appear as one of the options
under "Detailed Reports". When you click on this
option you will see the full text of the synthesis report.
Scroll through the report until you see the warnings. They will
have a highlighted hyperlink, so they are easely visible. Do not
click on the hyperlink, as it will only give you a generic explanation
of the error. Instead, scroll horizontally to the signal list. I
generally copy the signal list into a word processor (jEdit) and
break the signal list apart so there is one signal per line. Do this
with all the warnings. When we follow these instructions we get the
Combinatorial loop signals.
In the first loop we see "swint" appear several times. We
also see the interrupt vector signals appear. Both originate from
a direct decode of the instruction latch. ThHe instruction latch
is a transparent latch, and the source is the destination bus. the
results of the decode feed the destination bus, hence a combinatorial
loop. To fix this issue we can source the instruction latch
directly from the address/data pins. This fix has the added advantage
of faster instruction decodes.
In the second loop we see several signals associated with the
adder, the incrementer and "res_dest" which is only used in
flag generation. This indicates that there is an issue with the flags.
When we start digging deeper, we find that there are also issues with
the flags from the "DSUB" instruction and the carry from
the logical instructions and the "DADx" instructions.
Part of the problem is the flag load enable. Currently this signal
loads the flags from the destination bus. However, the flags also
are used to create signals on the destination bus. There is also
minimum justification for using a separate "res_dest"
bus to generate flags. The suspect flags are carry, auxiliary carry,
and unsigned indicator.
We address these issues by adding a separate mux to handle flag load
enable. This mux is fed from the modified flags and the address/data
bus. We also update the flag mask generation logic, replace the
"res_dest" bus with the "dest" bus, add auxiliary
carry generation to the logical block, and fix the adder and
incrementer blocks to generate carry, overflow, and unsigned indicator
flags. We also update "flags_r" to fix the flag masks.
The third loop indicates the same issue that we saw in the first
loop. We see "swino" appear several times. Fixing
the first loop should also fix this one
Once we have made the required changes we obtain the following
New project source file.
When we rerun the synthesis with this new code, we see that we have
successfully eliminated all warnings and errors.
What must we do to the FSM options? Why? How?
Download ISE and create a project.
How can you access the synthesis report?
What problems can combinatorial loops cause?