update

doc/manual/conversion.tex

@@ -1,15 +1,14 @@
 \section{Introduction\label{conv-intro}}
 
-MyHDL 0.4 provides a path to automatic implementation, by converting
-a subset of MyHDL code into synthesizable Verilog code.
+\myhdl\ 0.4 supports the automatic conversion of a subset of \myhdl\ code
+to synthesizable Verilog code. This feature provides a direct path
+from Python to an FPGA or ASIC implementation.
 
-MyHDL aims to be a complete design language, for high level modeling,
-verification, but also for implementation. However, prior to \myhdl\
-0.4 a \myhdl\ user had to translate synthesizable code manually to
-Verilog or VHDL. Needless to say, this is inconvenient. With \myhdl\
-0.4, this manual step should no longer be necessary.  The automatic
-conversion provides a direct path from Python to an FPGA or ASIC
-implementation.
+\myhdl\ aims to be a complete design language, for tasks such as high
+level modeling and verification, but also for implementation.
+However, prior to 0.4 a user had to translate \myhdl\ code manually to
+Verilog or VHDL. Needless to say, this was inconvenient. With \myhdl\
+0.4, this manual step is no longer necessary.
 
 \section{Solution description\label{conv-solution}}
 
@@ -21,18 +20,14 @@ language, using the function \function{toVerilog} from the \myhdl\
 library. Finally, a third-party \emph{synthesis tool} is used to
 convert the Verilog design into a gate implementation for an ASIC or
 FPGA. There are a number of Verilog synthesis tools available, varying
-in price, capabilities, and target implementation space.
+in price, capabilities, and target implementation technology.
 
 The conversion does not start from source files, but from a design
-that has been "elaborated" by the Python interpreter.  This has
-important advantages. First, there are no restrictions on how to
-describe structure, as all "structural" constructs and parameters are
-processed before the conversion starts. Second, the work of the Python
-interpreter is "reused". The converter uses the Python profiler to
-track the interpreter's operation and to infer the design structure
-and name spaces. It then selectively compiles pieces of source code
-for additional analysis and for conversion. This is done using the
-Python compiler package.
+that has been \emph{elaborated} by the Python interpreter. The
+converter uses the Python profiler to track the interpreter's
+operation and to infer the design structure and name spaces. It then
+selectively compiles pieces of source code for additional analysis and
+for conversion. This is done using the Python compiler package.
 
 \section{Features\label{conv-features}}
 
@@ -62,7 +57,7 @@ an \code{initial} block otherwise.
 The converted Verilog design will be a flat
 "net list of blocks".
 
-\subsection{The Verilog interface is inferred from signal usage\label{conv-features-intf}}
+\subsection{The Verilog module interface is inferred from signal usage\label{conv-features-intf}}
 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 an
@@ -95,7 +90,7 @@ The Verilog converter generates the appropriate code.
 
 \subsection{Introduction\label{conv-subset-intro}}
 
-Unsurprisingly, not all Python code can be converted into Verilog. In
+Unsurprisingly, not all \myhdl\ code can be converted into Verilog. In
 fact, there are very important restrictions.  As the goal of the
 conversion functionality is implementation, this should not be a big
 issue: anyone familiar with synthesis is used to similar restrictions
@@ -109,13 +104,13 @@ industry standards that define the RTL synthesis subset.  However,
 those were not used as a model for the restrictions of the MyHDL
 converter, but as a minimal starting point.  On that basis, whenever
 it was judged easy or useful to support an additional feature, this
-was done. For example, it is actually easier to convert while loops
-than for loops even though they are not RTL-synthesizable.  As another
-example, \keyword{print} is supported because it's so useful for
-debugging, even though it's not synthesizable.  In summary, the
-convertible subset is a superset of the standard RTL synthesis subset,
-and supports synthesis tools with more advanced capabilities, such as
-behavioral synthesis.
+was done. For example, it is actually easier to convert
+\keyword{while} loops than \keyword{for} loops even though they are
+not RTL-synthesizable.  As another example, \keyword{print} is
+supported because it's so useful for debugging, even though it's not
+synthesizable.  In summary, the convertible subset is a superset of
+the standard RTL synthesis subset, and supports synthesis tools with
+more advanced capabilities, such as behavioral synthesis.
 
 Recall that any restrictions only apply to the design post
 elaboration.  In practice, this means that they apply only to the code
@@ -134,9 +129,9 @@ change, or a tuple of such conditions.
 
 The most important restriction regards object types. Verilog is an
 almost typeless language, while Python is strongly (albeit
-dynamically) typed. The converter needs to infer the types of
-variables and map them to Verilog types. Therefore, it does type
-inferencing of object constructors and expressions.
+dynamically) typed. The converter needs to infer the types of names
+used in the code, and map them to Verilog variables. Therefore, it
+does type inferencing of object constructors and expressions.
 
 Only a limited amount of types can be converted.
 Python \class{int} and \class{long} objects are mapped to Verilog