ICED Design Steps Outline

This document attempts to give the big picture of the design flow in the URI ICED (Integrated Computer Engineering Design ) curriculum. Students and faculty not in the ICED program may also use it to take advantage of the ICED hardware/software environment. I also give some tips about nasty situations that may occur in your use of the EDA tools, as well as the precautions/solutions that I have found; I call these "FAPS": Frequently Annoying Problems and their Solutions.

The design steps will only be given in schematic form. For detailed information and tutorials see the documents in the ELE 305 and ELE 405 websites. If there is a discrepancy between this document and information on the latter two courses' web sites, use the information in this document.

1. Introduction
2. EDA Flow - The flow through the EDA (Electronic Design Automation) tools
1. Setup
2. Design Entry - w/ Renoir
3. Logic Macro Generation (optional) - w/ Xilinx Logiblox
4. Behavioral Simulation - w/ QuickHDL
5. Logic Synthesis - w/ Galileo
6. Logic Translation - w/ Xilinx M1
7. Structural Simulation - w/ M1, Galileo and QuickHDL
8. Download Design
3. FAPS: Freqently Annoying Problems and their Solutions - tips, caveats, bugaboos and gotchas

1. Introduction
The overall flow is shown in: ICED EDA Flow. NOTES: Leonardo Spectrum is now used instead of Galileo, and ModelSim is used instead of QuickHDL; their operation is similar.

2. EDA Flow - The flow through the EDA (Electronic Design Automation) tools
We consider the flow using the Mentor Graphics Renoir tool as a starting point. Beginning with Mentor's Design Architect is similar.

Unless mentioned otherwise, all tools are started from the design's home directory, which we'll call: dhdir. Unless leviathan (the department server) is heavily loaded, it is recommended that you run all of the tools from a leviathan shell.

1. Setup.
1. Create an environment variable that will point to your dhdir by:
1. cd'ing to your home directory:    cd ~
2. open your .cshrc file in a text editor:    xemacs .cshrc
3. add the following line to the end of the file (make sure the path for dhdir is fully specified):

    setenv $MY_ICED_HOME dhdir
4. save the file and close the editor
5. to make the change effective immediately, type:    source .chsrc
2. Create dhdir.
3. Create the following four subdirectories in dhdir:
1. dd - design data - holds the Renoir source files
2. hdl - hardware description language - holds the VHDL (or Verilog) files generated by Renoir
3. dp - downstream preparation - holds the compiled HDL files, as well as other intermediate and final output files of EDA tools used later on. This is where the *.bit file winds up that holds the configuration information for the FPGA (hardware).
4. lb - logiblox - holds the output of the Xilinx Logiblox macro generation tool. This is not shown in the figure. Logiblox generates semi-custom building block designs such as adders and registers tailored for our specific Xilinx part.
4. Change directories to dhdir; use something like:   cd dhdir
5. Start up Renoir by typing:    renoir &
6. Create a library and set its subdirectory pointers to the first three subdirectories you just created. Use the environment variable created earlier. For example, the entry for the design data directory should be:

    $MY_ICED_HOME/dd
2. Design Entry. Enter the design in Renoir, and generate and compile the VHDL. Contrary to what is stated elsewhere, do NOT create a port for a global reset. It IS recommended to have a global reset signal, but tie it to '0'. It is only used during simulation.
3. Logic Macro Generation (optional). If you want to use a Logiblox macro, see the ELE 305 Logiblox Tutorial and do the following for each macro:
1. change directories to /lb:    cd lb
2. start the Logiblox generation interface by typing:    lbgui &
3. generate the macro or module; say it's called: mylbmacro
4. in Renoir, which should already be running out of dhdir, create a new VHDL architecture; it MUST have a different name, that is, it should NOT be mylbmacro
5. complete the creation of the Renoir entity and architecture as described in the ELE 305 Logiblox Tutorial
6. assuming you're still in /lb, compile the VHDL behavioral description of the Logiblox macro by typing:

    qvhcom -work ../dp mylbmacro.vhd
7. copy the actual macro design information to the downstream directory by typing:

    cp -p mylbmacro.ngc ../dp
8. The macro can now be used anywhere in any of your Renoir designs. It will also be treated correctly when performing behavioral or structural simulation.
4. Behavioral Simulation. Perform a behavioral simulation to initially verify your design, correcting your design as necessary. This is discussed in the ELE 305 Renoir Tutorial.
5. Logic Synthesis. From dhdir, start the Exemplar (a Mentor Graphics subsidiary) Galileo synthesis tool. This takes the VHDL from Renoir and synthesizes logic targeted for our hardware. Note that Logiblox macros are not affected by Galileo; it will in fact generate a warning message to the effect that it "can't find an entity to bind to" for each macro used.
1. cd to your account home directory and create a directory for your Galileo project files by typing:

        mkdir galileo
2. cd back to dhdir and start Galileo by typing:

        galileo -product leonardo &
3. Using the File pull-down menu, create a new project by saving the old one into a new location via "Save as ..." Put the new project into the ~/galileo subdirectory you just made. (Say "yes" to the "Overwrite?..." question.)
4. Again using the File pull-down menu, set the "Working Directory" to point to: dhdir/dp
5. Using information elsewhere (the Galileo part of the ELE 405 Lab 1), set the other Galileo switches the right way and synthesize your design. MAKE SURE you save your Galileo project frequently to avoid repeating work. Also make sure that in the main Galileo window you set the target (output) design file to be placed in dhdir/dp ; NOTE: by default it DOES NOT DO THIS, it sets it erroneously to dhdir/hdl
6. Logic Translation. Perform the translation from abstract to physical logic with the Xilinx M1 EDA tool.
1. Again from dhdir, start the Xilinx M1 tool by typing:

        dsgnmgr &
2. When asked, enter a unique project subdirectory that M1 will use. It should be something like:

    .../dhdir/xproj_design_the_first
3. Change the settings not given here as described in ELE 405 Lab 1
4. In the simulation settings box, use a unique name for the simulation file prefix; change: time_sim to something unique, like: time_sim_design_the_first
5. In the implementation settings tamplate, check the box to enable generation of simulation data.
6. Run M1 to generate the simulation files:

        time_sim_design_the_first.vhd and time_sim_design_the_first.sdf
and the configuration file:
        design_name.bit
7. The simulation files are used to perform structural simulation, while the configuration file is downloaded to the FPGA to actually realize your design. First, we simulate.
7. Structural Simulation. This is sometimes called "back annotation". The big thing about structural simulation is that it uses the real routing and logic design information to more accurately simulate and verify your design before physical hardware test. Specifically, the *.vhd file generated by M1 contains a structural (low-level) VHDL description of your design, while the *.sdf file, also generated by M1 contains the timing data for the logic elements in the *.vhd file. While it is unnecessary to use Galileo to run the simulation, it is very convenient, and we will do so here.
1. Go back to the main Galileo window. Make sure you are still using the .../dhdir/dp directory as the working directory.
2. On the "Tools" pull-down menu, select "QuickHDL". A new window comes up, the "QuickHDL" window, strangely enough.
3. The QuickHDL window has three major panes. Settings are made in the top two, while runtime messages appear in the bottom one. The left pane is for compilation, while the right one is for starting the QuickHDL simulator.
4. Set the working directories in both panes to: .../dhdir/dp
5. Make sure the 1993 VHDL box is NOT checked on the left pane.
6. Set the compilation pane to use the time_sim_design_the_first.vhd file as its source.
7. Compile that file by selecting: "Compile" from the "Run" pull-down menu. Note that you must re-compile this file whenever M1 is run through its "timing" section.
8. Set the timing information in the right-hand pane to come from the time_sim_design_the_first.sdf file.
9. Start the simulator by selecting: "Simulate" from the "Run" pull-down menu.
10. The same qhsim simulator that you used in the behavioral simulation starts up. Perform the structural simulation in the same manner. You should even be able to use the same command (*.do) files you created for your behavioral simulation, although you may have to change the detailed time settings.
11. Correct your design as necessary and repeat everything until it works.
8. Download Design. You're finally there: download the *.bit file generated by M1 and do the REAL testing! See the ELE 405 S99 Labs 2-4 for more on this process. Use the HP logic analyzer connected to the ICED sys-card to see your design's outputs/inputs from/to the FPGA; documentation on the sys-card is forthcoming.

3. FAPS: Frequently Annoying Problems and their Solutions

1. Symptom: Weird naming problems and complaints from M1.

Problem: Upper vs. lower case names can give the EDA tools fits; this may be exacerbated when operating on Windows platforms.
Solution: ALWAYS use purely lower-case names for EVERYTHING. If you don't, you may be fine, but you're on your own.
2. Symptom: After changing from one (VHDL) architecture to another, the change is not seen in the final output. The new architecture was added to the list of VHDL files in Galileo.

Problem: Galileo probably uses the first architecture it sees in the list for a given entity.
Solution: Remove the old architecture's file name from the VHDL file list in Galileo.
3. Symptom: When compiling VHDL, get error messages something like: "...can't find library ieee of ieee..." even though, of course, the ieee library always exists.

Problem: Somehow the quickhdl.ini settings file gets corrupted. This file is normally created and maintained automatically.
Solution: Delete (rm) the quickhdl.ini file in your dhdir/dp directory, then compile as usual. The quickhdl.ini file will be correctly regenerated.
4. Symptom: Running out of resources on the FPGA; M1 is taking a long time to place-and-route, even though not many CLB's are used.

Problem: You may be using too many tri-state nets. Although the FPGA has many, many tri-state buffers on it, all tri-state buffers driving the same net must be on the same CLB row of the same quadrant. This makes life very difficult for M1.
Solution: Use tri-state nets sparingly. Use multiplexers most of the time, instead.
5. Symptom: When trying to start a structural simulation via Galileo, it complains about an unrecognized "-title" option in the command line it generated automatically (actually, QuickHDL complains).

Problem: Unknown.
Solution: Restart Galileo.
6. Symptom: After editing a net in a Renoir block diagram, error messages appear during VHDL generation/compilation concerning the net.

Problem: Not completely understood. It appears that if part of a net is removed, some of the information about the net that Renoir needs is removed or corrupted. The worst problems occur if the part of the net containing the VHDL type declaration is removed.
Solution: Delete the entire net and rewire it.
7. Symptom: Error messages during Renoir VHDL generation/compilation about entity/architecture/component names.

Problem: This especially occurs when using Logiblox. The architecture instantiating a component MUST have a different name than the component. In fact, the entity, architecture and component must all have different names.
Solution: Rename the entity, architecture and/or component. It may be easiest just to re-create the Logiblox component and its instantiating entity and architecture.
8. Symptom: The output design of M1 is much smaller than expected, and the design does not work at all.

Problem: Some or all of your design has been optimized away, for one or more of at least a couple of reasons:
• The design has no outputs or is missing outputs at the highest VHDL level. This especially happens in intermediate designs. M1 reasons: if there is no output from a circuit, you don't need the circuit.
• The design has a mis-wired reset or clock. If the reset is hardwired asserted, or the clock is hardwired to stay at one logic level, M1 assumes the outputs of the circuit do not change with time and can either be hardwired to 0 or 1, or possibly even removed completely.

Solution: Make sure sufficient outputs appear at the highest level (that corresponds to pins on the FPGA, i.e., real outputs). Make sure the reset is de-asserted, and the clock is not hardwired to 0 or 1.
9. Symptom: After editing part of your Renoir design, VHDL generation/compilation errors occur, or the design functions oddly.

Problem: Parts of the VHDL may be inconsistent with each other, e.g., if an output of one entity has been eliminated but the instantiating VHDL still uses the old version.
Solution: After editing, but before going to Galileo, set the "Generate Always" option for the highest-level VHDL entity in your design, and regenerate and recompile it. This will cause every sub-design to be re-generated and re-compilied automatically, flushing out any inconsistencies in the VHDL. I recommend you do this EVERY time you make a change in Renoir. Our machines are fast enough that this doesn't take much time.
10. Symptom: M1 takes forever to finish, or stops without creating a configuration file (it fails).

Problem: This happens with large designs, or any time an FPGA resource is in short supply. FPGA resources include: CLBs, routing (wiring) channels, flip-flops, tri-state buffers or channels, etc. I've seen it happen even when only 60% of the CLBs are being used. It is particularly likely to happen on your complete processor designs.
Solution: Not too many easy fixes, here.
• Try setting the effort level of the place-and-route algorithm at its maximum point.
• Change the number of passes from "auto" to some large number (100 or 1000), to give M1 every possible chance to complete.
• Set the "map I/O registers into buffers" box in M1.
• Optimize for area in Galileo and M1, although sometime this will backfire, and a more structured layout (corresponding to lower delay) will be routed more easily.
• Redesign parts of your circuit to use less of the resource that is in short supply (look at the reports in M1 to see what is and isn't being used).
11. Symptom: You've downloaded your design to one of the Sun's in Kelley 220, that is, a Sun with an FPGA card on it, and when you start the design up the Sun crashes.

Problem: One or more of the outputs of your design is going to an otherwise-used pin on the FPGA, probably fouling up the Sun's sbus (I/O bus). Specifically, an output is going to a pin that has not been (correctly) specified in the M1 User Constraints File (*.ucf).
Solution: Always use one of the canned *.ucf files and do not renumber the pins. Make sure that all inputs and outputs of your design (ports of the highest-level VHDL entity) are assigned to one of the pins in a canned *.ucf file. The canned *.ucf files may be found in the /ocean/classes/iced/??? directory.
12. Symptom: In the first step of M1, the "Translate" step, one or more sub-designs is "unexpanded".

Problem: M1 cannot find the data for the sub-design. This can occur either because of a missing VHDL file in the input file list in Galileo, or a missing *.ngc data file for a Logiblox component, or a missing slvif3_b.xtf file.
Solution: Add the missing file(s) to the Galileo list. Copy the missing *.ngc files from your .../dhdir/lb directory to your ...dhdir/dp directory. You can do this quickly and mindlessly by typing:
        cd .../dhdir
        cp -p lb/*.ngc dp
NOTE: If you use designs from multiple libraries, make sure that you have copied ALL of the different library's *.ngc files to the .../dhdir/dp directory that holds the data for your CURRENT highest-level VHDL design entity. Copy the slvif3_b.xtf file from the ICED area to your .../dhdir/dp directory.
13. Symptom: When processing a design in Galileo, an error message appears including something like: "-5, feature does not exist".

Problem: This is a licensing issue. Either the Galileo licenses have expired (unlikely), or you neglected to type the "-product leonardo" on the command line when starting Galileo.
Solution: Restart Galileo with the command-line switch present.