riscv
/
coriolis
mirror of https://gitlab.lip6.fr/vlsi-eda/coriolis.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
coriolis/unittests/python/test_rectilinear.py

169 lines
7.4 KiB
Python
Raw Normal View History

Add vertical rectangles partionning to Rectilinear. * New: Rectilinear::asRectangles(), decompose the Rectilinear into a set of non-overlapping rectangles sliced vertically. This not a mathematical minimum set. But should be speedier. Done using a sweepline processing the vertical edges. Specially suited for use in the extractor which basically manage only rectangles. Simple algorithm described in pp. 9-11 of Extractor notebook. Tests done with unitests/python/test_rectilinear.py, the Rectilinear here should cover all the sweepline cases.
2023-05-03 10:08:57 -05:00
#!/usr/bin/python
import sys
from coriolis.Hurricane import DataBase, Net, \
DbU, Point, Box, Pad, Rectilinear
from coriolis import Cfg
from coriolis.CRL import AllianceFramework, Catalog, Gds
from coriolis.helpers import l, u
from coriolis.helpers.overlay import CfgCache, UpdateSession
def testRectilinear ( editor ):
"""Check Hurricane.Rectilinear class."""
with CfgCache(priority=Cfg.Parameter.Priority.UserFile) as cfg:
cfg.misc.minTraceLevel = 17000
cfg.misc.maxTraceLevel = 18000
with UpdateSession():
cell = AllianceFramework.get().createCell( 'Rectilinear' )
cell.setTerminalNetlist( True )
cell.setAbutmentBox( Box( l(-5.0), l(-5.0), l(400.0), l(200.0) ) )
#cell.setAbutmentBox( Box( l(-5.0), l(-5.0), l(21.0), l(35.0) ) )
if editor:
editor.setCell( cell )
editor.fit()
technology = DataBase.getDB().getTechnology()
metal1 = technology.getLayer( "METAL1" )
metal2 = technology.getLayer( "METAL2" )
metal3 = technology.getLayer( "METAL3" )
metal4 = technology.getLayer( "METAL4" )
poly = technology.getLayer( "POLY" )
ptrans = technology.getLayer( "PTRANS" )
ntrans = technology.getLayer( "NTRANS" )
pdif = technology.getLayer( "PDIF" )
ndif = technology.getLayer( "NDIF" )
contdifn = technology.getLayer( "CONT_DIF_N" )
contdifp = technology.getLayer( "CONT_DIF_P" )
nwell = technology.getLayer( "NWELL" )
contpoly = technology.getLayer( "CONT_POLY" )
ntie = technology.getLayer( "NTIE" )
with UpdateSession():
net = Net.create( cell, 'my_net' )
net.setExternal( True )
points = [ Point( l( 0.0), l( 0.0) )
, Point( l( 0.0), l( 10.0) )
, Point( l( 20.0), l( 30.0) )
, Point( l( 30.0), l( 30.0) )
, Point( l( 30.0), l( 20.0) )
Add Rectilinear & "cut" support to the extractor. Note about the managment of VIA & cuts: Components using a layer which is a ViaLayer, that is one containing more than one BasicLayer, multiple tiles are created in QueryTiles::goCallback(). Components that have a single BasicLayer of "cut" material will also have their multiples tiles created in QueryTiles::goCallback(). Rectilinear components will have their multiples tiles created in Tile::create(). Tile::create() return not all the tiles but the one used as root (for the union find). * New: In SweepLine::_buildCutConnexMap(), when using a "cut" layer in a standalone way, and not as part of a ViaLayer, we do not automatically know to which layer above & below they are connected. We build a table for each cut layer, based on the ViaLayer, to know all tops & belows layers they connect (this is cumulative, in the case of "cut" towards the substrate). Then in Tile::create(), we not only create the tile for the "cut" but also in thoses connected layers (and link them in the union find). * New: In Tile::create(), when we encounter a Rectilinear, break it into rectangles and make as many tiles. All tiles linked to the same root in the union find. * Bug: In Hurricane::Rectilinear, ambiguous specification of the set of points defining the shape. I did suppose that the start and and point where not the same the last edge being between them. But if FlexLib, it uses the GDSII inspired convention where the first and last point must be the same, to indicate a closed contour. This difference was not causing any difference with the drawing, but it was a problem for getAsRectangle(). This was creating a "false" extra vertical edge leading to a bigger rectangle. And this, in turn, was making "false" intersections in the tiling/sweepline of the extractor. Add a more thorough checking of the points vector.
2023-05-05 09:22:51 -05:00
, Point( l( 10.0), l( 0.0) )
, Point( l( 0.0), l( 0.0) ) ]
Add vertical rectangles partionning to Rectilinear. * New: Rectilinear::asRectangles(), decompose the Rectilinear into a set of non-overlapping rectangles sliced vertically. This not a mathematical minimum set. But should be speedier. Done using a sweepline processing the vertical edges. Specially suited for use in the extractor which basically manage only rectangles. Simple algorithm described in pp. 9-11 of Extractor notebook. Tests done with unitests/python/test_rectilinear.py, the Rectilinear here should cover all the sweepline cases.
2023-05-03 10:08:57 -05:00
r = Rectilinear.create( net, metal2, points )
#print( 'Normalized and manhattanized contour:' )
#i = 0
#for point in p.getMContour():
# print( '| %d '%i, point, '[%fum %fum]' % ( u(point.getX()), u(point.getY()) ))
# i += 1
#points = [ Point( l( 0.0), l( 40.0) ) # 0
# , Point( l( 30.0), l( 40.0) ) # 1
# , Point( l( 30.0), l( 60.0) ) # 2
# , Point( l( 50.0), l( 60.0) ) # 3
# , Point( l( 50.0), l( 80.0) ) # 4
# , Point( l( 90.0), l( 80.0) ) # 5
# , Point( l( 90.0), l( 50.0) ) # 6
# , Point( l( 60.0), l( 50.0) ) # 7
# , Point( l( 60.0), l( 30.0) ) # 8
# , Point( l( 70.0), l( 30.0) ) # 9
# , Point( l( 70.0), l( 20.0) ) # 10
# , Point( l( 90.0), l( 20.0) ) # 11
# , Point( l( 90.0), l( 0.0) ) # 12
# , Point( l( 20.0), l( 0.0) ) # 13
# , Point( l( 20.0), l( 20.0) ) # 14
Add Rectilinear & "cut" support to the extractor. Note about the managment of VIA & cuts: Components using a layer which is a ViaLayer, that is one containing more than one BasicLayer, multiple tiles are created in QueryTiles::goCallback(). Components that have a single BasicLayer of "cut" material will also have their multiples tiles created in QueryTiles::goCallback(). Rectilinear components will have their multiples tiles created in Tile::create(). Tile::create() return not all the tiles but the one used as root (for the union find). * New: In SweepLine::_buildCutConnexMap(), when using a "cut" layer in a standalone way, and not as part of a ViaLayer, we do not automatically know to which layer above & below they are connected. We build a table for each cut layer, based on the ViaLayer, to know all tops & belows layers they connect (this is cumulative, in the case of "cut" towards the substrate). Then in Tile::create(), we not only create the tile for the "cut" but also in thoses connected layers (and link them in the union find). * New: In Tile::create(), when we encounter a Rectilinear, break it into rectangles and make as many tiles. All tiles linked to the same root in the union find. * Bug: In Hurricane::Rectilinear, ambiguous specification of the set of points defining the shape. I did suppose that the start and and point where not the same the last edge being between them. But if FlexLib, it uses the GDSII inspired convention where the first and last point must be the same, to indicate a closed contour. This difference was not causing any difference with the drawing, but it was a problem for getAsRectangle(). This was creating a "false" extra vertical edge leading to a bigger rectangle. And this, in turn, was making "false" intersections in the tiling/sweepline of the extractor. Add a more thorough checking of the points vector.
2023-05-05 09:22:51 -05:00
# , Point( l( 0.0), l( 20.0) ) # 15
# , Point( l( 0.0), l( 40.0) ) ] # 16
# Super-test rectilinear.
Add vertical rectangles partionning to Rectilinear. * New: Rectilinear::asRectangles(), decompose the Rectilinear into a set of non-overlapping rectangles sliced vertically. This not a mathematical minimum set. But should be speedier. Done using a sweepline processing the vertical edges. Specially suited for use in the extractor which basically manage only rectangles. Simple algorithm described in pp. 9-11 of Extractor notebook. Tests done with unitests/python/test_rectilinear.py, the Rectilinear here should cover all the sweepline cases.
2023-05-03 10:08:57 -05:00
points = [ Point( l( 0.0), l( 0.0) ) # 0
, Point( l( 0.0), l( 20.0) ) # 1
, Point( l( 10.0), l( 20.0) ) # 2
, Point( l( 10.0), l( 30.0) ) # 3
, Point( l( 20.0), l( 30.0) ) # 4
, Point( l( 20.0), l( 40.0) ) # 5
, Point( l( 40.0), l( 40.0) ) # 6
, Point( l( 40.0), l( 80.0) ) # 7
, Point( l( 20.0), l( 80.0) ) # 8
, Point( l( 20.0), l( 70.0) ) # 9
Add Rectilinear & "cut" support to the extractor. Note about the managment of VIA & cuts: Components using a layer which is a ViaLayer, that is one containing more than one BasicLayer, multiple tiles are created in QueryTiles::goCallback(). Components that have a single BasicLayer of "cut" material will also have their multiples tiles created in QueryTiles::goCallback(). Rectilinear components will have their multiples tiles created in Tile::create(). Tile::create() return not all the tiles but the one used as root (for the union find). * New: In SweepLine::_buildCutConnexMap(), when using a "cut" layer in a standalone way, and not as part of a ViaLayer, we do not automatically know to which layer above & below they are connected. We build a table for each cut layer, based on the ViaLayer, to know all tops & belows layers they connect (this is cumulative, in the case of "cut" towards the substrate). Then in Tile::create(), we not only create the tile for the "cut" but also in thoses connected layers (and link them in the union find). * New: In Tile::create(), when we encounter a Rectilinear, break it into rectangles and make as many tiles. All tiles linked to the same root in the union find. * Bug: In Hurricane::Rectilinear, ambiguous specification of the set of points defining the shape. I did suppose that the start and and point where not the same the last edge being between them. But if FlexLib, it uses the GDSII inspired convention where the first and last point must be the same, to indicate a closed contour. This difference was not causing any difference with the drawing, but it was a problem for getAsRectangle(). This was creating a "false" extra vertical edge leading to a bigger rectangle. And this, in turn, was making "false" intersections in the tiling/sweepline of the extractor. Add a more thorough checking of the points vector.
2023-05-05 09:22:51 -05:00
Add vertical rectangles partionning to Rectilinear. * New: Rectilinear::asRectangles(), decompose the Rectilinear into a set of non-overlapping rectangles sliced vertically. This not a mathematical minimum set. But should be speedier. Done using a sweepline processing the vertical edges. Specially suited for use in the extractor which basically manage only rectangles. Simple algorithm described in pp. 9-11 of Extractor notebook. Tests done with unitests/python/test_rectilinear.py, the Rectilinear here should cover all the sweepline cases.
2023-05-03 10:08:57 -05:00
, Point( l( 10.0), l( 70.0) ) # 10
, Point( l( 10.0), l( 60.0) ) # 11
, Point( l( 0.0), l( 60.0) ) # 12
, Point( l( 0.0), l(120.0) ) # 13
, Point( l( 10.0), l(120.0) ) # 14
, Point( l( 10.0), l(110.0) ) # 15
, Point( l( 20.0), l(110.0) ) # 16
, Point( l( 20.0), l(100.0) ) # 17
, Point( l( 40.0), l(100.0) ) # 18
, Point( l( 40.0), l(140.0) ) # 19
Add Rectilinear & "cut" support to the extractor. Note about the managment of VIA & cuts: Components using a layer which is a ViaLayer, that is one containing more than one BasicLayer, multiple tiles are created in QueryTiles::goCallback(). Components that have a single BasicLayer of "cut" material will also have their multiples tiles created in QueryTiles::goCallback(). Rectilinear components will have their multiples tiles created in Tile::create(). Tile::create() return not all the tiles but the one used as root (for the union find). * New: In SweepLine::_buildCutConnexMap(), when using a "cut" layer in a standalone way, and not as part of a ViaLayer, we do not automatically know to which layer above & below they are connected. We build a table for each cut layer, based on the ViaLayer, to know all tops & belows layers they connect (this is cumulative, in the case of "cut" towards the substrate). Then in Tile::create(), we not only create the tile for the "cut" but also in thoses connected layers (and link them in the union find). * New: In Tile::create(), when we encounter a Rectilinear, break it into rectangles and make as many tiles. All tiles linked to the same root in the union find. * Bug: In Hurricane::Rectilinear, ambiguous specification of the set of points defining the shape. I did suppose that the start and and point where not the same the last edge being between them. But if FlexLib, it uses the GDSII inspired convention where the first and last point must be the same, to indicate a closed contour. This difference was not causing any difference with the drawing, but it was a problem for getAsRectangle(). This was creating a "false" extra vertical edge leading to a bigger rectangle. And this, in turn, was making "false" intersections in the tiling/sweepline of the extractor. Add a more thorough checking of the points vector.
2023-05-05 09:22:51 -05:00
Add vertical rectangles partionning to Rectilinear. * New: Rectilinear::asRectangles(), decompose the Rectilinear into a set of non-overlapping rectangles sliced vertically. This not a mathematical minimum set. But should be speedier. Done using a sweepline processing the vertical edges. Specially suited for use in the extractor which basically manage only rectangles. Simple algorithm described in pp. 9-11 of Extractor notebook. Tests done with unitests/python/test_rectilinear.py, the Rectilinear here should cover all the sweepline cases.
2023-05-03 10:08:57 -05:00
, Point( l( 20.0), l(140.0) ) # 20
, Point( l( 20.0), l(150.0) ) # 21
, Point( l( 10.0), l(150.0) ) # 22
, Point( l( 10.0), l(160.0) ) # 23
, Point( l( 0.0), l(160.0) ) # 24
, Point( l( 0.0), l(180.0) ) # 25
, Point( l( 40.0), l(180.0) ) # 26
, Point( l( 40.0), l(170.0) ) # 27
, Point( l( 50.0), l(170.0) ) # 28
, Point( l( 50.0), l(160.0) ) # 29
Add Rectilinear & "cut" support to the extractor. Note about the managment of VIA & cuts: Components using a layer which is a ViaLayer, that is one containing more than one BasicLayer, multiple tiles are created in QueryTiles::goCallback(). Components that have a single BasicLayer of "cut" material will also have their multiples tiles created in QueryTiles::goCallback(). Rectilinear components will have their multiples tiles created in Tile::create(). Tile::create() return not all the tiles but the one used as root (for the union find). * New: In SweepLine::_buildCutConnexMap(), when using a "cut" layer in a standalone way, and not as part of a ViaLayer, we do not automatically know to which layer above & below they are connected. We build a table for each cut layer, based on the ViaLayer, to know all tops & belows layers they connect (this is cumulative, in the case of "cut" towards the substrate). Then in Tile::create(), we not only create the tile for the "cut" but also in thoses connected layers (and link them in the union find). * New: In Tile::create(), when we encounter a Rectilinear, break it into rectangles and make as many tiles. All tiles linked to the same root in the union find. * Bug: In Hurricane::Rectilinear, ambiguous specification of the set of points defining the shape. I did suppose that the start and and point where not the same the last edge being between them. But if FlexLib, it uses the GDSII inspired convention where the first and last point must be the same, to indicate a closed contour. This difference was not causing any difference with the drawing, but it was a problem for getAsRectangle(). This was creating a "false" extra vertical edge leading to a bigger rectangle. And this, in turn, was making "false" intersections in the tiling/sweepline of the extractor. Add a more thorough checking of the points vector.
2023-05-05 09:22:51 -05:00
Add vertical rectangles partionning to Rectilinear. * New: Rectilinear::asRectangles(), decompose the Rectilinear into a set of non-overlapping rectangles sliced vertically. This not a mathematical minimum set. But should be speedier. Done using a sweepline processing the vertical edges. Specially suited for use in the extractor which basically manage only rectangles. Simple algorithm described in pp. 9-11 of Extractor notebook. Tests done with unitests/python/test_rectilinear.py, the Rectilinear here should cover all the sweepline cases.
2023-05-03 10:08:57 -05:00
, Point( l(150.0), l(160.0) ) # 30
, Point( l(150.0), l(150.0) ) # 31
, Point( l(130.0), l(150.0) ) # 32
, Point( l(130.0), l(140.0) ) # 33
, Point( l(120.0), l(140.0) ) # 34
, Point( l(120.0), l(130.0) ) # 35
, Point( l(110.0), l(130.0) ) # 36
, Point( l(110.0), l(110.0) ) # 37
, Point( l(120.0), l(110.0) ) # 38
, Point( l(120.0), l(100.0) ) # 39
Add Rectilinear & "cut" support to the extractor. Note about the managment of VIA & cuts: Components using a layer which is a ViaLayer, that is one containing more than one BasicLayer, multiple tiles are created in QueryTiles::goCallback(). Components that have a single BasicLayer of "cut" material will also have their multiples tiles created in QueryTiles::goCallback(). Rectilinear components will have their multiples tiles created in Tile::create(). Tile::create() return not all the tiles but the one used as root (for the union find). * New: In SweepLine::_buildCutConnexMap(), when using a "cut" layer in a standalone way, and not as part of a ViaLayer, we do not automatically know to which layer above & below they are connected. We build a table for each cut layer, based on the ViaLayer, to know all tops & belows layers they connect (this is cumulative, in the case of "cut" towards the substrate). Then in Tile::create(), we not only create the tile for the "cut" but also in thoses connected layers (and link them in the union find). * New: In Tile::create(), when we encounter a Rectilinear, break it into rectangles and make as many tiles. All tiles linked to the same root in the union find. * Bug: In Hurricane::Rectilinear, ambiguous specification of the set of points defining the shape. I did suppose that the start and and point where not the same the last edge being between them. But if FlexLib, it uses the GDSII inspired convention where the first and last point must be the same, to indicate a closed contour. This difference was not causing any difference with the drawing, but it was a problem for getAsRectangle(). This was creating a "false" extra vertical edge leading to a bigger rectangle. And this, in turn, was making "false" intersections in the tiling/sweepline of the extractor. Add a more thorough checking of the points vector.
2023-05-05 09:22:51 -05:00
Add vertical rectangles partionning to Rectilinear. * New: Rectilinear::asRectangles(), decompose the Rectilinear into a set of non-overlapping rectangles sliced vertically. This not a mathematical minimum set. But should be speedier. Done using a sweepline processing the vertical edges. Specially suited for use in the extractor which basically manage only rectangles. Simple algorithm described in pp. 9-11 of Extractor notebook. Tests done with unitests/python/test_rectilinear.py, the Rectilinear here should cover all the sweepline cases.
2023-05-03 10:08:57 -05:00
, Point( l(130.0), l(100.0) ) # 40
, Point( l(130.0), l( 90.0) ) # 41
, Point( l(150.0), l( 90.0) ) # 42
, Point( l(150.0), l( 80.0) ) # 43
, Point( l(120.0), l( 80.0) ) # 44
, Point( l(120.0), l( 70.0) ) # 45
, Point( l(110.0), l( 70.0) ) # 46
, Point( l(110.0), l( 50.0) ) # 47
, Point( l(120.0), l( 50.0) ) # 48
, Point( l(120.0), l( 40.0) ) # 49
Add Rectilinear & "cut" support to the extractor. Note about the managment of VIA & cuts: Components using a layer which is a ViaLayer, that is one containing more than one BasicLayer, multiple tiles are created in QueryTiles::goCallback(). Components that have a single BasicLayer of "cut" material will also have their multiples tiles created in QueryTiles::goCallback(). Rectilinear components will have their multiples tiles created in Tile::create(). Tile::create() return not all the tiles but the one used as root (for the union find). * New: In SweepLine::_buildCutConnexMap(), when using a "cut" layer in a standalone way, and not as part of a ViaLayer, we do not automatically know to which layer above & below they are connected. We build a table for each cut layer, based on the ViaLayer, to know all tops & belows layers they connect (this is cumulative, in the case of "cut" towards the substrate). Then in Tile::create(), we not only create the tile for the "cut" but also in thoses connected layers (and link them in the union find). * New: In Tile::create(), when we encounter a Rectilinear, break it into rectangles and make as many tiles. All tiles linked to the same root in the union find. * Bug: In Hurricane::Rectilinear, ambiguous specification of the set of points defining the shape. I did suppose that the start and and point where not the same the last edge being between them. But if FlexLib, it uses the GDSII inspired convention where the first and last point must be the same, to indicate a closed contour. This difference was not causing any difference with the drawing, but it was a problem for getAsRectangle(). This was creating a "false" extra vertical edge leading to a bigger rectangle. And this, in turn, was making "false" intersections in the tiling/sweepline of the extractor. Add a more thorough checking of the points vector.
2023-05-05 09:22:51 -05:00
Add vertical rectangles partionning to Rectilinear. * New: Rectilinear::asRectangles(), decompose the Rectilinear into a set of non-overlapping rectangles sliced vertically. This not a mathematical minimum set. But should be speedier. Done using a sweepline processing the vertical edges. Specially suited for use in the extractor which basically manage only rectangles. Simple algorithm described in pp. 9-11 of Extractor notebook. Tests done with unitests/python/test_rectilinear.py, the Rectilinear here should cover all the sweepline cases.
2023-05-03 10:08:57 -05:00
, Point( l(130.0), l( 40.0) ) # 50
, Point( l(130.0), l( 30.0) ) # 51
, Point( l(150.0), l( 30.0) ) # 52
, Point( l(150.0), l( 20.0) ) # 53
, Point( l( 50.0), l( 20.0) ) # 54
, Point( l( 50.0), l( 10.0) ) # 55
, Point( l( 40.0), l( 10.0) ) # 56
Add Rectilinear & "cut" support to the extractor. Note about the managment of VIA & cuts: Components using a layer which is a ViaLayer, that is one containing more than one BasicLayer, multiple tiles are created in QueryTiles::goCallback(). Components that have a single BasicLayer of "cut" material will also have their multiples tiles created in QueryTiles::goCallback(). Rectilinear components will have their multiples tiles created in Tile::create(). Tile::create() return not all the tiles but the one used as root (for the union find). * New: In SweepLine::_buildCutConnexMap(), when using a "cut" layer in a standalone way, and not as part of a ViaLayer, we do not automatically know to which layer above & below they are connected. We build a table for each cut layer, based on the ViaLayer, to know all tops & belows layers they connect (this is cumulative, in the case of "cut" towards the substrate). Then in Tile::create(), we not only create the tile for the "cut" but also in thoses connected layers (and link them in the union find). * New: In Tile::create(), when we encounter a Rectilinear, break it into rectangles and make as many tiles. All tiles linked to the same root in the union find. * Bug: In Hurricane::Rectilinear, ambiguous specification of the set of points defining the shape. I did suppose that the start and and point where not the same the last edge being between them. But if FlexLib, it uses the GDSII inspired convention where the first and last point must be the same, to indicate a closed contour. This difference was not causing any difference with the drawing, but it was a problem for getAsRectangle(). This was creating a "false" extra vertical edge leading to a bigger rectangle. And this, in turn, was making "false" intersections in the tiling/sweepline of the extractor. Add a more thorough checking of the points vector.
2023-05-05 09:22:51 -05:00
, Point( l( 40.0), l( 0.0) ) # 57
, Point( l( 0.0), l( 0.0) ) ] # 57
#points = [ Point( l( 0.0), l( 0.0) ) # 0
# , Point( l( 0.0), l( 80.0) ) # 1
# , Point( l( 40.0), l( 80.0) ) # 2
# , Point( l( 40.0), l( 60.0) ) # 3
# , Point( l( 20.0), l( 60.0) ) # 4
# , Point( l( 20.0), l( 0.0) ) # 5
# , Point( l( 0.0), l( 0.0) ) ] # 6
Add vertical rectangles partionning to Rectilinear. * New: Rectilinear::asRectangles(), decompose the Rectilinear into a set of non-overlapping rectangles sliced vertically. This not a mathematical minimum set. But should be speedier. Done using a sweepline processing the vertical edges. Specially suited for use in the extractor which basically manage only rectangles. Simple algorithm described in pp. 9-11 of Extractor notebook. Tests done with unitests/python/test_rectilinear.py, the Rectilinear here should cover all the sweepline cases.
2023-05-03 10:08:57 -05:00
r = Rectilinear.create( net, metal2, points )
boxes = []
r.getAsRectangles( boxes )
#print( 'boxes={}'.format( boxes ))
for box in boxes:
box.translate( l(180.0), l(0.0) )
Pad.create( net, metal3, box )
Gds.save( cell )
def scriptMain ( **kw ):
"""The mandatory function to be called by Coriolis CGT/Unicorn."""
editor = None
if 'editor' in kw and kw['editor']:
editor = kw['editor']
testRectilinear( editor )
return True