The first thing to do is to create a working directory. Copy all your VHD files into this directory and type fpga_analyzer to start.

You have to set up the paths etc first so open the setup > defaults menu and fill in the proper information. Here is a copy of ours.

The next thing to do is open up the command window. (setup > command window)

I usually put the Design Analyzer window in the top left-hand corner and the command window smaller below it. Leave the right side of your desktop free for text editors. The command window shows everything that Design Analyzer is doing. This is very useful when you decide to make a script to automate the whole process. To make a script, perform the proper commands using the menus then watch the syntax Design Analyzer uses in the command window. I would recommend executing one command then high-lighting the command with the mouse. Then switch to a text editor window, hopefully you have one open, and press the middle mouse button. This will copy the high-lighted text over. Do this for every command.

Once you have a script, you may run it by setup > execute script. Keep your script in your working directory for easy access. We used fpgatop.script and fpgatop2.script. If you are still green and get a lot of errors, you may want to split your scripts into several smaller scripts and run them one at a time. This way when you get an error you won't have to wait for the whole script to run before you can fix the errors. Our script takes around 20 minutes to run.

If you do not have a script yet, the menu version is given below.

Menu Version

The first thing to do is analyze your VHD files. This can be found in file > analyze.

Analyze your files one at a time starting with the lowest in your hierarchy. We only used two levels of hierarchy for each chip, one top level file (top2.vhd for example) and the rest were on the same level below this one. Be sure to check the box "create new library if it doesn't exist" and choose "WORK" as your library.

Once you have analyzed all the files, without errors or warnings, you can elaborate your design. I would recommend getting rid of all the warnings and errors as soon as possible, even if you are still making significant changes to your VHD files. This will help you to write better code and you are going to have to get rid of them sooner or later. We eliminated all warnings in both the analyze and elaborate steps before we moved on.

Only the top level file has to be elaborated. (file > elaborate) Be sure to check the "re_analyze out-of-date libraries" box. Remember that your files are in your WORK library if you don't see them right away. There is a slight shortcut here. If you change a VHD file, you can go straight to elaborating the top level file and it will re-analyze the new version for you. The catch is that it has to have been analyzed at least once before from the same directory and with the same name.

If you have no errors or warnings at this point and there is more than 6 days left before your presentation, you are kicking some serious butt. Make sure you get rid of all the warnings and errors. A common error is the sensitivity list error. Remember from your VHD files, TUNE : PROCESS(CLOCK,RESET,ENABLE)? Clock, reset and enable are in your sensitivity list. Do not add unnecessary signals to your sensitivity list. I recommend adding the ones you know you need then analyze and elaborate the VHD file by itself. Watch the errors go by in the command window and add the right signals to the sensitivity list. Again use the mouse to copy the signal name from the command window into an editor, with the proper VHD file open, to update the sensitivity list. Then save the file and re-elaborate. Make sure you recheck your simulations because these new signals can create kaos if you wrote bad code (So you thought you were an async god, guess again).

You should also look at the Flip-Flops and Latches your code is creating and make sure they are the right size. We used and variable of the type integer for a counter which had to count from 0-7 (3-bit). While looking through this section we noticed that a Latch with a width of 32 was being created. We were wasting 29 bits which is something like 8 cells (Well 8 4-bit latches anyway).

Well you should now be able to see each VHD file represented as a block in the Design Analyzer window. Double click the blocks to see the schematic representations. Aren't you glad you did not choose to use schematic entry?

You are now ready to create actual physical pads for your inputs and outputs. Select your input pads first. Forget the fact that some may be tri-state, just look at the picture.

Now select attributes > optimization directives > input port. Select the "port is pad" box and press apply then cancel. Do the same for the output ports. You will notice that the tri-state ports open up both the input and output window but remember to look in the command window when executing any commands. See how the same command is issued whether it is an input, output or tri-state? It does not matter which it is, only that it needs a physical representation, a pad.

You are cooking with gas now. The pads you created need locations on the Xilinx chip. Because the Rapid Prototyping Board is already built, you have to pick the proper pins on the Xilinx. For example there are only certain pins connected to SRAM and others which are only connected from FPGA1 to FPGA2. The pin assignments can be found in the RPB User's Manual in Chapter 4. It would be to hard to explain all the details here, but feel free to check out the pin assignments we used in our scripts. (fpgatop.script, fpgatop2.script) Don't forget that all your inputs and outputs must go thru the Xilinx chip. The Xilinx is not on a breadboard and you will not be able to directly access the LEDs or SRAM. You should note that Synopsys is smart enough to detect certain system wide signals, such as a clock and reset, and give them special buffering. This will create an error when you try to xmake your final code. Xmake is used to prepare your code for loading onto the RPB. Use set_pad_type -no_clock clock after you insert the pad to remove the buffer. See our scripts for a better idea.

If this is your first time thru the process, I would recommend not bothering to pick the pin placements. Just leave them blank and see if all the other parts work first. We kept this part as a separate script until we got rid of all the other errors. If you get to many errors at once, you will never be able to fix them all. Divide and conquer.

You are now ready to actually insert the pads. So far you have only selected which pads to insert and where. Select edit > insert pads and just press ok.

After you have inserted the pads you may need to uniquify your design. If you have used two instances of any entity you will need to do this. Select edit > uniquify > hierarchy to do this. Feel free to do it even if you are not sure. It won't wreck anything.

You will now notice that you have separate copies of each of these multiple enities. You are now ready for the the biggest step of your life. You may now compile. Under tools > design optimization you will find the Design Optimizations. Go figure. Select the map design "high" and press ok. Go for coffee. You will need it, it's going to be a long night. If you know for sure that you have a lot of room, set the effort to medium or low. It will compile a lot faster.

I can't believe it compiled on the first try. You rock. Check out all the wicked new blocks you have created. Schematic heaven.

Double click to your hearts desire.

I bet you though you were doing good. You are sadly mistaken. the worst is yet to come. Now you can try mapping the design to the FPGA. Type REPLACE_FPGA in the command window.

This usually takes a lot longer to run than the compiler so go get your lab partner and coffee. He'll need it while he's staying up all night rewriting your buggy code. You are going to have to get rid of all the errors and most of the warnings. These are the warnings we chose to ignore.

Check your report under analysis > report to see how everything mapped out.

The first thing to check is the size of your design. Look at the area and reference sections first. These show the number of cells you have used on you FPGA or more accurately how much hacking and cutting you are going to have to do.

The most important information is the total cell area. Here is a copy of one of our preliminary area.out files. This is before we split the code onto two FPGAs. Looking at the reference section you can see that tuner and processor would be good candidates to move to the second FPGA. We also noticed that something as simple as the noise_gate took a ton of modules so we looked into the code and rewrote a few parts to make it less than 1/4 the size.

If you have everything working up to this point you are pushing your luck. The last thing to do is run a couple of commands I don't understand and save it.

set_attribute top "part" -type string "4010pg191-6"

and

set_attribute find(design,"*") "xnfout_use_blknames" -type boolean FALSE

Type these in the command window.

I suppose you better save your work for posterity. Highlight your top level file and select file > save as. Under file name, type in a name with the extension .sxnf. Change the file format to xnf and check the "Save all Designs in Hierarchy" box and press ok.

You are now ready to xmake your creation. If everything was gong great so far, you in for a rude awakening. If the have been going anything like ours went, go and get some coffee because it will be a long frustrating night.

Disclaimer: We did not get our FPGA's to work so take all our advice with a grain of salt, in your eye (No we're not bitter).