DISCLAIMER: THIS PAGE IS STILL UNDER DEVELOPMENT. THE INFORMATION HERE MIGHT BE INCORRECT OR OUTDATED.
Using openlane, you can produce a GDSII from a chip RTL.
The current methodology views the chip using the following hierarchy:
- Chip Core
- The hard macros
- The rest of the design
- Chip IO
- IO Pads
- Power Pads
- Corener Pads
The current methodology goes as follows:
- Hardening the hard macros.
- Hardening the core with the hard macros inside it.
- Hardening the full chip with the padframe.
This is discussed in more detail here.
The chip core would usually have other macros inside it.
You need to set the following environment variables in your config.tcl
file for the chip core:
::env(VERILOG_FILES)
To point at the used verilog files; those that were not previously hardened.::env(VERILOG_FILES_BLACKBOX)
To point at the blackboxes (the hardened macros).::env(EXTRA_LEFS)
To point at the LEF files of the hardened macros.::env(EXTRA_GDS_FILES)
To point at the GDS files of the hardened macros.
Therefore, the verilog files shouldn't have any includes in any of your verilog files. But use ::env(VERILOG_FILES)
and ::env(VERILOG_FILES_BLACKBOX)
for that purpose.
Add set ::env(SYNTH_READ_BLACKBOX_LIB) 1
, if you have ::env(VERILOG_FILES_BLACKBOX)
in your configuration file.
You can follow the same instructions provided here for the rest of the hardenning steps.
In case you want to manually place the macros in specific locations, this should provide a good example on how to do it.
Here you can find a list of all the available OpenLANE configuartions.
Check this section for more details on power routing setup.
The full chip requires an interactive script to harden. You could take this full chip as an example.
You need to set the following environment variables in your config.tcl
file for the chip:
::env(VERILOG_FILES)
To point at the used verilog files; those that were not previously hardened. Ideally, this should be only one file.::env(VERILOG_FILES_BLACKBOX)
To point at the blackboxes (the hardened macros). Ideally, this should include all the other verilog files.::env(EXTRA_LEFS)
To point at the LEF files of the hardened core macro.::env(EXTRA_GDS_FILES)
To point at the GDS files of the hardened core macro.
Therefore, the verilog files shouldn't have any includes in any of your verilog files. But use ::env(VERILOG_FILES)
and ::env(VERILOG_FILES_BLACKBOX)
for that purpose.
Add set ::env(SYNTH_READ_BLACKBOX_LIB) 1
, if you have ::env(VERILOG_FILES_BLACKBOX)
in your configuration file.
Add set ::env(SYNTH_FLAT_TOP) 1
to your config.tcl
. To flatten the padframe, if it's presented in a chip_io
module.
The following inputs are provided to produce the final GDSII:
- Padframe cfg file (provided by the user or generated by padring). Here is an example.
- Hardened lef & GDS-II for the core module, generated here
- Top level netlist instantiating pads and core module (Could be provided by the user or generated by topModuleGen)
Note: The chip Verilog file should contain a guard ifdef PFG
under which all the verilog file names should be included, without specifying a directory. This includes the verilog for the pads as well.
Given these inputs the following interactive script script. Mainly, it does the following steps:
- set
padframe_root $::env(TMP_DIR)/padframe/<chip design name>/
. - Copy all the lef files (of all the macros and power/corner/io pads) to
$padframe/mag
, and all the verilog files to$padframe/verilog
. - Copy the padframe cfg file to
$padframe/mag
. - Combine the pads lef, macros lefs and tech lef in one lef file.
- Use padring to generate the padframe.def and the core.def.
- Parse the padframe cfg file to get the diearea and input it to the floorplanner.
- Run the top level netlist through yosys.
- Running
chip_floorplan
which first generates a floorplan usingverilog2def
followed by removing PINS section and cleaning NETS section in the generated def file. - Replace the components of the floorplan def file with placed components from padframe def file and core def file.
- Perform manual placement if desired.
- legalize the placement.
- Perform
power_routing
. - Route the design.
- Perform power routing.
- Generate a GDSII file of the routed design.
- Run DRC and LVS checks.
This is discussed in detail here.
It should have an stdcell
section that includes a core_ring
on met4 and met5. It should use met5 and met4 for the straps, and met1 for the rails. Thus, make sure to add these to your config file:
set ::env(DESIGN_IS_CORE) 1
set ::env(FP_PDN_CORE_RING) 1
If your core contains other macros inside it. Then make sure to check the macro
section and see if it requires any modifications for each of them depending on their special configs. The default section specifies that metal4 pins should be hooked up to the metal5 straps.
Refer to this for more details about the syntax. In case you needed to create your own pdn.tcl
then point to it using PDN_CFG
.
When you use the power_routing
command in the chip interactive script, the power pads will be connected to the core ring, and thus the whole chip would be powered.
This includes more guidance on how to create an interactive script.
This documents all OpenLANE configurations.
This has a description for all OpenLANE commands.