jcarr
/
coriolis
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
coriolis/crlcore/etc/symbolic/cmos/technology.conf

195 lines
7.9 KiB
Plaintext
Raw Normal View History

Add a common/ to share the trunk of symbolic technologies configurations. In CRL Core configuration files, "display.conf", "patterns.conf" and "technology.conf" share most of their code. So that common part is put into "common/" and sourced from the final configuration file. Update the documentation according the the new initialization scheme.
2014-05-21 17:13:17 -05:00
# -*- Mode:Python; explicit-buffer-name: "technology.conf<cmos>" -*-
* All Tools: - A complete sweep of cleanup to suppress allmost all compiler warnings. * ./crlcore: - New: Extented Python support for all objects needed to configure Coriolis. - New: Configuration files and load helpers completly written in Python. An XML emulation mode is still avalaible. - New: UsersGuide, as a replacement for README, written in ReST. - New: Start of Doxygen documentation (mostly for documenting the initialisation objects & methods).
2012-11-16 06:49:47 -06:00
Add a common/ to share the trunk of symbolic technologies configurations. In CRL Core configuration files, "display.conf", "patterns.conf" and "technology.conf" share most of their code. So that common part is put into "common/" and sourced from the final configuration file. Update the documentation according the the new initialization scheme.
2014-05-21 17:13:17 -05:00
import helpers
Reorganisation of technology configuration files. * Change: In CRL Core, in coriolis2/etc the file an directory structure describing the technonolies is modified. Before, one technology was split in two: the symbolic part that may be shared across multiple real technology and the real technology itself. To configure this we needed in ".coriolis2/techno.py" two variables: * symbolicTechnology. * realTechnology. After, we duplicate the symbolic technology in each real ones, so to configure we only have to refer to one technology with the variable: * technology. Pure sympolic technologies are still availables, associated with a dummy real one. We provides: * 180/scn6m_deep_09 for MOSIS 180nm * 45/freepdk_45 for FreePDK 45nm (work in progress). * symbolic/cmos for classical Alliance symbolic. * Change: In CRL Core python/helpers, SymbolicTechnology.py and RealTechnology.py are now grouped under Technology.py.
2017-11-17 04:10:32 -06:00
from Hurricane import DbU
* All Tools: - A complete sweep of cleanup to suppress allmost all compiler warnings. * ./crlcore: - New: Extented Python support for all objects needed to configure Coriolis. - New: Configuration files and load helpers completly written in Python. An XML emulation mode is still avalaible. - New: UsersGuide, as a replacement for README, written in ReST. - New: Start of Doxygen documentation (mostly for documenting the initialisation objects & methods).
2012-11-16 06:49:47 -06:00
Add a common/ to share the trunk of symbolic technologies configurations. In CRL Core configuration files, "display.conf", "patterns.conf" and "technology.conf" share most of their code. So that common part is put into "common/" and sourced from the final configuration file. Update the documentation according the the new initialization scheme.
2014-05-21 17:13:17 -05:00
# The informations here are extracted from the Alliance ".rds" file,
# and must be coherent with it.
* All Tools: - A complete sweep of cleanup to suppress allmost all compiler warnings. * ./crlcore: - New: Extented Python support for all objects needed to configure Coriolis. - New: Configuration files and load helpers completly written in Python. An XML emulation mode is still avalaible. - New: UsersGuide, as a replacement for README, written in ReST. - New: Start of Doxygen documentation (mostly for documenting the initialisation objects & methods).
2012-11-16 06:49:47 -06:00
#
Add a common/ to share the trunk of symbolic technologies configurations. In CRL Core configuration files, "display.conf", "patterns.conf" and "technology.conf" share most of their code. So that common part is put into "common/" and sourced from the final configuration file. Update the documentation according the the new initialization scheme.
2014-05-21 17:13:17 -05:00
# Provides standard settings for:
# - <viewerConfig>
# - <realLayersTable>
Cleaner support for real technologies (Hurricane, CRL Core configuration). * Change: In Hurricane::Technology, in all the layer connexity methods (getLayers(), getMetalAbove(), getCutAbove(), getViaBetween(), ...) the "useWorking" parameter is replaced by a more accurate "useSymbolic". BEHAVIOR CHANGE: formerly, if a symbolic layer was requested, and none was found, NULL was returned. Now, if the symbolic layer is not found, we try to return the associated real one (same layer mask, but not flagged as symbolic, and usually with a lowercase name). All thoses changes have been propagated to Python bindings. * Change: In Hurricane::BasicLayer and derived classes, rename the "isWorking" attribute into "isSymbolic" (to match the technology renaming). * Change: In Hurricane::Cell::flattenNets(), ignore power, ground and blockage nets for the flatten. * Change: In CRL Core, in coriolisInit.py and Technology.py helpers, rename the tables describing the technology as follow: - symbolicLayersTable --> compositeLayersTable - workingLayersTable --> symbolicLayersTable - symbolicRulesTable --> layersExtensionsTable This is to give the table names a more clearer semantic after merging real technologies configurations (testbench AMS c35b4). In particular, we need to define a composite layer for the real VIAs, and not only the symbolic ones. And with correct enclosures expressed in real dimensions (microns).
2017-12-27 06:13:29 -06:00
# - <compositeLayersTable>
Add a common/ to share the trunk of symbolic technologies configurations. In CRL Core configuration files, "display.conf", "patterns.conf" and "technology.conf" share most of their code. So that common part is put into "common/" and sourced from the final configuration file. Update the documentation according the the new initialization scheme.
2014-05-21 17:13:17 -05:00
# - <symbolicLayersTable>
* All Tools: - A complete sweep of cleanup to suppress allmost all compiler warnings. * ./crlcore: - New: Extented Python support for all objects needed to configure Coriolis. - New: Configuration files and load helpers completly written in Python. An XML emulation mode is still avalaible. - New: UsersGuide, as a replacement for README, written in ReST. - New: Start of Doxygen documentation (mostly for documenting the initialisation objects & methods).
2012-11-16 06:49:47 -06:00
Add a common/ to share the trunk of symbolic technologies configurations. In CRL Core configuration files, "display.conf", "patterns.conf" and "technology.conf" share most of their code. So that common part is put into "common/" and sourced from the final configuration file. Update the documentation according the the new initialization scheme.
2014-05-21 17:13:17 -05:00
execfile( helpers.sysConfDir+'/common/technology.conf' )
* All Tools: - A complete sweep of cleanup to suppress allmost all compiler warnings. * ./crlcore: - New: Extented Python support for all objects needed to configure Coriolis. - New: Configuration files and load helpers completly written in Python. An XML emulation mode is still avalaible. - New: UsersGuide, as a replacement for README, written in ReST. - New: Start of Doxygen documentation (mostly for documenting the initialisation objects & methods).
2012-11-16 06:49:47 -06:00
Reorganisation of technology configuration files. * Change: In CRL Core, in coriolis2/etc the file an directory structure describing the technonolies is modified. Before, one technology was split in two: the symbolic part that may be shared across multiple real technology and the real technology itself. To configure this we needed in ".coriolis2/techno.py" two variables: * symbolicTechnology. * realTechnology. After, we duplicate the symbolic technology in each real ones, so to configure we only have to refer to one technology with the variable: * technology. Pure sympolic technologies are still availables, associated with a dummy real one. We provides: * 180/scn6m_deep_09 for MOSIS 180nm * 45/freepdk_45 for FreePDK 45nm (work in progress). * symbolic/cmos for classical Alliance symbolic. * Change: In CRL Core python/helpers, SymbolicTechnology.py and RealTechnology.py are now grouped under Technology.py.
2017-11-17 04:10:32 -06:00
technoConfig = { 'name' : 'hcmos9gp'
, 'gridValue' : 0.005
, 'gridUnit' : DbU.UnitPowerMicro
, 'gridsPerLambda': 24
}
Cleaner support for real technologies (Hurricane, CRL Core configuration). * Change: In Hurricane::Technology, in all the layer connexity methods (getLayers(), getMetalAbove(), getCutAbove(), getViaBetween(), ...) the "useWorking" parameter is replaced by a more accurate "useSymbolic". BEHAVIOR CHANGE: formerly, if a symbolic layer was requested, and none was found, NULL was returned. Now, if the symbolic layer is not found, we try to return the associated real one (same layer mask, but not flagged as symbolic, and usually with a lowercase name). All thoses changes have been propagated to Python bindings. * Change: In Hurricane::BasicLayer and derived classes, rename the "isWorking" attribute into "isSymbolic" (to match the technology renaming). * Change: In Hurricane::Cell::flattenNets(), ignore power, ground and blockage nets for the flatten. * Change: In CRL Core, in coriolisInit.py and Technology.py helpers, rename the tables describing the technology as follow: - symbolicLayersTable --> compositeLayersTable - workingLayersTable --> symbolicLayersTable - symbolicRulesTable --> layersExtensionsTable This is to give the table names a more clearer semantic after merging real technologies configurations (testbench AMS c35b4). In particular, we need to define a composite layer for the real VIAs, and not only the symbolic ones. And with correct enclosures expressed in real dimensions (microns).
2017-12-27 06:13:29 -06:00
# Format of <layersExtensionsTable>:
* All Tools: - A complete sweep of cleanup to suppress allmost all compiler warnings. * ./crlcore: - New: Extented Python support for all objects needed to configure Coriolis. - New: Configuration files and load helpers completly written in Python. An XML emulation mode is still avalaible. - New: UsersGuide, as a replacement for README, written in ReST. - New: Start of Doxygen documentation (mostly for documenting the initialisation objects & methods).
2012-11-16 06:49:47 -06:00
# Each entry is a pair of (string, value).
Cleaner support for real technologies (Hurricane, CRL Core configuration). * Change: In Hurricane::Technology, in all the layer connexity methods (getLayers(), getMetalAbove(), getCutAbove(), getViaBetween(), ...) the "useWorking" parameter is replaced by a more accurate "useSymbolic". BEHAVIOR CHANGE: formerly, if a symbolic layer was requested, and none was found, NULL was returned. Now, if the symbolic layer is not found, we try to return the associated real one (same layer mask, but not flagged as symbolic, and usually with a lowercase name). All thoses changes have been propagated to Python bindings. * Change: In Hurricane::BasicLayer and derived classes, rename the "isWorking" attribute into "isSymbolic" (to match the technology renaming). * Change: In Hurricane::Cell::flattenNets(), ignore power, ground and blockage nets for the flatten. * Change: In CRL Core, in coriolisInit.py and Technology.py helpers, rename the tables describing the technology as follow: - symbolicLayersTable --> compositeLayersTable - workingLayersTable --> symbolicLayersTable - symbolicRulesTable --> layersExtensionsTable This is to give the table names a more clearer semantic after merging real technologies configurations (testbench AMS c35b4). In particular, we need to define a composite layer for the real VIAs, and not only the symbolic ones. And with correct enclosures expressed in real dimensions (microns).
2017-12-27 06:13:29 -06:00
# * string: a synthetic way to designate the real or symbolic layer on
# which it applies, an optional sub layer (BasicLayer) in case
# where there is more than one, and the dimension name.
# * value : the rule (dimension) value. If the main layer is symbolic it
# must be expressed in lambda, if it is for a real layers it
# must be expressed in microns.
layersExtensionsTable = \
* All Tools: - A complete sweep of cleanup to suppress allmost all compiler warnings. * ./crlcore: - New: Extented Python support for all objects needed to configure Coriolis. - New: Configuration files and load helpers completly written in Python. An XML emulation mode is still avalaible. - New: UsersGuide, as a replacement for README, written in ReST. - New: Start of Doxygen documentation (mostly for documenting the initialisation objects & methods).
2012-11-16 06:49:47 -06:00
( ('NWELL.nWell.extention.cap' , 0.0)
, ('PWELL.pWell.extention.cap' , 0.0)
, ('NTIE.minimum.width' , 3.0)
, ('NTIE.nWell.extention.cap' , 1.5)
, ('NTIE.nWell.extention.width' , 0.5)
, ('NTIE.nImplant.extention.cap' , 1.0)
, ('NTIE.nImplant.extention.width' , 0.5)
, ('NTIE.active.extention.cap' , 0.5)
, ('NTIE.active.extention.width' , 0.0)
, ('PTIE.minimum.width' , 3.0)
, ('PTIE.pWell.extention.cap' , 1.5)
, ('PTIE.pWell.extention.width' , 0.5)
, ('PTIE.pImplant.extention.cap' , 1.0)
, ('PTIE.pImplant.extention.width' , 0.5)
, ('PTIE.active.extention.cap' , 0.5)
, ('PTIE.active.extention.width' , 0.0)
, ('NDIF.minimum.width' , 3.0)
, ('NDIF.nImplant.extention.cap' , 1.0)
, ('NDIF.nImplant.extention.width' , 0.5)
, ('NDIF.active.extention.cap' , 0.5)
, ('NDIF.active.extention.width' , 0.0)
, ('PDIF.minimum.width' , 3.0)
, ('PDIF.pImplant.extention.cap' , 1.0)
, ('PDIF.pImplant.extention.width' , 0.5)
, ('PDIF.active.extention.cap' , 0.5)
, ('PDIF.active.extention.width' , 0.0)
, ('GATE.minimum.width' , 1.0)
, ('GATE.poly.extention.cap' , 1.5)
, ('NTRANS.minimum.width' , 1.0)
, ('NTRANS.nImplant.extention.cap' , -1.0)
, ('NTRANS.nImplant.extention.width' , 2.5)
, ('NTRANS.active.extention.cap' , -1.5)
, ('NTRANS.active.extention.width' , 2.0)
, ('PTRANS.minimum.width' , 1.0)
, ('PTRANS.nWell.extention.cap' , -1.0)
, ('PTRANS.nWell.extention.width' , 4.5)
, ('PTRANS.pImplant.extention.cap' , -1.0)
, ('PTRANS.pImplant.extention.width' , 4.0)
, ('PTRANS.active.extention.cap' , -1.5)
, ('PTRANS.active.extention.width' , 3.0)
, ('POLY.minimum.width' , 1.0)
, ('POLY.poly.extention.cap' , 0.5)
Added support for multiple symbolic+real technology in configuration. In CRL Core, the layout of the files under "/coriolis2/etc" changes. Instead of having them directly under "etc", they are now replicated, in subdirectories. Each subdirectory having the name of the associated symbolic or real technology (they are kept separated). We have, for now: * etc/cmos/ : symbolic, the Alliance original one. * etc/vsc200/ : symbolic, for G. Petley vsclib. * etc/hcmos9/ : real, generic fake (130nm). To tell which pair (symbolic,real) technologies must be used we create a *second* (sigh) configuration file "coriolis2_techno.conf", and it's hidden counterpart in the user's account, to set it up. It needs to be separate because it is read as early as possible and select which set of configuration files would be read. Also add support up to METAL8 and POLY2 in CRL core and it's Alliance parser/drivers.
2014-05-21 07:50:22 -05:00
, ('POLY2.minimum.width' , 1.0)
, ('POLY2.poly.extention.cap' , 0.5)
* All Tools: - A complete sweep of cleanup to suppress allmost all compiler warnings. * ./crlcore: - New: Extented Python support for all objects needed to configure Coriolis. - New: Configuration files and load helpers completly written in Python. An XML emulation mode is still avalaible. - New: UsersGuide, as a replacement for README, written in ReST. - New: Start of Doxygen documentation (mostly for documenting the initialisation objects & methods).
2012-11-16 06:49:47 -06:00
# Routing Layers.
, ('METAL1.minimum.width' , 1.0)
, ('METAL1.metal1.extention.cap' , 0.5)
, ('METAL2.minimum.width' , 1.0)
, ('METAL2.metal2.extention.cap' , 1.0)
, ('METAL3.minimum.width' , 1.0)
, ('METAL3.metal3.extention.cap' , 1.0)
, ('METAL4.minimum.width' , 1.0)
, ('METAL4.metal4.extention.cap' , 1.0)
, ('METAL5.minimum.width' , 2.0)
, ('METAL5.metal5.extention.cap' , 1.0)
, ('METAL6.minimum.width' , 2.0)
, ('METAL6.metal6.extention.cap' , 1.0)
Added support for multiple symbolic+real technology in configuration. In CRL Core, the layout of the files under "/coriolis2/etc" changes. Instead of having them directly under "etc", they are now replicated, in subdirectories. Each subdirectory having the name of the associated symbolic or real technology (they are kept separated). We have, for now: * etc/cmos/ : symbolic, the Alliance original one. * etc/vsc200/ : symbolic, for G. Petley vsclib. * etc/hcmos9/ : real, generic fake (130nm). To tell which pair (symbolic,real) technologies must be used we create a *second* (sigh) configuration file "coriolis2_techno.conf", and it's hidden counterpart in the user's account, to set it up. It needs to be separate because it is read as early as possible and select which set of configuration files would be read. Also add support up to METAL8 and POLY2 in CRL core and it's Alliance parser/drivers.
2014-05-21 07:50:22 -05:00
, ('METAL7.minimum.width' , 2.0)
, ('METAL7.metal6.extention.cap' , 1.0)
, ('METAL8.minimum.width' , 2.0)
, ('METAL8.metal6.extention.cap' , 1.0)
* All Tools: - A complete sweep of cleanup to suppress allmost all compiler warnings. * ./crlcore: - New: Extented Python support for all objects needed to configure Coriolis. - New: Configuration files and load helpers completly written in Python. An XML emulation mode is still avalaible. - New: UsersGuide, as a replacement for README, written in ReST. - New: Start of Doxygen documentation (mostly for documenting the initialisation objects & methods).
2012-11-16 06:49:47 -06:00
Cleaner support for real technologies (Hurricane, CRL Core configuration). * Change: In Hurricane::Technology, in all the layer connexity methods (getLayers(), getMetalAbove(), getCutAbove(), getViaBetween(), ...) the "useWorking" parameter is replaced by a more accurate "useSymbolic". BEHAVIOR CHANGE: formerly, if a symbolic layer was requested, and none was found, NULL was returned. Now, if the symbolic layer is not found, we try to return the associated real one (same layer mask, but not flagged as symbolic, and usually with a lowercase name). All thoses changes have been propagated to Python bindings. * Change: In Hurricane::BasicLayer and derived classes, rename the "isWorking" attribute into "isSymbolic" (to match the technology renaming). * Change: In Hurricane::Cell::flattenNets(), ignore power, ground and blockage nets for the flatten. * Change: In CRL Core, in coriolisInit.py and Technology.py helpers, rename the tables describing the technology as follow: - symbolicLayersTable --> compositeLayersTable - workingLayersTable --> symbolicLayersTable - symbolicRulesTable --> layersExtensionsTable This is to give the table names a more clearer semantic after merging real technologies configurations (testbench AMS c35b4). In particular, we need to define a composite layer for the real VIAs, and not only the symbolic ones. And with correct enclosures expressed in real dimensions (microns).
2017-12-27 06:13:29 -06:00
# Contacts (i.e. Active <--> Metal) (symbolic).
* All Tools: - A complete sweep of cleanup to suppress allmost all compiler warnings. * ./crlcore: - New: Extented Python support for all objects needed to configure Coriolis. - New: Configuration files and load helpers completly written in Python. An XML emulation mode is still avalaible. - New: UsersGuide, as a replacement for README, written in ReST. - New: Start of Doxygen documentation (mostly for documenting the initialisation objects & methods).
2012-11-16 06:49:47 -06:00
, ('CONT_BODY_N.minimum.side' , 1.0)
, ('CONT_BODY_N.nWell.enclosure' , 1.5)
, ('CONT_BODY_N.nImplant.enclosure' , 1.5)
, ('CONT_BODY_N.active.enclosure' , 1.0)
, ('CONT_BODY_N.metal1.enclosure' , 0.5)
, ('CONT_BODY_P.minimum.side' , 1.0)
, ('CONT_BODY_P.pWell.enclosure' , 1.5)
, ('CONT_BODY_P.pImplant.enclosure' , 1.5)
, ('CONT_BODY_P.active.enclosure' , 1.0)
, ('CONT_BODY_P.metal1.enclosure' , 0.5)
, ('CONT_DIF_N.minimum.side' , 1.0)
, ('CONT_DIF_N.nImplant.enclosure' , 1.0)
, ('CONT_DIF_N.active.enclosure' , 0.5)
, ('CONT_DIF_N.metal1.enclosure' , 0.5)
, ('CONT_DIF_P.minimum.side' , 1.0)
, ('CONT_DIF_P.pImplant.enclosure' , 1.0)
, ('CONT_DIF_P.active.enclosure' , 0.5)
, ('CONT_DIF_P.metal1.enclosure' , 0.5)
, ('CONT_POLY.minimum.width' , 1.0)
, ('CONT_POLY.poly.enclosure' , 0.5)
, ('CONT_POLY.metal1.enclosure' , 0.5)
Cleaner support for real technologies (Hurricane, CRL Core configuration). * Change: In Hurricane::Technology, in all the layer connexity methods (getLayers(), getMetalAbove(), getCutAbove(), getViaBetween(), ...) the "useWorking" parameter is replaced by a more accurate "useSymbolic". BEHAVIOR CHANGE: formerly, if a symbolic layer was requested, and none was found, NULL was returned. Now, if the symbolic layer is not found, we try to return the associated real one (same layer mask, but not flagged as symbolic, and usually with a lowercase name). All thoses changes have been propagated to Python bindings. * Change: In Hurricane::BasicLayer and derived classes, rename the "isWorking" attribute into "isSymbolic" (to match the technology renaming). * Change: In Hurricane::Cell::flattenNets(), ignore power, ground and blockage nets for the flatten. * Change: In CRL Core, in coriolisInit.py and Technology.py helpers, rename the tables describing the technology as follow: - symbolicLayersTable --> compositeLayersTable - workingLayersTable --> symbolicLayersTable - symbolicRulesTable --> layersExtensionsTable This is to give the table names a more clearer semantic after merging real technologies configurations (testbench AMS c35b4). In particular, we need to define a composite layer for the real VIAs, and not only the symbolic ones. And with correct enclosures expressed in real dimensions (microns).
2017-12-27 06:13:29 -06:00
# VIAs (i.e. Metal <--> Metal) (symbolic).
* All Tools: - A complete sweep of cleanup to suppress allmost all compiler warnings. * ./crlcore: - New: Extented Python support for all objects needed to configure Coriolis. - New: Configuration files and load helpers completly written in Python. An XML emulation mode is still avalaible. - New: UsersGuide, as a replacement for README, written in ReST. - New: Start of Doxygen documentation (mostly for documenting the initialisation objects & methods).
2012-11-16 06:49:47 -06:00
, ('VIA12.minimum.side' , 1.0)
, ('VIA12.metal1.enclosure' , 0.5)
, ('VIA12.metal2.enclosure' , 0.5)
, ('VIA23.minimum.side' , 1.0)
, ('VIA23.metal2.enclosure' , 0.5)
, ('VIA23.metal3.enclosure' , 0.5)
, ('VIA34.minimum.side' , 1.0)
, ('VIA34.metal3.enclosure' , 0.5)
, ('VIA34.metal4.enclosure' , 0.5)
, ('VIA45.minimum.side' , 1.0)
, ('VIA45.metal4.enclosure' , 0.5)
, ('VIA45.metal5.enclosure' , 0.5)
, ('VIA56.minimum.side' , 1.0)
, ('VIA56.metal5.enclosure' , 0.5)
, ('VIA56.metal6.enclosure' , 0.5)
Added support for multiple symbolic+real technology in configuration. In CRL Core, the layout of the files under "/coriolis2/etc" changes. Instead of having them directly under "etc", they are now replicated, in subdirectories. Each subdirectory having the name of the associated symbolic or real technology (they are kept separated). We have, for now: * etc/cmos/ : symbolic, the Alliance original one. * etc/vsc200/ : symbolic, for G. Petley vsclib. * etc/hcmos9/ : real, generic fake (130nm). To tell which pair (symbolic,real) technologies must be used we create a *second* (sigh) configuration file "coriolis2_techno.conf", and it's hidden counterpart in the user's account, to set it up. It needs to be separate because it is read as early as possible and select which set of configuration files would be read. Also add support up to METAL8 and POLY2 in CRL core and it's Alliance parser/drivers.
2014-05-21 07:50:22 -05:00
, ('VIA67.minimum.side' , 1.0)
, ('VIA67.metal6.enclosure' , 0.5)
, ('VIA67.metal7.enclosure' , 0.5)
, ('VIA78.minimum.side' , 1.0)
, ('VIA78.metal7.enclosure' , 0.5)
, ('VIA78.metal8.enclosure' , 0.5)
* All Tools: - A complete sweep of cleanup to suppress allmost all compiler warnings. * ./crlcore: - New: Extented Python support for all objects needed to configure Coriolis. - New: Configuration files and load helpers completly written in Python. An XML emulation mode is still avalaible. - New: UsersGuide, as a replacement for README, written in ReST. - New: Start of Doxygen documentation (mostly for documenting the initialisation objects & methods).
2012-11-16 06:49:47 -06:00
Cleaner support for real technologies (Hurricane, CRL Core configuration). * Change: In Hurricane::Technology, in all the layer connexity methods (getLayers(), getMetalAbove(), getCutAbove(), getViaBetween(), ...) the "useWorking" parameter is replaced by a more accurate "useSymbolic". BEHAVIOR CHANGE: formerly, if a symbolic layer was requested, and none was found, NULL was returned. Now, if the symbolic layer is not found, we try to return the associated real one (same layer mask, but not flagged as symbolic, and usually with a lowercase name). All thoses changes have been propagated to Python bindings. * Change: In Hurricane::BasicLayer and derived classes, rename the "isWorking" attribute into "isSymbolic" (to match the technology renaming). * Change: In Hurricane::Cell::flattenNets(), ignore power, ground and blockage nets for the flatten. * Change: In CRL Core, in coriolisInit.py and Technology.py helpers, rename the tables describing the technology as follow: - symbolicLayersTable --> compositeLayersTable - workingLayersTable --> symbolicLayersTable - symbolicRulesTable --> layersExtensionsTable This is to give the table names a more clearer semantic after merging real technologies configurations (testbench AMS c35b4). In particular, we need to define a composite layer for the real VIAs, and not only the symbolic ones. And with correct enclosures expressed in real dimensions (microns).
2017-12-27 06:13:29 -06:00
# Blockages (symbolic).
* All Tools: - A complete sweep of cleanup to suppress allmost all compiler warnings. * ./crlcore: - New: Extented Python support for all objects needed to configure Coriolis. - New: Configuration files and load helpers completly written in Python. An XML emulation mode is still avalaible. - New: UsersGuide, as a replacement for README, written in ReST. - New: Start of Doxygen documentation (mostly for documenting the initialisation objects & methods).
2012-11-16 06:49:47 -06:00
, ('BLOCKAGE1.minimum.width' , 1.0)
, ('BLOCKAGE1.blockage1.extention.cap' , 0.5)
, ('BLOCKAGE2.minimum.width' , 2.0)
, ('BLOCKAGE2.blockage2.extention.cap' , 0.5)
, ('BLOCKAGE3.minimum.width' , 2.0)
, ('BLOCKAGE3.blockage3.extention.cap' , 0.5)
, ('BLOCKAGE4.minimum.width' , 2.0)
, ('BLOCKAGE4.blockage4.extention.cap' , 0.5)
, ('BLOCKAGE5.minimum.width' , 2.0)
, ('BLOCKAGE5.blockage5.extention.cap' , 1.0)
, ('BLOCKAGE6.minimum.width' , 2.0)
, ('BLOCKAGE6.blockage6.extention.cap' , 1.0)
Added support for multiple symbolic+real technology in configuration. In CRL Core, the layout of the files under "/coriolis2/etc" changes. Instead of having them directly under "etc", they are now replicated, in subdirectories. Each subdirectory having the name of the associated symbolic or real technology (they are kept separated). We have, for now: * etc/cmos/ : symbolic, the Alliance original one. * etc/vsc200/ : symbolic, for G. Petley vsclib. * etc/hcmos9/ : real, generic fake (130nm). To tell which pair (symbolic,real) technologies must be used we create a *second* (sigh) configuration file "coriolis2_techno.conf", and it's hidden counterpart in the user's account, to set it up. It needs to be separate because it is read as early as possible and select which set of configuration files would be read. Also add support up to METAL8 and POLY2 in CRL core and it's Alliance parser/drivers.
2014-05-21 07:50:22 -05:00
, ('BLOCKAGE7.minimum.width' , 2.0)
, ('BLOCKAGE7.blockage6.extention.cap' , 1.0)
, ('BLOCKAGE8.minimum.width' , 2.0)
, ('BLOCKAGE8.blockage6.extention.cap' , 1.0)
* All Tools: - A complete sweep of cleanup to suppress allmost all compiler warnings. * ./crlcore: - New: Extented Python support for all objects needed to configure Coriolis. - New: Configuration files and load helpers completly written in Python. An XML emulation mode is still avalaible. - New: UsersGuide, as a replacement for README, written in ReST. - New: Start of Doxygen documentation (mostly for documenting the initialisation objects & methods).
2012-11-16 06:49:47 -06:00
)
Reorganisation of technology configuration files. * Change: In CRL Core, in coriolis2/etc the file an directory structure describing the technonolies is modified. Before, one technology was split in two: the symbolic part that may be shared across multiple real technology and the real technology itself. To configure this we needed in ".coriolis2/techno.py" two variables: * symbolicTechnology. * realTechnology. After, we duplicate the symbolic technology in each real ones, so to configure we only have to refer to one technology with the variable: * technology. Pure sympolic technologies are still availables, associated with a dummy real one. We provides: * 180/scn6m_deep_09 for MOSIS 180nm * 45/freepdk_45 for FreePDK 45nm (work in progress). * symbolic/cmos for classical Alliance symbolic. * Change: In CRL Core python/helpers, SymbolicTechnology.py and RealTechnology.py are now grouped under Technology.py.
2017-11-17 04:10:32 -06:00
gdsLayersTable = \
( ("nWell" , "NWELL" , 3)
, ("nImplant", "NPLUS" , 26)
, ("pImplant", "PPLUS" , 25)
, ("active" , "ACTIVE" , 6)
, ("poly" , "POLY" , 17)
, ("cut0" , "CONTACT", 30)
, ("metal1" , "METAL1" , 31)
, ("cut1" , "VIA1" , 51)
, ("metal2" , "METAL2" , 32)
, ("cut2" , "VIA2" , 52)
, ("metal3" , "METAL3" , 33)
, ("cut3" , "VIA3" , 53)
, ("metal4" , "METAL4" , 34)
, ("cut4" , "VIA4" , 54)
, ("metal5" , "METAL5" , 35)
, ("cut5" , "VIA5" , 55)
, ("metal6" , "METAL6" , 36)
)