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