*****************************************
******                             ******
******     How to run the scripts  ******
******                             ******
*****************************************

1. Log into any Sweethall Sun machine and issue the command:
  ls -a /usr/class/ee486/WWW/project_scripts

2. copy sourceMe to your fpu directory

3. Copy the whole scr directory which contains all the script files to 
your fpu directory.

4. Make two new directories under your fpu directory. One is called db and 
the other called log

4. Copy .synopsys_dc.setup to your fpu directory (note the `.' at the 
start, this is a hidden file and you need ls -a to see it.) After you do 
that your fpu directory should look like:
      /fpu> ls -a
            ./
            ../
            .synopsys_dc.setup
            db/
            fcmp/
            FPU.pdf
            log/
            README
            README.first
            scr/
            sourceMe
            test_bench/
            test_vectors/
            verilog/

5. Issue the command:  source sourceMe
You will need to do this each time you log in to your account unless you 
put this command in your .cshrc

6. Run Synopsys using either one of these three scripts
      /fpu> dc_shell -f scr/primitives.scr
      /fpu> dc_shell -f scr/simplerun.scr
      /fpu> dc_shell -f scr/run.scr

The first is to synthesis just the primitives file. The simplerun.scr is
for the whole FPU with minimum effort to optimize the mapping in the
synthesis while run.scr does more optimization for the whole FPU and
obviously takes much more time. You really need just to run the first
script for this project. The other two are included to satisfy the
curiosity of some people. :)

Note that if you try to run it on the current primitives.v that you have, 
it will not work and will give you an error because it cannot synthesis 
the division. If you want, you can temporarily eliminate the 
division from primitives.v and primitives.scr by commenting those portions 
out. Then, you can run the script and see its result.

7. Check the report file from the log directory.
   For primitives.scr -> add_sub27_run.rpt, mul_r2_run.rpt, div_r2_run.rpt
   For simplerun.scr -> log/fpu_simple_run.rpt
   For run.scr -> log/fpu_wscr.rpt

It will have at first some details about the area taken by the module and
its different sub-modules. For example, if you try to synthesis the
current adder as it is you will get a total area of 737 units with 311
units taken by an adder and 314 units taken by a subtractor while the
remaining 112 units are taken by multiplexers to choose between the adder
and the subtractor. As you can see this is wasting too much when it comes
to area by implementing two different modules. This is why we told you to
try to do the work yourself. The tools are not smart!

Following the part on the area, the report gives some details on the
inputs and outputs and the assumed wire loads and delays to get them in
and out. In scr/defaults.con we assumed that your inputs are driven by D
Flip-flops and they take 1.2 units of time to be available for you. For
the outputs we assumed that they have a fanout of 4.5. We also assumed
that the clock skew could be up to 0.45 units and that the outputs are
needed at least 1.5 units before the final edge of the clock (as if it is
a setup time for the following latches). You will see all this reported in
the report.

The third part of the report is the timing.  The path delay of all the
outputs is given and it is compared to the required path delay (which is
the assumed clk_period minus the skew of 0.45 and output setup delay of
1.5).  The slack is the difference between the delay of a specific output
and the required path delay. If this slack is positive then the output 
meets the specifications. The worst fifteen critical paths are 
then reported for you and you can see when the signals are rising (r) or 
falling (f) till they reach the output.

Your goal is to get the primitives to work correctly then improve on the 
path delay for your outputs while keeping an eye on the area. As we 
discussed in class, the clock cycle is restricted by the divider but you 
should still optimize your adder and multiplier. You can work with a large 
clock cycle to fit the divider but still optimize the other two blocks and 
making sure that their worst case delay is small (or conversely that 
their slack is large). 

Notes:

To change the clock frequency, edit clk_period from scr/default.con

To reduce the compile time, change the map_effort to low from the script
	compile -map_effort low
This will give you quicker but probably not very good results. The other 
options are medium and high.

To run dc_shell interactively, run dc_shell from the unix prompt. Then, 
type the corresponding commands from the script files.