1. Delays for INOUT ports
as far as timing generics go, the delay for INOUT port to itself 
should be conditonal on the switch of the control signal, which is an 
issue in itself. When we turn to support INOUTS, these delays should
receive proper attention.

2. Only port delays between data ports will be considered. Delays caused
by activity on control ports need special generics and are more complicated.

3. No mechanism to combine information given in different delay formats.
	(Library_element())

4. For re-allocation purposes, both the names and the order of the
data ports of the arithmetic units has been fixed to (in1, in2, out1).
It sould be made more generic by template mapping. (later)

5. // There is a substantial problem with setting the bitwidth of a node.
// The problem is, more precisely, in defining the bitwidth of a component.
// For now, we will go with the old SCALP convention that all data ports
// of a component are of the same width which is considered as the bitwidth.
// I have to eat my own words that I emitted previously to get rid of
// that approach to determining the bitwidth.
// To make it simple and more efficient, we will get the bitwidth
// from the BITWIDTH generic.

6. In overloaded for Dfgedge_value arithmetic operators, there are
potential memory leaks due to the member value of Dfgedge_value.
Value is a pointer to an interer array, and it's not clear whether
that array gets deleted when the temporary object is optimized out by
the compiler.

7. Library_manager can read only *, -,or + in Operations attribute.
  (this is easy to fix)

8. It's not clear whether to create ALL functional_element storage in
Library_manager (presently), or just for the elements present in the package file (on demand, more memory efficient).

9. Retrieval messages of Library_manager that involve lists of operators
were not tested.

10. Library_manager::get_random_library_element implementation is based on
accessing a list by index which is SLOW. Also, only one operator (not a
list) option is supported. It seems to be enough for the present time. 

11. Arithmetic operators for Dfg_value class introduced a problem of a
(potentially) dangling pointer Dfg_value.digits.elements. When local Dfg_Value
is returned by a function, it is presumably deleted, with a copy passed out.
A copy presumably contains an aforementioned pointer to an invalid memory
location. Not confirmed.

12. Type Functinal_library_element::functions could be changed from
  List_ar<Operator> to Array<Boolean> for the sake of efficiency.
  Array implementation is justified since the total number of HDL
  operators is fixed.

13. For class Matrix, it may be convenient to have messages add_row()
    and add_column() (first is more important). These will save some
    time over resize(). Look for code redundancy in Scheduler::create_fsm().

14. We need to come up with a class Table which would essentially have
    an array of columns of different types. All entries within a column
    will be of the same type.

15. Some confusion introduced due to necessity to support port mapping
by order and by name. Muxes need mapping by name only, whereas all the
rest are happy with by-order. We should either de-inherit Mux from
Datapath_element, or provide flexibilty in the nets storage to handle
both types of mapping (array+list, or list only, or what have you).
Resizing the array every time you add a net to it is ... you know.

16. Datapath_element::connect_port (by name). When applied to FSM,
   checks on whether a port with this name has been mapped can get
   very slow as the number of ports grows. A symbol_table solution is
   suggested.

17. Consistency of maintaining port maps should be improved.

18. Automatically add "clk" and "reset" (possibly "vdd" and "vss")
to the list of top entity ports.

19. Library_package::delete* : why one would need these?
Status: FIXED. Delete messages removed.

20. In FRITS, Boolean type was defined to int which eliminates type
checking. Boolean should be defined to built-in bool. In Scheduler::generate_move an Array<Boolean> argument was changed to 
Array<int> due to g++ complaint.

21. Dfg:copy should use copy messages for edges and nodes instead
of copying all fanin/out lists explicitely. Suggestion (PhaseII): go over all
SCALP copy messages and look for such inconsistencies.

22. sequbody.lp In Sequential_body::update_dfg, near 
// undefined => found a loopin. If the same loopin is found twice on the RHS
of different assignments, TWO different edges are created, etc.

23. If an actual loopin is initially defined, it is not created as a loopin.
See DIFFEQ.hdl. Need a solution.

24. Pay attention to messages returning number of various ports of
library_elements and datapath_elements.

25. Remove unnecessary lex/yacc code from _SCALP_ mode.

26. Improve Port_connections so that it's easy to access ports both by name
and order.

27. Module selection does not work properly without module's address being set.
??

28. ANAND 1/25/96. In stand alone mode, Storage_unit and Interconnect_unit
objects are constructed with a NULL passed to their constructor. As a result,
the nets array is NOT allocated. However, for Storage_units, the nets array
needs to be allocated since port mapping is done BY ORDER. I have added a
temporary fix in the constructor Storage_unit(), wrapped with #ifndef _SCALP_,
and #ifdef _OLD_LIBRARY. This problem will automatically be solved when we
move to using the NEW library only, ie, the old scalp library code is
eliminated.

29. ANAND 1/25/96. The code for Library_element class and its sub-classes
depends on some FRITS code (FRITS_object, and Symbol_table classes and
whatever they in turn recursively depend on). In order to completely
eliminate the OLD SCALP library code, it would be necessary to make these
"basic" classes available at Princeton as well, or else to develop a fresh
version of Symbol_table whose source code is mutually available (I actually
believe that this should be no more than a day's work).

30. ANAND 1/25/95. This comment is in continuation of point 5, that talks
about problems with having different botwidths for different ports of a
node. Ultimately it is necessary to handle variable bitwidths. In a program,
variables have associated
types/ranges, from which bitwidths can be inferred. Thus, bitwidth will
be associated ONLY with a Dfgedge, NOT WITH A DFGNODE. If it is allowed
to combine variables of different types/ranges (which is legal in VHDL),
we should also provide for datapath units that have differenct bitwidths
on different ports. The following fundamental principle must be obeyed
during synthesis:

In order to map n operations:
c_1 = a_1 op_1 b_1;
c_2 = a_2 op_2 b_2;
.
.
.
c_n = a_n op_n b_n;

to an instance of a Functional_library_element L that has 2 input
ports of bitwidths bwin_1, bwin_2 and 1 output port of bitwidth bwout,
the following conditions must be satisfied:
	(i) L should be able to perform functions op_1 ... op_n
	(ii) bw_in1 >= MAX( bitwidth(a_1), ..., bitwidth(a_n))
	(iii) bw_in2 >= MAX( bitwidth(b_1), ..., bitwidth(b_n))
	(iv) bw_out >= MAX( bitwidth(c_1), ..., bitwidth(c_n))

Storage units will ALWAYS have the same bitwidth on all input and output
ports. In order to store variables v_1, ..., v_n in a register, its
bitwidth must be >= MAX(bitwidth(v_1), ..., bitwidth(v_n)).

31. ANAND 2/18/96. The absence of input and output operations in a DFG
forces us to make the following assumptions about register sharing:
	(i) A PI/LOOPIN/CONSTANT edge e1 will not share a register
	    with another edge e2 such that e2's lifetime precedes e1.
	    In other words, a PI/CONSTANT/LOOPIN edge is always the
	    FIRST value stored in a register.
	(ii) Similarly, a PO/LOOPOUT edge will be the last value stored in
	     the register that it is mapped to.
