1. Some students asked for the source code of Flowmap because they wanted to 
extend Flowmap to handle the current project. I included flowmap source code
under the directory flowmap. They are source code only. There is a flowmap.doc
file to explain the source code and some basics for the package. To try out
flowmap executable, you can run /u/class/CS258G/proj_2004/rasp/sis (a version
with flowmap built in.) 

2. Is there a function to compute a K-feasible cut?

You can get a K-feasible cut by calling flowmap or by doing cut-enumeration.
The flowmap source code is available. If you plan to do cut-enumeration,
a good idea is that you implement it yourself so you have good control of
the cuts. (Jason lists one paper talking about cut enumeration in the
project handout.)

3. Some people found that they couldn't compile under certain machines such
as hawk. The compiler complained that it couldn't find some standard .h files.
Please use cheetah and try again. It is working fine there. If you still run
into problems, please try to use 'gnumake' instead of 'make'.

4. Is there a function to check tautology of a network?

Yes, please check sis/espresso/irred.c for function tautology.

5. Verify can take a long time to finish.

If the verification takes more than 10 minutes and there is no error
reported then you can assume the two networks are equivalent.

6. You can use a script to run through your benchmarks. The following is
an example:

#!/bin/csh
set CIR_SET = (cirname1 cirname2 cirname3)

set SIS = your_path_to_sis/sis

foreach cir ($CIR_SET)

    echo "$cir ..."
    set File = $cir.blif2
    set sis_args = "read_blif $File; myproj; print_stats; print_level -l"

    time $SIS -x -c "$sis_args"

end

7. The vqm dumper is still under development. We have some questions for 
Altera about the format of the dumper and still waiting for answers. I will
let you know when the dumper is ready.

8. There is cofactor routines available in SIS. Details can be found in
sis-1.3/sis/doc/node.doc. Code example can be found in sis/pld.

To get cofactor based on a single variable, you can use the following 
function:

	lit = node_literal(variable_node, 1);
	f_cof = node_cofactor(f, lit);

9. When checking if two six-input function can be implemented in one ALM
what does it mean by "the combinational function must be the same"?

For example, funtion o1 and o2 are the same in the context of two six-input 
functions into one ALM.

o1 = u v c + !u v d + u !v a + !u !v b
o2 = x y c + !x y d + x !y a + !x !y b

10. To verify that you indeed find the matching, after mapping you can use
a command 'write_eqn design_name.eqn'. In the eqn file, it will list the 
functions of mapped nodes (LUTs) in a format that is easy to understand. 
For details of eqn file, you can type 'help read_eqn' in sis.

11.
> In your FAQ, you said the following o1 and o2 can be implemented as 1 ALM
> o1 = u v c + !u v d + u !v a + !u !v b
> o2 = x y c + !x y d + x !y a + !x !y b
>
> What about the following o1 and o2
> o1 = u v d + !u v c + u !v a + !u !v b
> o2 = x y c + !x y d + x !y a + !x !y b
>
> o1 and o2 still shares 4 input a, b, c, d.
> Now, c and d singals don't go to the same input pins of the combinational 
> logic.  We think this still should be implementable as 1 ALM, but we are 
> not so sure.

NO. it is not working that way anymore.

> Another question is about node_t *mux_control[2].  For two 6-input-LUTs, 
> does it points to the input signals not shared?

For the example, the control signals are u and v for o1, and x and y for o2.

12. Thanks Haru Yamamoto for his following findings:

**************************************
Let's say we have a node X with following function
X   = abc + a'defg

If we let a be the MUX signal,
Xa  = Y = bc
Xa' = Z = defg

Set a as the MUX controller.
Let b be the unique signal to Y.
Let d be the unique signal to Z.
Let c, e, f, and g, be the shared signal between Y and Z,
but e, f, and g are ignored in LUT Y, 
and c is ignored in LUT Z.

Therefore, I thought X should be implementable using 7-input ALM.
**************************************

13. To follow up with question 12 above, after testing in Quartus, the 
following also works.

Xa  = Y = bcd
Xa' = Z = defg

and

Xa  = Y = bcde
Xa' = Z = defg

14. We will use tdf dumper instead of vqm dumper. It will serve the same 
purpose. Details will be given out soon. 

15. I tested the flow using the test benchmarks. I read the writetdf.c and 
found that the dumper didn't consider those fields related to shared inputs.  
So finally quartus didn't combine the 4:1 muxs which can be shared. 
Is there any problem?

Have you checked the floorplan? If not, you can check the floorplan and 
see whether it is packed or not. If packed, those two nodes will be 
together side by side in one ALM (A dash-line square). Move your cursor
to the node, the function of the node will appear in a window. 

16. Also, exactly what output do we need to turn in?

Your exe and mapped tdf in a directory open to access.

print_stats (number of LUTs), level info (mapping depth), Worst case tpd 
and ALM number reported by Quartus. Your tpd and ALM comparison compared 
to Quartus' own mapping results (refer to the Quartus+QUIP tutorial handout).

There are total 25 benchmarks.

17. If you copied the benchmarks to your own directory long time ago, please 
copy these benchmarks to your directory again. TDF dumper will use the 
design name specified in the first line of the benchmarks. For example, 
".model alu4". Before, many benchmarks start with ".model top", which will 
always dump out top.tdf.

Also, some students said that the device we use do not have enough pin 
numbers. If that is the case, you can change your device name to

EP2S15F672C3

If it still does not work, you can ignore that specific benchmark.
 
18. Some students reported that Quartus changed their own mapping 
solution and did some optimization. Currently, we have no method to stop
Quartus from doing that. We are examining why Quartus is doing that. 
Quartus is not supposed to do that because using LCELL means keeping the 
cell intact. Most of the changes are done to the 7-input Cell though. This
means that Quartus may have some special handling designed for 7-input
cell which goes beyond the LCELL constraint. 

19. If your mapped tdf contains signal names with character '-', you can 
do the following: replace all the '-' with '_', then it is going to be fine
with Quartus.

20. Many of the students did packing. Some of them used fancy methods. 
However, Quartus does not support the packing constraints (pairing nodes 
together). Quartus will do its own packing. Therefore, I suggest that the 
students can report their number of ALMs after their packing and the number
of ALMs reported by Quartus. If students' ALM number is better, they should 
get extra credits for that because it means that their packing algorithm 
is better than Quartus'

Now, the numbers that need to be reported are as follows:

1. Your number of ALMs after your mapping and packing. 
2. Your mapping depth (optimal or not)
3. Number of ALMs after you feed your mapped design into Quartus.
4. Worse case tpd of your mapped design after Quartus
5. Number of ALMs and Worse case tpd for Quartus' own mapping using
   the original benchmarks in tdf format.

21. ALM dumper is ready. Details are already sent out through email. I put
an ALMdump.readme in the directory. You can check out the file too. It contains
the same message as in the email.