mirror of https://github.com/KLayout/klayout.git
Updated Deep Verification Base (markdown)
parent
a110290e80
commit
a6f24970c6
|
|
@ -28,7 +28,7 @@ The basic plan is this:
|
|||
|
||||
In contrast to the flat operations provided so far, the new verification base operates in "deep" mode. Hence the name "Deep Verification Base" (DVB).
|
||||
|
||||
# Detailed plan for the hierarchical enhancements of the layout engine
|
||||
# Plan for the hierarchical enhancements of the layout engine
|
||||
|
||||
The layout engine is based on the Region, Edges and EdgePairs classes. Currently those are monolithic structures, but after some refactoring they can be used as providers for the hierarchical algorithms.
|
||||
|
||||
|
|
@ -56,7 +56,7 @@ Deep mode can basically be combined with tiling. In this case, the tiles form hi
|
|||
|
||||
## The hierarchical engine
|
||||
|
||||
The hierarchical engine can be based on a guiding shape/intruder approach.
|
||||
The hierarchical engine can be based on a subject shape/intruder approach.
|
||||
|
||||
Consider a simple boolean operation - for example a NOT operation. In this case there is a subject shape from the first layer and zero or many intruder shapes per subject shape. The intruder shapes come from the second layer. Knowing all intruders for each subject shape allows implementing the NOT operation by simply subtracting the intruders from the subject. This operation is local: only intruders within a limited distance - in this less than zero, i.e. overlapping - will participate and the output of the operation is fully defined from the inputs (subject shape, intruders).
|
||||
|
||||
|
|
@ -83,6 +83,24 @@ A further step involves recombination of the various context-dependent outputs o
|
|||
|
||||
This is a brief description of the idea.
|
||||
|
||||
## Schematic extraction tool
|
||||
|
||||
Having a hierarchical processing engine allows generating hierarchical device recognition markers.
|
||||
|
||||
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
|
||||
|
||||
The result of device recognition is a (per-cell) list of devices with their parameters and port shapes.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue