Merge pull request #3 from cfelton/master

Updated 0.9 documentation.

doc/source/index.rst

@@ -18,6 +18,7 @@ Welcome to the MyHDL documentation
    :maxdepth: 2
 
    manual/index
+   whatsnew/0.9
    whatsnew/0.8
    whatsnew/0.7
    whatsnew/0.6

doc/source/manual/conversion.rst

@@ -72,11 +72,17 @@ Generator are mapped to Verilog or VHDL constructs
   ``always`` blocks, continuous assignments or ``initial`` blocks. For VHDL,
   it will map them to ``process`` statements or concurrent signal assignments.
 
-The module interface is inferred from signal usage
+The module ports are inferred from signal usage
   In MyHDL, the input or output direction of interface signals is not explicitly
   declared. The converter investigates signal usage in the design hierarchy to
   infer whether a signal is used as input, output, or as an internal signal.
 
+Interfaces are expanded
+  MyHDL provides a power mechanism to define complex module interfaces.
+  These interfaces are name extended to individual signals in the target
+  HDL (Verilog and VHDL).  This enables MyHDL to support higher-level 
+  abstractions that are not available in the target HDL.
+
 Function calls are mapped to Verilog or VHDL subprograms
   The converter analyzes function calls and function code. Each function is
   mapped to an appropriate subprogram in the target HDL:  a function or task in  Verilog,
@@ -424,6 +430,21 @@ memory or VHDL array will be declared. The typical example is the
 description of RAM memories.
 
 
+.. _conv-interfaces:
+
+Conversion of Interfaces
+========================
+Interfaces simplify the complicated interconnect between modules.
+In MyHDL the interfaces provide an intuitive approach to group
+logically related ports.  The grouping of ports has many benefits
+such as reducing complexity and increasing modularity.
+
+The converter will name extend the interfaces during conversion,
+in the converted code each attribute will appear as a individual 
+signal.  Because the hierarchy is flattened the name extension 
+may need to include information on the where in the hierarchy
+the interface occurs to prevent name collisions.
+
 .. _conv-meth-assign:
 
 Assignment issues

doc/source/whatsnew/0.9.rst

@@ -63,7 +63,7 @@ The proposed solution is to create unique names for attributes which
 are type :class:`Signal` and used by a `MyHDL generator`_.  The 
 converter will create a unique name by using the name of the parent 
 and the name of the attribute along with the name of the MyHDL module 
-instance (if required for uniqueness).  The convert will essentially 
+instance (if required for uniqueness).  The converter will essentially 
 replace the "." with an "_" for each *interface* element.  
 
 Even though the target HDLs do not support *interfaces*, MyHDL is
@@ -74,18 +74,17 @@ target HDL (Verilog and VHDL).
 Conversion
 ----------
 
-.. add details of the conversion, what policies are used name 
+.. add details of the conversion, what policies are used to name 
 .. extend the Signals.  Any useful information about the approach
 .. or structure in the converter used.
 
 
 Limitations
 -----------
-The current implementation only converts ``Signal`` attributes.  It
-does not convert other attribute types.  One of the main drawbacks
-is if constants are defined in a class.  These constants will not 
-be converted.  Local references need to be made to the constant 
-values.
+The current implementation only converts ``Signal`` attributes and 
+constants (read-only ints).  Other Python structures will not be 
+analyzed (e.g. dict) and attributes used as variables will not be
+converted.