The Tao of EE183
This page collects miscellaneous tips
and pointers on the projects, tools and concepts in EE183, as well as
describing the general design procedure. Have anything to add or
subtract? Please email the TA! (Updated 13-Jan-2003)
Using the FPGA Boards
Here is the general information you will
need for implementing your designs in the FPGA demo boards. You can
download a copy of the manual from the Xess website
if you want more details.
- Xess FPGA Board Hints:
- Testing your board.
Each computer has a program called gxstest installed with the
XSTOOLs which will test your board to make sure it is functioning. In
order to run this test you simply select the board type (XSA-100), plug
in the power and the programming cable, and click test. Note, however,
that the tests will not work if you have any external components
connected to the board. That means you need to unplug any
controllers or VGA output or anything except the XStend board. This is
particularly true if you have used any of the FLASH pins as they are
used for testing the board.
- Hooking up the board.
To use your board simply plug in the power supply (between 6 and 9V,
please) and the parallel cable for programming.
- Hooking up external
When attaching external signals it is CRITICAL that all
components share the same ground and that all signals into the board be
between 0 and 5V. (The FPGA operates and outputs at 3.3V, but will
accept 5V signals.) The best way to destroy your board is to put in a
signal below 0V. The best way to get strange behavior out of external
components is to have different grounds. Conclusion: ALWAYS test
every input on the scope to make sure it is between 0-5V before
attaching it to the board.
External clocks should be connected to pin 73 on the XSA board. This is
listed as "SPARTAN-CCLK" in the documentation. Please verify that all
external clocks are between 0-5V as the function generators will
default to -2.5 to 2.5V which is not good for the boards. The
XSA boards also have a CPLD (configurable, programmable logic device)
which can generate various clock frequencies by itself. There is a
XSTOOL program gxssetclk for configuring the on-board clock. You can
configure this clock for a speed between 100MHz and 48kHz. See pages
22-23 of the XSA Board User Manual.
- The XStend Board.
Please be aware that the XStend board supports several different FPGA
boards and that you need to insert the board into the correct place on
the XStend board. With the two seve-segment 8 displays on the bottom of
the board towards you, the XSA-100 board should be inserted on the
RIGHT so one row of holes is visible on the LEFT side closest to the
prototyping area and the three buttons. Please be very careful when
inserting/removing these boards as you may damage them.
- General Board
Care. Make sure that any signals you put
into the board are limited to 0 to 3.3V and
that you don't try to draw too much current
from any output. (Insert a 470 Ohm current
limiting resistor in series with your output
if you're not sure, or just ask.) Also, please
try not to damage the FPGA boards by dropping
them or spilling drinks on them. Please also
store the boards upside down so static doesn't
build up on the pins.
- Verilog Hints:
You may need to configure the license file for Foundation. Information
for Stanford students can be found here.
- FFs and Clocks.
Any storage elements you wish you use MUST be instantiated from the
EE183 FF library. This means you may NOT ever use @ (posedge clk) or any
other clock dependent (asynchronous) logic. This also goes for
non-blocking assignments, ifs without elses, and cases without
defaults which infer storage. Trust us: this will save
you a lot of debugging time! (The one exception is to make a single
global "slow clock" by dividing down the global clock for purposes
such as debouncing inputs.)
- Inferred Storage.
To avoid having the compiler infer storage elements (flip-flops) for
you you simply need to make sure that every possible case is defined
in combinational logic. This means that for every if/else-if you must
have a final else with no dependencies to catch other cases and that
for every case you must have a default. Also, do not use the
non-blocking (<=) assignment operator.
- Combinational Logic.
Remember to include any wire on the Right Hand Side (RHS) of any
expression in an always block in the sensetivity list for that
block. Otherwise it will not be examined to see if the logic needs to
change and you will end up creating inferred flip-flops. (Think about
this until you understand why because it is important.)
All FMSs in EE183 consist of a state register (a bank of
flip-flops) and then a big combinational statement which determines
the next state based on inputs and writes it to the inputs on the
flip-flops so it will be updated on the next clock. This boils down to
a long case statement on your current state with EACH AND EVERY case
FULLY defining the next state AND any outputs. (That is, even if only
one bit in your state or output changes you MUST explicitly set all
the bits or it will infer more flip-flops (i.e., extra states). Hints: Use
the define statement to give your states human-readable names. Let the
compiler optimize your logic, so you should just make it easy to read.
- More on FSMs.
All FSMs should have a RESET signal and an ENABLE signal. Most of the
time the RESET will just go to the state FFs to set them to state
0. The ENABLE signal is required to allow other master state machines
to control this one. By using such a scheme you should be able to
avoid the use of tri-state (Z) outputs, which can be hard to debug.
- What you think you can do, but can't.
The verilog syntax has a lot of very nice constructs such as * / %
for and while which do NOT map into logic. This means that
you can write legal verilog which will simulate as you expect it will
NOT translate into hardware. See the Verilog handout section 14 for
details. If it seems too good to be true (i.e., automatic instatiation
of single-cycle 32-bit multiplier) then it probably is. Feel free to
The simulator we are using will sometimes not let you view a wire deep
in your design and you will have to manually bring it up to the top
level to view it. Try VERY hard to design and test each component
separately so you don't have to debug many levels down. Remember that
if something gives you a syntax error and you have no idea why or if it
just doesn't work that a very good way to figure out your error is to
comment out code around that area until you find out what does make it
work and then go backwards from there. If you're trying to simulate
a ROM make sure you use a distributed RAM for the simulations. You
should then switch to a standard Block RAM for your final ROM, but it
The Xilinx CoreGen module allows you to create optimized multipliers,
filter, ROMs, RAMs, and a whole lot more. You use it through a very
simple wizard-like interface and then you instantiate your module in
your design. However, if you don't understand what all the options in
the wizard are, you will probably not end up using the component
correctly, so please read the documentation and ask the teaching
staff. (I.e., if you're not sure what 'registered outputs' are or why
you might or might not want them you should ask instead of accepting
the default value.)
The week before each lab you are required to turn in a pre-lab report
which wil be worth 2 of the 20 writeup points. This pre-lab should
contain details on how you plan to implement your design including
overall architecture and state diagrams. Ideally this
should exactly form the Design section below, but you will probably
have to change some things during the implementation. The better a job
you do on your pre-lab the easier your implementation will be, so
please put some effort into the pre-lab!
The reports should be thorough enough to demonstrate what you did and
what you learned and to allow another person to replicate your
work. However, you do not need to spend a lot of time on the problem
you are solving as it is defined in the lab itself. (That is, you
should say "I implemented Conway's game of life" and not spend a page
describing the details of the game, but you must describe how you did
your memory access to calculate the next state, for example.) You must include the following,
with Simulations, Implementation, and Performance metrics forming
appendices to your actual report. Remember: someone is going to have
to read this so the point is NOT to make it long. Make it short and
sweet while covering the key points and features of your design and
why you chose them. Your code will be examined, but it will be
impossible to understand if your description of your design is not clear.
- Format = PDF.
All EE183 reports must be submitted in PDF format. You can find PDF
writers on all the lab machines or via ghostscript on the Sweet Hall
machines or under linux. Under Mac OS X you can choose "Save as PDF" from the
print dialog. You should put all documentation together in one pdf file
and submit it to the TA either by email (if < 1MB) or by posting it on
your web page and emailing a URL to the TA. All files should be in the
format of firstname_lastname_lab#.pdf, please!
- Title page - name, project, date
- Introduction - what you did
- Design - how you did it (hierarchy and design decisions;
descriptions of FSMs and how they interact go here. E.g., block
diagrams and flow charts. List any design aids (such as CoreGen
modules) and how you used them and how they work. Basically whatever you think it takes to make it clear
to the TA how your design works and interacts.)
- Results - how it worked out (including top speed and area
- Conclusions - what did you think of it? Was it a good/bad design/
implementation? Why?? What would you do differently next time?
Any comments on the lab itself are most appreciated.
- A1. Simulations - show KEY simulations and scripts. You MUST
annotate the simulations so the TA can see what is happening and why
this is important. This should directly relate to the design above and
show why it was a good/bad one. A minimum of about 3 simulations is
expected, although the basic rule of thumb is that you should have one
simulation per module.
- A2. Implementation - your verilog code. All of it, with enough
comments so the TA can read it and understand it. Specific modules
should be referenced from the Design section above. Any pinouts should
be noted along with any CoreGen modules. The best way to get this is
to use Foundation to print out your code to a pdf file and then use
acrobat to add those pages on to the end of the rest of your
report. This will ensure that all the key words are in bold making it
easier to read and saving you a lot of copying and pasting.
- A3. Performance metrics - a screen shot of your layout on the FPGA,
timing and usage reports. You can get the timing info from the
"Post-Layout Timing Report" for which you will have to implement as
well as synthesize your design. You can get a screen shot of the
layout (floorplan) from the Floorplanner under the Tools menu (again,
after implementing). Timing information must include the maximum
clock speed and the longest logic delay and what was
causing it. Usage should include the number of blocks and the
percentage of the FPGA used.