Home





Course Facts Calendar Handouts Datasheets Links Contact Information
Tao of EE183
 

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.

  1. Xess FPGA Board Hints:
    1. 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.
    2. 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.
    3. Hooking up external components/signals. 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.
    4. Clocks. 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.
    5. 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.
    6. 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.
  2. Verilog Hints:
    1. Foundation. You may need to configure the license file for Foundation. Information for Stanford students can be found here.
    2. 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.)
    3. 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.
    4. 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.)
    5. FSMs. 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.
    6. 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.
    7. 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 ask.
    8. Debugging. 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 won't simulate.
    9. CoreGen 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.)
  3. EE183 Reports:
    1. 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!
    2. Pre-labs. 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!
    3. Contents. 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.
      1. Title page - name, project, date
      2. Introduction - what you did
      3. 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.)
      4. Results - how it worked out (including top speed and area usage)
      5. 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.
      6. 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.
      7. 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.
      8. 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.
        9.