1Capabilities/Limitations 2======================== 3 4Global Considerations 5--------------------- 6 7- OpenROAD v1.0 production will be focused on the tapeout mentioned in 8 the above introduction. Features will be implemented in priority 9 order based on our sponsor requirement to make the chosen design 10 manufacturable. In Phase 2 of the IDEA program, the OpenROAD tool 11 feature set will be rounded out and more of the project’s flow and 12 tool research objectives will be addressed. 13- Each new design enablement (foundry process/PDK, library, IPs) will 14 require setup via configuration files, one-time characterizations, 15 etc. as documented with the tool. Examples include (i) the setup of 16 PDN generation, (ii) the creation of “wrapped LEF abstracts” for 17 cells and/or macros to comply with Generic Node Enablement (see 18 Routing, below), and (iii) the creation of characterized lookup 19 tables to guide CTS buffering. 20 21Supported Platforms 22------------------- 23 24- OpenROAD v1.0 will build on “bare metal”, CentOS 7 with required 25 packages installed as specified in the README. 26- MacOS will also be supported. 27- Users with access to Docker will also be able to build on any machine 28 using the included Dockerfile. 29 30Design Partitioning and Logic Synthesis 31--------------------------------------- 32 33- Logic Synthesis (Yosys) will accept only hierarchical RTL Verilog. 34- SystemVerilog to Verilog conversion must be performed by the user 35 (e.g., using bsg sv2v or any tool of their choosing) before running 36 Yosys. 37- Logic Synthesis is one of potentially multiple steps in OpenROAD that 38 may require a single merged LEF as of the v1.0 release. A utility 39 script to perform merging is 40 `here <https://github.com/The-OpenROAD-Project/alpha-release/blob/master/flow/scripts/mergeLib.pl>`__. 41- To support convergence in the downstream place-CTS-route steps, it is 42 advisable to exclude cells that risk difficult pin access (e.g., 43 sub-X1 sizes) and/or to invoke cell padding during placement. The 44 cell exclusion would be akin to a “dont_use” list, which is not 45 currently supported and must be manually implemented by editing the 46 library files. 47 48STA 49--- 50 51- Supports multi-corner analysis (e.g., setup and hold), but with limit 52 of one mode. 53- SDC support up to latest public, open version (e.g., SDC 1.4). 54- No SI analysis: any coupling caps can be multiplied by a “Miller 55 Coupling Factor” (MCF) and then treated as grounded. 56- No CCS/ECSM (current-source model) support. 57- No LVF support. 58- No PBA analysis option. 59- No instance IR drop (i.e., setting a rail voltage for given 60 instance). 61- No reduction of non-tree wiring topologies. (Arnoldi reduction 62 provided along with O’Brien-Savarino, 2-pole, Elmore reduction and 63 delay calculation options.) 64 65Floorplan 66--------- 67 68- Macro placement is limited to 100 RAMs/macros per P&R block. 69- PDN configuration files must be provided by the user. These are 70 documented in the “pdngen” tool repo, 71 `here <https://github.com/The-OpenROAD-Project/pdn>`__. 72 73Placement 74--------- 75 76- A P&R block is limited to one logic power domain and one I/O power 77 domain. Additional power domains must be handled manually (OpenROAD 78 Tcl scripting). 79- Isolation cells, level converters and power management must be 80 manually inserted into the layout by the user (e.g., as 81 pre-placements). 82- No support of UPF/CPF formats for power intent. 83- Support of user guidance for logic clustering and placement will be 84 limited to “fence” and “pre-placement” guidance, with the caveat that 85 such guidance may degrade solution QOR in the OpenROAD flow. 86 87Clock Tree Synthesis 88-------------------- 89 90- Support only positive edge-triggered FFs 91- Hold buffering will be at post-CTS and not later in the flow 92 93Routing 94------- 95 96- The TritonRoute router will not understand LEF57, LEF58 constructs in 97 techlef: the workaround is OpenROAD Generic Node Enablement (see 98 “OpenROAD Requirements for Generic Node Enablement, at `this 99 link <https://docs.google.com/document/d/1-KyRNu7qU_7oMYxXB5ToTkLv2C9AJbUAHJQr24rIU7U/edit?ts=5db1f0b2>`__). 100- Users should be advised that TritonRoute does not handle coloring 101 explicitly; a color-correct-by-construction methodology (e.g., for Mx 102 layers in 14/12nm) is achieved via Generic Node Enablement. 103- Antenna checking and fixing capability is committed for v1.0. 104 105Layout Finishing and Final Verifications 106---------------------------------------- 107 108- Parasitic extraction (SPEF from layout) is unlikely to comprehend 109 coupling. 110- There is no “signoff-quality electrical/performance analysis” 111 counterpart to “PrimeTime-SI” (timing, signal integrity) or 112 “Voltus”/“RedHawk” (power integrity). 113- A golden PV tool will be the evaluator for DRC. 114- Generation of merged GDS currently requires a Magic 8.2 tech file. 115 Details are given 116 `here <https://github.com/The-OpenROAD-Project-Attic/OpenROAD-Utilities/tree/master/def-to-gdsii>`__. 117- Export of merged GDS does not add text markings that may be expected 118 by commercial physical verification tools. 119- For supported design tape-outs (particularly, at a commercial 14/12nm 120 node, up through July 2020), physical verification (DRC/LVS) is 121 expected to be performed by the design team using commercial tools. 122 (Everything up to routed DEF and merged GDS will be produced by 123 OpenROAD or other open-source tools.) 124