Try to simplify your life :) You do not need to test the whole fpu, you can just test your implementation of the primitives versus what already exists, i.e. provide both with the same random inputs and check that they provide the same output. That would be way faster than asking verilog to also check the rounding and the exception handling parts.

If you still want to check the whole thing for your own interest then each line in the makeall.bat file that starts with rem is supposed to be a remark in Dos or a comment as scripts go. To change it to a comment add a `#' in front of each of those rem lines or delete them completely. The other lines call the program assuming that it is named pg. If you have compiled it to another name then change all those references to call the name you gave it. Depending on your path another Unix program that is also called pg (for page formating) might be called instead of what you want. Either change the path order or just change the references in makeall.bat to be all to a specific name that you choose.

In the README file in the top fpu directory it tells you:
------------------
The testbench is in: test_bench/test_top.v

To simulate the FPU using the included test bench use a comand like:
verilog test_bench/test_top.v \
verilog/fpu.v \
verilog/pre_norm.v \
verilog/primitives.v \
verilog/post_norm.v \
verilog/except.v \
verilog/pre_norm_fmul.v
------------------

I personaly do not recommend that you go through all of this trouble that is not needed for our project. Because all of this is not necessary we actually did not ask for an extra disk quota. It is good for you to read through all the files and to see how the whole FPU might be tested but your job for this project is much smaller than that fortunately :)

> 3- The class.v file has a lot of modules that seem to have the same > functional definitions (ie AN2 and AN2I). I can see in the class.lib > file that there are differences between the gates, but not being a > verilog expert it's difficult for me to determine the significance of > these differences. Could you provide some documentation on what each > module in the library does and what the purpose of the modules with the > same functionality but different names is?

I checked with the TA of ee318 who is generously going to provide us with the script to estimate the speed and area. She too wants your life to be simple. So, she said that all what you need to use are just the logical operations and normal verilog code. She said that you do not need to instantiate the gates. Her word then negates what I told you in class and your life now is simpler. You can just say things like: Z = A & B The script will then look up for the best possible synthesised gate that has the needed driving strength and so on.

My original aim was to force you to think in gates and simple logic blocks instead of writing complicated verilog expressions that would be synthesised into huge blocks. You are still advised to do that. In fact, the adder and multiplier (but not the divider and remainder) as they are written now are synthesisable using synopsis however the result is a big and slow block. If you use what you learned in this class and try to implement things at the logic gate level, you get a much better result.

I hope this helps.