Design Conversion Tool Sergey Yevstigneev, Boris Ryakhovsky ...

Design Conversion ToolSergey Yevstigneev, Boris Ryakhovsky, Valery LatyshevFreescale Semiconductor Inc.Moscow, RussiaAbstractModern IC design is strongly dependent from technology design kit (TDK)which is a central point of company technologists knowledge. Idealcompatibility between project database and TDK related Cadence library is akey feature of successful tape out. Any TDK update (models, primitives,technology specifics, etc.) could be critical for the project and causes painfuldesign re-use. Comfortable checking and repairing of correspondent Cadencedesign database is a real need for design teams. Usually, specialprocedures/utilities for design migration are built-in TDKs or deliveredseparately. Since design update needs are appeared frequently there areproblems with usage of correspondent migration utilities due to differences inprogram interfaces, initial settings, reports, etc. Moreover, the programdevelopment is complicated anytime by necessarily to create self-consistentprocedures with own GUI, design hierarchy scanning, log information creating,etc.SKILL based migration utility named as “Design Conversion Tool” was createdto support customer needs for automatic design compatibility checking andrepairing with emerged TDK. The tool allows check/convert Cadence designlibraries easier, standard and quicker by separating of technology-independentcore and technology-dependent plug-in set. Tool core presents commoninterface with GUI, plug-in registration and running mechanism, libraryscanning technique, summarizing issues and log data keeping. SKILL basedtechnology-dependent plug-in is supposed to be applied on library, cell view orinstance to determine design issues and fix them. Those plug-ins contain alltechnological specifics of checking/migration procedures. The tool could beused both for user defined checks to achieve own local goals and for commontechnology independent design update procedures like instance CDFcompatibility checking, reference libraries checking, etc. Developed DesignConversion Tool presents unified design update flow. Unexpected and/orundesirable design modification is avoided by requirement to review and signoff discovered issues. Creation of procedures for design checking and repairingis dramatically simplified. The possibility to run multiple plug-inssimultaneously can greatly reduce the processing time of design update.IntroductionTechnology Design Kit is targeted to provide circuit simulation, minimizeamount of hand layout, verify the design and allow layout re-simulation withextracted parasitics. All technologies which are used by Freescale designcommunity are presented by own TDKs with Cadence technology library core.Strong consistency between design database and reference TDK for primitivesand their parameters, layout rules and LVS features is mandatory condition ofproduct quality assurance. However market requirements force to presentcompleted TDK for designers on early stage of technology development. Itresults in frequent TDK updates for models, device structures, design rules, etc.with each new library release. Unfortunately such library update could be

critical for existing projects and design migration will be required to repair itsalignment to modern technology specifics.To decrease appeared impact from updated technology library automatedconversion procedures are developed and delivered for designers. Theseprocedures are intended to resolve local technology dependent inconsistenciesand could not be assembled into common automated tool to cover differentproblems for different technologies. Thus multiple migration utilities withunique interfaces, options and report style are usually delivered separately or aspart of emerged TDK to check and repair the design. Existing diversity betweenpresented utilities requires additional time for designers to understand supportedusage techniques. Designer’s learning should be repeated anytime with newmigration procedure. Quality of created self-consistent migration procedure withown GUI, design hierarchy scanning, log information keeping, etc. is anotherproblem because it should be developed and qualified by designer or externalteam anytime as well. Usually the procedure quality is a compromise withrequired time resources to avoid any impact on the design tape out.Freescale has a centralized library group that develops and maintains near 20technologies actively. To resolve the problem with design alignment to emergedTDK automated Design Conversion Tool (Design Converter) was developed bythis team. The tool was coded by SKILL Cadence language and presents forusers common GUI and issue report form as well as log information conductingwith error handling. Cadence library database passing was also built-in the toolcore. Comfortable database checking and repairing are achieved for designer bymentioned common technology independent features. All technology dependentspecifics are supposed to be done by help of external plug-ins which could beinvolved both from TDK and user side. Development process of suchprocedures could be dramatically simplified because they should contain onlydatabase object processing without redundant cosmetic features like GUI andreport. Quality level of result design migration utility is greatly improved due tocompletely qualified complex technology independent Design Converter coreand simplified technology dependent plug-in set. Developed conversionmethodology demonstrates high reliability on different Freescale technologiesand multiple designs. Defined plug-in registration and executing rules providepossibility to resolve wide variety of design inconsistencies like instance vs.base CDF mismatches, inherited connection issues , layout crash from pcellfootprint changes , etc.Tool methodologyDesign Converter provides an interface to check and, if necessary, convertCadence database objects. Currently supported object types are library, cell, cellview and instance. The structure of the tool is separated on two main parts,technology-independent core and technology-dependent plug-in set. The toolcore is targeted to apply technology dependent plug-ins to the Cadence databaseobjects selected by user. Plug-ins are intended for checking and, if necessary,fixing objects issues.To avoid unexpected design changes Design Conversion tool work process isseparated on two stages. The first is a scanning process (Scan) to find all designproblem issues. At this stage design library is used in read mode to avoid anydatabase changes. The second is a fixing process (Action) to correct all issueswhich were found by scanning procedure and approved by user. Issue approvalprocedure gives user good control for design update. This is a GUI drivenprocess which presents all issues found during Scan stage for review andrequires to sign off what should be fixed at the Action stage.

Single log file is supported by Design Converted across all steps. User is able totrack result status of any step of the process in the log file. There is informationwith errors/warnings summary available at the end of the each stage. The sameinformation is provided by the tool to Cadence log file as well.Technology dependent process is implemented by the plug-ins. Plug-ins operatewith the Cadence database objects only, all design library b rowsing operationsare driven by the tool core. It allows to release plug-ins from additionalprocedures. Since the migration process concerns with big number of open cellviews the tool core has an optimization algorithm which performs all plug-ins onone cell by one pass, in this manner the tool opens destination design cell viewonce per stage.The plug-ins are SKILL bases files which must satisfy to special DesignConversion plug-in registration rules. Design Conversion tool automaticallylooks for the plug-in files in the special locations defined according to tool workmode. There are two work modes of the tool available at this time. The first is ageneric mode, intended to run the tool in the user specific environment with userspecific plug-in set. The location of user plug-ins set could be defined by localSKILL variable. The second is a TDK mode, intended to be used by TDK tomigrate from old to new release. When Design Conversion tool is executed inthis mode it looks for special configuration file which defines the plug-in set forcurrent TDK mode. The file is located in correspondence with the standardFreescale IP directory structure. The file describes plug-in set and plug-inexecution queue to resolve plug-in interference conflicts. TDK could haveseveral configurations to delimit migration procedures to logical groups to helpuser to reduce the number of issues per migration run.User InterfaceTop procedure named “aldDesignConversion” is developed to run the tool,taking as arguments technology library name, plug-in set name, form title nameand log file name. When necessary a corresponding Command InterpreterWindow (CIW) menu item can be made for comfortable tool execution.Procedure execution starts with searching and initializing of plug-ins. Badlydefined or initialized are filtered off and appropriate error messages are printedin CIW. Next the main form of tool is displayed (unless some of initializationprocedures has displayed their own interactive forms to setup themselves).Buttons “Ok”, “Cancel”, “Usage info” and “Load scan data” are available tostart Scan stage, cancel processing, display usage information, load previouslysaved scan data accordingly. To select objects for processing, library cyclicfield, cells and views listboxes are present. Only single design library can beselected. Multiple cells and views are allowed. The following auxiliary buttonsare present for handy selection: “All”, “Pattern”, “None”, “Select CurrentCellview”. Together with a log file name field the described controls areminimal main form content. Second part is info about plug-ins, displayed bylines, including: plug-in prompt; options, description, on/off buttons.After database objects for processing are selected, required set of plug-ins ischosen and options are set - Scan stage can be run by “Ok” button. Errorsoccurred inside of plug-ins are intercepted by the tool and are printed to log fileand CIW with explanation data. Several error message severities exist:“warning” for signaling about problems, which could influence reportinterpretation by user, e.g. when an old version of a required tool was foundinstead of supported; “error” for signaling about not fatal errors, which influencereport interpretation by user. e.g. when flatten of desired instance failed; “fatal”

used when further execution of the tool is useless, e.g. when no space on disk isleft for required intermediate files creation.Information about objects currently processed and number of issues found islogged to the log file and CIW.After Scan stage completes, the form with gathered data (Scan Data form)appears. Unless any data found – a message about it appears and tool finisheswork. The Scan Data form contains two listboxes, "Available data:" - with founddata and "Chosen data:" - with data (issues) which you chose to be fixed. Eachline in listbox represents one issue, found while scanning. It contains instancemaster, name, address (library, cell, view), id of issue, issue description.Auxiliary buttons “All”, “None”, “Choose”/”Unchoose”, “Chooseall”/”Unchoose all” allow handy selection of the issues. “Information” buttondisplays expanded generated by plug-in information about each issue cause.Cyclic field “Sort by” allow to sort issues by any field. "Check schematics"button allows to use standard Cadence “Check&Save” functionality before eachschematic view closing with printing results to log and CIW.Unless Action stage desired, the original list of found issues can be saved bypressing "Save scan data" button for future use. File name is set by file managerdialog. To avoid repeated database scanning for someone reason, e.g. whenaction stage failed due to write-protected database, previously saved data can beloaded in main form by “Load scan data” button, thus replacing Scan stage.After pressing “OK” button fixing of all chosen issues begins. Process isreported to CIW and log file. Issues which require no action are skipped.Disregarding absence of any stage, at the end of work the tool performs deinitializationof plug-ins to clean up environment.Plug-insActual design database problem resolving is provided by specially preparedSKILL utility or utilities set. They could be involved in the database conversionprocess if several pre-defined rules are supported. The utilities could bereasonably named as plug-ins for Design Conversion tool. The followingconditions should be satisfied to successfully register and execute a plug-in byDesign Converter:plug-in configuration file should be named with “.il” extension and locatedaccording to known TDK sub-directory or DESIGNCONVERSION_PATHSKILL variable in case of generic mode;all SKILL procedures which are used by plug-in should be defined before theplug-in registration.correct set of keywords and their values should be available in the plug-inconfiguration, this information should be followed by the next template:; $keyword: value $Plug-in configuration could be done either as separate file or usually could bemerged with correspondent SKILL procedures. Below is a list of valid plug-inattributes which allows migration procedure registering and defines how itshould be executed. Each keyword should be selected in the configuration, nonesymbol should be done for optional fields at least.ToolName: plug-in symbolic name. It is identification name which is used byDesign Converter for processing and log information keeping.Prompt: user friendly plug-in name. It’s used in Design Converter GUI andcould be referenced in related documentation.

Configures: external plug-in symbolic name or none symbol. The reason of thisfield is to maintain simplified setting plug-ins which are targeted to tunesomeone standard external main plug-in for local needs, e.g. for currenttechnology. Design Converter will ignore registration of setting plug-in, but itsinitialization procedure (see PreProc below) will be executed only. none valuemeans that this is a regular self-consistent plug-in.Level: valid choices: library, cell, cellview or instance. Defines object type toapply scanning and converting plug-in procedures. dd_object, dd_object,db_object or db_object are supported respectively. Thus, plug-in could be doneto process one of mentioned database objects.CellViewTypes: valid choices: schematicSymbol, schematic, maskLayout, or anycombination of these symbols separated by space. Defines what Cadence cellview type should be processed by the plug-in. For example, schematic valuemeans that schematic views will be processed only.PreProc: symbolic name of SKILL procedure. It is executed by DesignConverter immediately after the plug-in registration. No any argument should besupported. This field is optional and usually it’s used to create and fill plug-inlocal option form. However any other initialization features could be als osupported. Convention for procedure returned value is : nil means that plug-inregistration failed and this migration utility will be skipped by DesignConverter, other value – plug-in registration completed successfully and thecorrespondent record will be appeared in the Design Converter start form.ScanProc: symbolic name of SKILL procedure. It is applied by DesignConverter to specified in the Level field object during database scanning. Singleargument – database object ID – should be supported. Of course ScanProcprocedure should be compatible with object selected in Level field. Conventionfor procedure returned value is: nil - if no issue found, lis t of SKILL structureswith ”id”, “message” and “information” fields for each in case of discoveredissue, where id –string with flag number to display in Design Converted ScanData form, e.g. “PcellError.1”; message – string with short flag description toexplain it in Design Converted Scan Data form as well, e.g. “Repair layout byold pcell?”, information – detailed issue description to display this one in DesignConverted Information form, e.g. “New pcell affects on existing layout:source/drain via array extended. To protect the design layout instance flatteningis recommended before new technology libra ry setup”. Thus, mentioned SKILLstructure defines discovered issue and should be named as aldDCscanData.ActionProc: symbolic name of SKILL procedure. It is applied by DesignConverter to specified in the Level field object during database correction.Flagged database object is supported as first argument and aldDCscanData assecond. Issue definition is necessary to understand what problem has beenappeared for entered database object. Output value will be processed by DesignConverter as following: t or nil will be understood as successful or failed resultrespectively. Correspondent notification will be returned in the log file anyway.If ActionProc isn’t defined, i.e. it’s marked by none, then no database correctionwill be done for discovered issue. It means that the plug-in is a design librarychecker only and not intended for automatic database correction. For example,such information plug-in could be prepared to check alternative devices in thedesign, but the responsibility to clean-up the project will be assigned to designer.PostProc: symbolic name of SKILL procedure. It is applied by DesignConverter during tool exit. This de-initialization procedure is supposed to bedone without any argument. The field is optional and usually it’s used to cleanup memory after plug-in work. For example, PostProc procedure can deleteplug-in option form, temporal files, etc. Convention for procedure returned

value is : nil means that plug-in de-installation failed; other value – plug-inuninstalled successfully. Design Converter will notify about the status ofoperation.OptionsForm: symbolic name of local plug-in graphic form. Field value issupposed as argument of hiDisplayForm function; none could be specified if noany option form available. This form will be called by Design Converted for “o”plug-in related button on the tool main form. User can set plug-in options ifnecessary or simply understand what database features are supposed to convert.InfoFile: path to documentation file. The path could be relative from plug-inlocation. Design Converter will open the file (“i” button on the plug-in line inmain form) by the correspondent application. Text, PDF, PostScript, HTML filetypes are supported for this mandatory field.Available registration and executing plug-in rules and plug-in keyword set allowto dramatically simplify efforts for migration procedure development. Below isplug-in example which repairs existing layouts from pcell footprint changesappeared in new TDK.; Plug-in configuration:; $ToolName: FlattenPcellInst $; $Prompt: “Flatten obsolete pcells” $; $Configures: none $; $Level: instance $; $CellViewTypes: maskLayout $; $PreProc: none $; $ScanProc: fslDCfindObsoletePcell $; $ActionProc: fslDCflattenPcell $; $PostProc: none $; $OptionsForm: none $; $InfoFile: ./doc/FlattenPcellInst.pdf $; Scan procedure to check that the instance is valid for flattening; actually theinstance is (my_tdk nmos layout)procedure( fslDCfindObsoletePcell(inst “d”)let(()if( (inst~>master~>libName== “my_tdk”) &&(inst~>master~>cellName==”nmos”) &&(inst~>master~>viewName == "layout") thenlist(make_aldDCscanData(?id “PcellError.1”?message ”Repair layout by old pcell?”))elsenil))) ; end of fslDCfindObsoletePcell; Action procedure to flatten selected pcell

procedure( fslDCflattenPcell(inst scanData “dg”)let((); Open obsolete pcell cellView. Note: “oldPcellLib” should exist.inst~>master = dbOpenCellViewByType(ddGetObj(“oldPcellLib”)“nmos” “layout" “maskLayout” "r")dbFlattenInst(inst 20 t nil))) ; end of fslDCfindObsoletePcellTechnically, this SKILL code with plug-in configuration part should becorrectly placed in network directory structure as first. Second, DesignConversion tool should be run by executing of its top procedure. Appeared toolmain form will contain “Flatten obsolete pcells” plug-in line which means thatthe plug-in has been registered. After necessary user selections all processedlayouts will be scanned to find “nmos” pcell. All found instances will be shownin Design Converted Scan Data form for designer’s approval, i.e. he/she shouldmove necessary statements to “Chosen” Scan Data form box. If designer willagree to proceed automatic design conversion then all signed-off instances willbe repaired to old pcell footprint and flattened.You can see from mentioned example that database conversion procedure couldbe too simple in terms of Design Converter Tool plug-in. Standard technologyindependent plug-in could be created as well to check and repair general designcompatibility features. Such type of plug-ins could be delivered with DesignConverter core, but their technology dependence could be provided bysimplified procedure – configuration plug-in - which will be a part of TDK.Configuration plug-in will tune external plug-in, e.g. through the known graphicform, for current technology support.To speed up plug-in development process several SKILL procedures werecreated and are presented by tool core in shared library. This library gives youaccess to some tool data and ma ke writing and debugging plug-ins easier. Hereis a list of available standard procedures:aldDCgetDCversion(): returns Design Conversion tool version;aldDCgetDCtechLibName(): returns technology library name if TDK mode isinvoked;aldDCgetDesignConversionPath(s_pluginId): to know the path to specifiedplug-in;aldDCgetViewType(dd_CellViewId): gives Cadence cell view from its dd ID;aldDCprint(t_msgseverity t_message):prints messages according to DesignConverter log file format.SummaryAs a result, Design Conversion tool was created and can be used for designlibrary checking and conversion. It can be a part of TDK or a separate SKILLutility. The following basic possibilities are supported by Design Converter:i. Check and update the following Cadence database objects: library, cell,cell view or instance. Update process is optional.ii.Present open interface for SKILL based programs (plug-ins) which areintended to check and fix design library. Differentiated support of plugingroups is available.

iii.iv.Run multiple checking and repairing procedures which correspond todifferent object types during single design library passing.Present all discovered database issues for user sign-off before theircorrection.v. Allow backup issue list for future processing.vi.Keep commo n log file during tool running.Developed design conversion methodology and implemented techniques help toachieve multiple benefits against separate migration tools as follows:a. Reduced development time for migration procedure due to separationof created and qualified generic tool core and required technologydependent plug-in code. The last one is greatly simplified because onlydatabase object processing is needed.b. Minimal risk of built-in errors due to limited functionality of plug-ins.In addition to local database object processing more primitivefunctionality could be implemented to the plug-in: it can configuresomeone generic plug-in only.c. No need to teach designers how the tool should be applied. Commonusage methodology is developed and presented by Design Converterfor any technology. Standard main form, issue report, single log fileand documented user guide provide quicker user’s adaptation to newmigration procedure.d. Full control for design update from user side due to implemented issueapproval procedure.e. Completed issue report without write access to checked database. Anydatabase processing is provided on opened for read object during Scanstage. This possibility is available independently from correctionprocedure presence.f. Custom conversion utilities support. Any designer can create owncustom plug-in and execute it by help of Design Conversion tool.g. Decreased database checking/conversion time. Tangible time benefitoccurs if bunch of design problems are necessary to resolve.Design Converter is successfully used by Freescale TDKs to decrease an impactto existing designs from emerged technology libraries and to present multipletechnology specific checking procedures for safe design development. Differenttypes of technologies demonstrated that the tool is really technologyindependent and can cover any database conversion need. Time resources whichare needed to support required database migration were dramatically reducedwith increasing of whole quality of Freescale design kits.