Spelling fixes in documentation (by Larry Doolittle)

docs/format.html

@@ -116,7 +116,7 @@ corner tile (12 16). The entire CRAM of such a device is depicted on the right (
 </p>
 
 <p>
-The checkerboard pattern in the picture visualizes which bits are assoziated
+The checkerboard pattern in the picture visualizes which bits are associated
 with which tile. The height of the configuration block is 16 for all tile
 types, but the width is different for each tile type. IO tiles have
 configurations that are 18 bits wide, LOGIC tiles are 54 bits wide, and
@@ -126,12 +126,12 @@ RAM tiles are 42 bits wide. (Notice the two slightly smaller columns for the RAM
 <p>
 The IO tiles on the top and bottom of the chip use a strange permutation pattern for their bits. It can be seen in the picture that
 their columns are spread out horizontally. What cannot be seen in the picture is the columns also are not in order and the bit
-positions are vertically permutated as well. The <tt>CramIndexConverter</tt> class in <tt>icepack.cc</tt> encapsulates the calculations
+positions are vertically permuted as well. The <tt>CramIndexConverter</tt> class in <tt>icepack.cc</tt> encapsulates the calculations
 that are neccessary to convert between tile-relative bit addresses and CRAM bank-relative bit addresses.
 </p>
 
 <p>
-The black pixels in the image correspond to CRAM bits that are not assoziated with any IO, LOGIC or RAM tile.
+The black pixels in the image correspond to CRAM bits that are not associated with any IO, LOGIC or RAM tile.
 Some of them are unused, others are used by hard IPs or other global resources. The <tt>iceunpack</tt> tool reports
 such bits, when set, with the "<tt>.extra_bit <i>bank x y</i></tt>" statement in the ASCII output format.
 </p>

docs/index.html

@@ -2,7 +2,7 @@
 <h1>Project IceStorm</h1>
 
 <p>
-<b>2015-07-19:</b> Released support for 8k chips. Moved IceStorm sourcecode to GitHub.<br/>
+<b>2015-07-19:</b> Released support for 8k chips. Moved IceStorm source code to GitHub.<br/>
 <b>2015-05-27:</b> We have a working fully Open Source flow with <a href="http://www.clifford.at/yosys/">Yosys</a> and <a href="https://github.com/cseed/arachne-pnr">Arachne-pnr</a>! Video: <a href="http://youtu.be/yUiNlmvVOq8">http://youtu.be/yUiNlmvVOq8</a><br/>
 <b>2015-04-13:</b> Complete rewrite of IceUnpack, added IcePack, some major documentation updates<br/>
 <b>2015-03-22:</b> First public release and short YouTube video demonstrating our work: <a href="http://youtu.be/u1ZHcSNDQMM">http://youtu.be/u1ZHcSNDQMM</a>
@@ -34,7 +34,7 @@ for all kinds of projects.
 <h2>What is the Status of the Project?</h2>
 
 <p>
-We have enough bits mapped that we can create a functional verilog model for almost all 
+We have enough bits mapped that we can create a functional Verilog model for almost all 
 bitstreams generated by Lattice iCEcube2 for the iCE40 HX1K-TQ144 and the iCE40 HX8K-CT256.
 </p>
 
@@ -56,7 +56,7 @@ iceprog rot.bin</pre>
 <h2>Where are the Tools? How to install?</h2>
 
 <p>
-Installing the <a hreaf="https://github.com/cliffordwolf/icestorm">IceStorm Tools</a> (icepack, icebox, iceprog):
+Installing the <a href="https://github.com/cliffordwolf/icestorm">IceStorm Tools</a> (icepack, icebox, iceprog):
 </p>
 
 <pre style="padding-left: 3em">git clone https://github.com/cliffordwolf/icestorm.git icestorm
@@ -97,13 +97,13 @@ that has blocks of <tt>0</tt> and <tt>1</tt> for the config bits for each tile i
 <p>
 A python library and various tools for working with IceBox ASCII files and accessing
 the device database. For example <tt>icebox_vlog.py</tt> converts our ASCII file
-dump of a bitstream into a verilog file that implements an equivalent circuit.
+dump of a bitstream into a Verilog file that implements an equivalent circuit.
 </p>
 
 <h3>IceProg</h3>
 
 <p>
-A small driver programm for the FTDI-based programmer used on the iCEstick and HX8K development boards.
+A small driver program for the FTDI-based programmer used on the iCEstick and HX8K development boards.
 </p>
 
 <h3>ChipDB</h3>
@@ -191,8 +191,8 @@ an example program that does that.
 <p>
 The recommended approach for learning how to use this documentation is to synthesize very simple circuits using
 Lattice iCEcube2, run our toolchain on the resulting bitstream files, and analyze the results using the HTML export of the database
-mentioned above. <tt>icebox_vlog.py</tt> can be used to convert the bitstream to verilog. The output file of
-this tool will also outline the signal paths in comments added to the generated verilog.
+mentioned above. <tt>icebox_vlog.py</tt> can be used to convert the bitstream to Verilog. The output file of
+this tool will also outline the signal paths in comments added to the generated Verilog.
 </p>
 
 <p>

docs/io_tile.html

@@ -39,7 +39,7 @@ of IO cell (1 0).
 
 <p>
 Note that unlike the span-wires connection LOGIC and RAM tiles, the span-wires
-connecting IO tiles to each other are not pairwised crossed out.
+connecting IO tiles to each other are not pairwise crossed out.
 </p>
 
 <h2>IO Blocks</h2>

docs/logic_tile.html

@@ -70,7 +70,7 @@ For example, the wire <tt>sp4_h_r_0</tt> in cell (x, y) has the following names:
 <p><a href="sp4v.svg"><img style="float:right; padding:1em; padding-top:0" height="200" src="sp4v.svg" border="0"></a></p>
 
 <p>
-The image on the right shows the <i>veritical span-4</i> wires of a logic or ram cell (click to enlarge).
+The image on the right shows the <i>vertical span-4</i> wires of a logic or ram cell (click to enlarge).
 </p>
 
 <p>
@@ -82,7 +82,7 @@ to <tt>sp4_v_b_12</tt> to <tt>sp4_v_b_47</tt>.
 
 <p>
 But in addition to that, each cell also has access to <tt>sp4_v_b_0</tt> to <tt>sp4_v_b_47</tt> of its right neighbour.
-This are the wires <tt>sp4_r_v_b_0</tt> to <tt>sp4_r_v_b_47</tt>. So over all a single veritical span-4 wire
+This are the wires <tt>sp4_r_v_b_0</tt> to <tt>sp4_r_v_b_47</tt>. So over all a single vertical span-4 wire
 connects 9 cells. For example, the wire <tt>sp4_v_b_0</tt> in cell (x, y) has the following names:
 </p>
 
@@ -129,7 +129,7 @@ terminate in the cell. Wire names are normalized to <tt>sp12_v_r_2</tt> to <tt>s
 
 <p>
 The <i>local tracks</i> are the gateway to the logic cell inputs. Signals from the span-wires
-and the logic cell ouputs of the eight neighbour cells can be routed to the local tracks and
+and the logic cell outputs of the eight neighbour cells can be routed to the local tracks and
 signals from the local tracks can be routed to the logic cell inputs.
 </p>
 
@@ -223,7 +223,7 @@ Each logic tile has a logic block containing 8 logic cells. Each logic cell cont
 unit and a flip-flop. Clock, clock enable, and set/reset inputs are shared along the 8 logic cells. So is the
 bit that configures positive/negative edge for the flip flops. But the three configuration bits that specify if
 the flip flop should be used, if it is set or reset by the set/reset input, and if the set/reset is synchronous
-or asynchrouns exist for each logic cell individually.
+or asynchronous exist for each logic cell individually.
 </p>
 
 <p>
@@ -240,7 +240,7 @@ The carry unit calculates <tt>lutff_<i>i</i>/cout</tt> = <tt>lutff_<i>i</i>/in_1
 
 <p>
 Part of the functionality described above is documented as part of the routing
-bitstream documentation (see the buffers for <tt>luttff_</tt> inputs). The <tt>NegClk</tt>
+bitstream documentation (see the buffers for <tt>lutff_</tt> inputs). The <tt>NegClk</tt>
 bit switches all 8 FFs in the tile to negative edge mode. The <tt>CarryInSet</tt>
 bit drives the <tt>carry_in_mux</tt> high (it defaults to low when not driven via the buffer from
 <tt>carry_in</tt>).
@@ -248,7 +248,7 @@ bit drives the <tt>carry_in_mux</tt> high (it defaults to low when not driven vi
 
 <p>
 The remaining functions of the logic cell are configured via the <tt>LC_<i>i</i></tt> bits. This
-are 20 bit per logic cell. We have arbitrarily labeld those bits as follows:
+are 20 bit per logic cell. We have arbitrarily labeled those bits as follows:
 </p>
 
 <p align="center">