doc: cosmetic changes (thanks sh4rm4 for reporting typos)

README

@@ -1,12 +1,16 @@
 Migen (Milkymist Generator)
   a Python toolbox for building complex digital hardware
 
-Migen aims at automating further the VLSI design process. It provides
-tools to build synchronous designs more productively, integrate
-system-on-chips, design dataflow systems, and more. Migen will become
-the foundation for the next-generation Milkymist SoC.
+Migen aims at automating further the VLSI design process. Migen makes it
+possible to apply modern software concepts such as object-oriented
+programming and metaprogramming to design hardware. This results in more
+elegant and easily maintained designs and reduces the incidence of human
+errors. Built on these principles, it also provides tools to build
+synchronous designs more productively, integrate system-on-chips, design
+dataflow systems, and more. Migen will become the foundation for the
+next-generation Milkymist SoC.
 
-See doc/migen.txt for a more complete description.
+See the doc/ folder for a more complete description.
 
 Code repository:
 https://github.com/milkymist/migen

doc/index.rst

@@ -35,7 +35,7 @@ Even though the Milkymist system-on-chip [mm]_ is technically successful, it suf
 
 #. V*HDL support for composite types is very limited. Signals having a record type in VHDL are unidirectional, which makes them clumsy to use e.g. in bus interfaces. There is no record type support in Verilog, which means that a lot of copy-and-paste has to be done when forwarding grouped signals.
 
-#. V*HDL support for procedurally generated logic is extremely limited. The most advanced forms of procedural generation of synthesizable logic that V*HDL offers are CPP-style directives in Verilog, combinatorial functions, and generate statements. Nothing really fancy, and it shows. To give a few examples:
+#. V*HDL support for procedurally generated logic is extremely limited. The most advanced forms of procedural generation of synthesizable logic that V*HDL offers are CPP-style directives in Verilog, combinatorial functions, and ``generate`` statements. Nothing really fancy, and it shows. To give a few examples:
 
    #. Building highly flexible bus interconnect is not possible. Even arbitrating any given number of bus masters for commonplace protocols such as Wishbone is difficult with the tools that V*HDL puts at our disposal.
    #. Building a memory infrastructure (including bus interconnect, bridges and caches) that can automatically adapt itself at compile-time to any word size of the SDRAM is clumsy and tedious.
@@ -100,7 +100,7 @@ The properties of a signal object are:
 * a boolean "variable". If true, the signal will behave like a VHDL variable, or a Verilog reg that uses blocking assignment. This parameter only has an effect when the signal's value is modified in a synchronous statement.
 * the signal's reset value. It must be an integer, and defaults to 0. When the signal's value is modified with a synchronous statement, the reset value is the initialization value of the associated register. When the signal is assigned to in a conditional combinatorial statement (``If`` or ``Case``), the reset value is the value that the signal has when no condition that causes the signal to be driven is verified. This enforces the absence of latches in designs. If the signal is permanently driven using a combinatorial statement, the reset value has no effect.
   
-The sole purpose of the name property is to make the generated V*HDL code easier to understand and debug. From a purely functional point of view, it is perfectly OK to have several signals with the same name property. The back-end will generate a unique name for each object. If no name property is specified, Migen will analyze the code that created the signal object, and try to extract the variable or member name from there. For example, the following statements will create one or several signal named "bar": ::
+The sole purpose of the name property is to make the generated V*HDL code easier to understand and debug. From a purely functional point of view, it is perfectly OK to have several signals with the same name property. The back-end will generate a unique name for each object. If no name property is specified, Migen will analyze the code that created the signal object, and try to extract the variable or member name from there. For example, the following statements will create one or several signals named "bar": ::
 
   bar = Signal()
   self.bar = Signal()