mirror of https://github.com/KLayout/klayout.git
Updated Deep Verification Base (markdown)
Matthias Köfferlein
parent
487740d170
commit
cf68251966
|
|
@ -89,102 +89,63 @@ Having a hierarchical processing engine allows generating hierarchical device re
|
|||
|
||||
Device recognition consists of:
|
||||
|
||||
* DRC rules that derive markers that identify each type of device
|
||||
* Code to extract device parameters from these markers
|
||||
* DRC rules that derive device ports to which the connectivity extraction can connect to
|
||||
* Boolean operators (maybe others) that derive markers that identify each type of device and which derive the connectivity layers.
|
||||
* Code to extract device parameters from specific layers.
|
||||
* Code to extract nets (connected shapes) in a hierarchical fashion and their terminals
|
||||
|
||||
The result of device recognition is a (per-cell) list of devices with their parameters and port shapes.
|
||||
The first feature is provided by the hierarchical engine mentioned before. The formation of nets and devices requires non-local operations. More specificially "clustering" is required. "Clustering" means that shapes connect to other shapes using connectivity rules. All shapes connected directly or indirectly form clusters. Clusters are meant to be finite - they aggregate to a certain size, but do not cover the whole layout (except in pathological cases).
|
||||
|
||||
Connectivity layers are either taken from their original layers or derived using DRC rules (i.e. boolean operations). Having a hierarchical engine allows maintaining the hierarchy of where possible. The connectivity rules define which of the connectivity layers connect to each other. DRC rules for deriving the layers plus the connectivity rules form a connectivity description similar to the layer stack of the net tracer.
|
||||
For the netlist extraction, hierarchical clustering is required.
|
||||
|
||||
After device recognition, schematic extraction can proceed bottom-up to connect shape by shape and form growing clusters of connected shapes. The incremental nature of the connection extraction forms sub-circuits for each cell. When moving up in the hierarchy, nets from these sub-circuits are connected with nets either from the parent cell or with nets from sibling cells. The result is a hierarchical netlist.
|
||||
## The hierarchical cluster engine
|
||||
|
||||
Here is a rough idea for a schematic extraction script:
|
||||
The implementation of the hierarchical cluster engine consists of a data structure capable of holding local shape clusters and their connections across the hierarchy and the algorithms to derive the latter.
|
||||
|
||||
```ruby
|
||||
# ---------------------------------------------
|
||||
# device definitions
|
||||
The details of the data structure are:
|
||||
* local_cluster objects keep the shapes from one cluster. This is not necessarily a single layer - depending on
|
||||
the connectivity, clusters may consist or more than one layer.
|
||||
* local_clusters objects keep all local clusters for a single cell.
|
||||
* connected_clusters objects keep the local clusters plus connection objects which form the connections
|
||||
to clusters from subcells. A special case is a cluster consisting only of connections: such clusters arise
|
||||
when two cells interact without a shape in the upper hierarchy level on which they interact.
|
||||
* hier_clusters objects keep the entire hierarchy of connected_clusters across all cells.
|
||||
|
||||
# generic MOS device definitions
|
||||
class MOSDevice < DeviceExtractor
|
||||
A useful assertion is that if a cluster of a cell is connected upwards in the hierarchy it is so in all placements. If necessary, dummy clusters are created in the parent cell for the purpose of providing this connection. This assertion greatly simplifies the implementation of the building algorithm because it does not need to look on different hierarchy levels and forking of instantiation paths does not happen.
|
||||
|
||||
def extract(layout, seed, body)
|
||||
The connectivity definition lists the interactions of layers. It consists of pairs of layer IDs which interact. Intra-layer interactions are explicitly included. Without explicit intra-layer connectivity the clustering algorithm reduces to local interactions. This may be useful for preventing huge long range aggregations, for example for treating bulk areas.
|
||||
|
||||
body.size == 1 || raise("MOS device requires exactly one body layer")
|
||||
The algorithm walks the hierarchy bottom-up and performs the following operations:
|
||||
* Collect local shapes into clusters
|
||||
* Look for interactions between local clusters and clusters from child cells. For each such interaction create a connection. If required, place dummy clusters in each parent of a specific cluster (see above).
|
||||
* Look for interactions between child cells and their clusters. On such an interaction, create a dummy cluster in the local cell with two connections to the child cell clusters.
|
||||
|
||||
sd = body[0]
|
||||
sd.size == 2 || raise("Exactly two body shapes (S,D) are required for MOS devices")
|
||||
## Device recognition and extraction
|
||||
|
||||
sides = seed.edges * sd.edges
|
||||
width = sides.length * 0.5 * layout.dbu
|
||||
Device recognition is based on the same cluster scheme, but this time with clusters formed by the device layers. A special connectivity definition connects these layers into clusters. The clusters are presented to the device extraction object. The task of this object is to derive the devices from these clusters. Typically some shapes act as seeds for the device recognitions (i.e. gate shapes for MOSFET devices).
|
||||
|
||||
faces = seed.edges - sd.edges
|
||||
length = faces.length * 0.5 * layout.dbu
|
||||
The device extraction produces the devices with their parameters. In addition, the device terminals are provided which form connection points for the nets. In our implementation, these terminals are new shapes generated by the device extractor. These shapes are produced on standard connectivity layers included in the net extraction. But they are annotated is a special way (through properties), so the net extractor can derive the device connections at the net.
|
||||
|
||||
params = { "W" => width, "L" => length }
|
||||
Device extraction happens for all devices supported in the same way. The effect of the device extraction is a pre-filled netlist with the devices, yet unconnected.
|
||||
|
||||
ports = [
|
||||
Port::new(SEED, "G", seed),
|
||||
Port::new(BODY1, "S", sd[0]),
|
||||
Port::new(BODY1, "D", sd[1])
|
||||
]
|
||||
## Netlist extraction
|
||||
|
||||
return Device::new(self.DEVICE_NAME, params, ports)
|
||||
The netlist extraction step will create the actual nets in the netlist object. It takes a connectivity definition and performs the clustering described above. Each cluster forms a net. Cell instances for subcircuits. Connections between different cells form connections to pins of subcircuits.
|
||||
|
||||
end
|
||||
## The Netlist data structure
|
||||
|
||||
end
|
||||
The netlist data structure consists of these elements:
|
||||
|
||||
# NMOS device definition
|
||||
class NMOSDevice < MOSDevice
|
||||
self.DEVICE_NAME = "NMOS"
|
||||
end
|
||||
* A top-level Netlist object being the container for all objects.
|
||||
|
||||
# PMOS device definition
|
||||
class PMOSDevice < MOSDevice
|
||||
self.DEVICE_NAME = "PMOS"
|
||||
end
|
||||
In Netlist:
|
||||
|
||||
# ---------------------------------------------
|
||||
# extraction script
|
||||
* Circuits corresponding to cells. A Circuit object has a name and a reference to a layout cell (cell_index).
|
||||
* DeviceClass objects inside Netlist representing one kind of device. The main objective of the device class object is to supply the definition of the device terminals.
|
||||
|
||||
deep
|
||||
In Circuits:
|
||||
|
||||
# input layers
|
||||
* Pin objects describing one point each by which a net can connect to a circuit from outside.
|
||||
* Device objects for one device instance each. A device instance has a reference to a DeviceClass object describing the device type.
|
||||
* Subcircuit objects forming Circuit instances. The basic property of the SubCircuit is the reference to the Circuit object that it references.
|
||||
* Net objects. Technically a Net object is a list of Device terminal references and pin references. Pin references are either connections to a subcircuit or outward pin connections.
|
||||
|
||||
nwell = input(1, 0)
|
||||
active = input(2, 0)
|
||||
poly = input(3, 0)
|
||||
contact = input(4, 0)
|
||||
metal1 = input(5, 0)
|
||||
metal1_texts = texts(5, 0)
|
||||
via1 = input(6, 0)
|
||||
metal2 = input(7, 0)
|
||||
metal2_texts = texts(7, 0)
|
||||
|
||||
# generation rules
|
||||
|
||||
sd = active - poly
|
||||
gate = active * poly
|
||||
pmos = gate * nwell
|
||||
nmos = gate - nwell
|
||||
|
||||
# net extraction
|
||||
|
||||
extract_nets do
|
||||
|
||||
connect metal2, via1
|
||||
connect via1, metal1
|
||||
connect metal1, contact
|
||||
connect contact, sd
|
||||
connect contact, poly
|
||||
connect contact, gate
|
||||
|
||||
label metal1, metal1_texts
|
||||
label metal2, metal2_texts
|
||||
|
||||
device NMOSDevice, nmos, sd
|
||||
device PMOSDevice, pmos, sd
|
||||
|
||||
end
|
||||
```
|
||||
Loading…
Reference in New Issue