Boost-Commit :

Date view	Thread view	Subject view	Author view

Subject: [Boost-commit] svn:boost r62130 - in sandbox/gtl/doc: . images
From: lucanus.j.simonson_at_[hidden]
Date: 2010-05-21 19:50:13

Author: ljsimons
Date: 2010-05-21 19:50:12 EDT (Fri, 21 May 2010)
New Revision: 62130
URL: http://svn.boost.org/trac/boost/changeset/62130

Log:
fixes for typos and added image to tutorial and index
Added:
   sandbox/gtl/doc/images/foo.PNG (contents, props changed)
   sandbox/gtl/doc/images/nands.PNG (contents, props changed)
Text files modified:
   sandbox/gtl/doc/gtl_tutorial.htm | 34 ++++++++++++++++++++--------------
   sandbox/gtl/doc/index.htm | 13 +++++++++++--
   2 files changed, 31 insertions(+), 16 deletions(-)

Modified: sandbox/gtl/doc/gtl_tutorial.htm
==============================================================================
--- sandbox/gtl/doc/gtl_tutorial.htm (original)
+++ sandbox/gtl/doc/gtl_tutorial.htm 2010-05-21 19:50:12 EDT (Fri, 21 May 2010)
@@ -42,7 +42,7 @@
Logical Pin: A special net that defines an input or output for the circuit 
Schematic Database: A graph consisting of nets and logical
devices
-Next lets define the sequence of operations performed by our toy
+Next let's define the sequence of operations performed by our toy
layout versus schematic application:
Parse Layout: Stream layout rectangles and polygons into a layout database
and stream layout pins into a connectivity database 
@@ -89,7 +89,7 @@
"on" and can pass current from the voltage source to the output .  The
poly-silicon lines that are not insulated create electrical connections to the
transistor for output signals and source voltage.  The n-type transistor
-differs from the p-type in that its diffusion it n-type material outside of NWELL area.  Current can pass from the output to the ground when the
+differs from the p-type in that its diffusion is n-type material outside of NWELL area.  Current can pass from the output to the ground when the
voltage at the gate of the n-type transistor is at the source voltage level. 
Above the poly-silicon layer is a layer of silicon-oxide insulator with holes
cut out of it that get filled in with metal.  These metal filled holes are
@@ -109,7 +109,7 @@
technology.

<img border="0" src="images/NAND.PNG" width="602" height="387">
-The following is the input layout file for the above NAND gate:
+The following is the input layout file for the above NAND gate layout:
Rectangle 0 60 24 48 NWELL 
Rectangle 3 57 32 43 PDIFF 
Rectangle 3 57 5 16 NDIFF 
@@ -135,11 +135,14 @@
Rectangle 3 57 18 20 METAL1 
Rectangle 3 57 23 25 METAL1 
Pin 29 31 0 2 METAL1 GND 
-Pin 29 31 23 25 METAL1 OUTPUT 
-Pin 29 31 28 30 METAL1 INPUT1 
+Pin 29 31 23 25 METAL1 OUTPUT 
+Pin 29 31 28 30 METAL1 INPUT1 
Pin 29 31 46 48 METAL1 VDD 
Pin 29 31 18 20 METAL1 INPUT2
-The following is the logic schematic net list for a NAND gate:
+
+<img border="0" src="images/nands.PNG" width="421" height="402">
+The following is the logic schematic net list file for the above NAND gate
+schematic:
Pin OUTPUT Pin INPUT1 Pin INPUT2 
Pin VDD Pin GND Device PTRANS VDD INPUT1 OUTPUT Device PTRANS VDD
INPUT2 OUTPUT Device NTRANS GND INPUT1 NET1 Device NTRANS NET1 INPUT2
@@ -156,21 +159,24 @@
on this
<a href="analysis.htm">analysis</a> of Boost.Polygon performance we can expect
this methodology to easily scale up to million gate blocks on standard
-workstations and arbitrarily large designs given sufficient system memory.  Lets start
+workstations and arbitrarily large designs given sufficient system memory. 
+let's start
by implementing some data structures for our application.
struct layout_rectangle { 
  int xl, yl, xh, yh; 
  std::string layer; 
};
Our layout rectangle is nice and minimal, just enough to store its data. 
-It is defined in layout_rectangle.hpp. Next lets implement the layout
+It is defined in layout_rectangle.hpp. Next
+let's implement the layout
pin in a similar way.
struct layout_pin { 
  int xl, yl, xh, yh; 
  std::string layer; 
  std::string net; 
};
-Our layout pin is defined in layout_pin.hpp.  Now lets define a layout database object and populate it from our parsed
+Our layout pin is defined in layout_pin.hpp.  Now
+let's define a layout database object and populate it from our parsed
layout data in in layout_database.hpp.
typedef std::map<std::string,
boost::polygon::polygon_90_set_data<int> > layout_database; 
@@ -210,12 +216,12 @@
Since we are lazy this object does double duty as a pin and both types of
transistor.  A traditional object oriented design might declare a base
class with virtual destructor and derive every device from that.  Since we
-aren't paid by the line of code lets just keep things simple.
+aren't paid by the line of code let's just keep things simple.
struct device { 
  std::string type; 
  std::vector<std::string> terminals; 
};
-Now lets define a schematic database object in
+Now let's define a schematic database object in
<a href="tutorial/schematic_database.hpp">schematic_database.hpp</a> and populate it from our parsed
schematic data.
struct schematic_database{ 
@@ -430,8 +436,8 @@
most complicated part of this simple procedure.  Now that we have our
connectivity database extracted from pins down to transistors we need to extract
our transistors and establish the relationship between transistor terminals and
-nets in our connectivity database.  First lets extract transistors with the
-functions defined in defined in <a href="tutorial/extract_devices.hpp">
+nets in our connectivity database.  First let's extract transistors with
+the functions defined in defined in <a href="tutorial/extract_devices.hpp">
extract_devices.hpp</a>.
typedef boost::polygon::connectivity_extraction_90<int>
connectivity_extraction; 
@@ -649,4 +655,4 @@

</body>

-</html>
+</html>
\ No newline at end of file

Added: sandbox/gtl/doc/images/foo.PNG
==============================================================================
Binary file. No diff available.

Added: sandbox/gtl/doc/images/nands.PNG
==============================================================================
Binary file. No diff available.

Modified: sandbox/gtl/doc/index.htm
==============================================================================
--- sandbox/gtl/doc/index.htm (original)
+++ sandbox/gtl/doc/index.htm 2010-05-21 19:50:12 EDT (Fri, 21 May 2010)
@@ -139,8 +139,10 @@
The end result is accumulated into a list of polygons with a union operation. 
It is considerably more typing to describe this usage of the API than to code
it, and the description is not much clearer than the code itself. 
-Functions are named for what they do, or are overloads of C++ operators that make it
-easy to infer from reading the code what to expect from it.  Operators are
+A picture is worth a thousand words.
+<img border="0" src="images/foo.PNG" width="432" height="371">
+In Boost.Polygon operations such as those shown above are free functions named for what they do, or are overloads of C++ operators that make it
+easy to infer from reading the code what to expect.  Operators are
contained in the namespace boost::polygon::operators
so that they can be used outside the boost::polygon
namespace without bringing in the entire boost::polygon
@@ -182,6 +184,13 @@
Using the n-layer map-overlay algorithm on polygon data</li>
</ul>

+<li>Tutorial:
+<ul>
+ <li>Layout Versus Schematic Learn how to
+ apply Boost.Polygon capabilities to implement a simplified circuit
+ extraction application</li>
+</ul>
+
</ul>

Date view	Thread view	Subject view	Author view

Boost-Commit list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk