[DOC] add documentation on how to use the magic embedded within the openlane docker. This waives the magic installation requirement.
diff --git a/README.md b/README.md
index 9679858..bae5f64 100644
--- a/README.md
+++ b/README.md
@@ -35,9 +35,11 @@
Then, you will need to put your design aboard the Caravel chip. Make sure you have the following:
-- Magic installed on your machine. We may provide a Dockerized version later.
+- [Magic VLSI Layout Tool](http://opencircuitdesign.com/magic/index.html) installed on your machine. We may provide a Dockerized version later.\*
- You have your user_project_wrapper.gds under `./gds/` in the Caravel directory.
+ > \* **Note:** You can avoid the need for the magic prerequisite by using the openlane docker to run the make step. This [section](#running-make-using-openlane's-magic) shows how.
+
Run the following command:
```bash
@@ -47,6 +49,32 @@
This should merge the GDSes using magic and you'll end up with your version of `./gds/caravel.gds`. You should expect hundred of thousands of magic DRC violations with the current "development" state of caravel.
+## Running Make using OpenLANE's Magic
+
+To use the magic installed inside Openlane to complete the final GDS streaming out step, export the following:
+
+```bash
+export PDK_ROOT=<The location where the pdk is installed>
+export OPENLANE_ROOT=<the absolute path to the openlane directory cloned or to be cloned>
+export IMAGE_NAME=<the openlane image name installed on your machine. Preferably openlane:rc5>
+export CARAVEL_PATH=$(pwd)
+```
+
+Then, mount the docker:
+
+```bash
+docker run -it -v $CARAVEL_PATH:$CARAVEL_PATH -v $OPENLANE_ROOT:/openLANE_flow -v $PDK_ROOT:$PDK_ROOT -e CARAVEL_PATH=$CARAVEL_PATH -e PDK_ROOT=$PDK_ROOT -u $(id -u $USER):$(id -g $USER) $IMAGE_NAME
+```
+
+Finally, once inside the docker run the following commands:
+```bash
+cd $CARAVEL_PATH
+make
+exit
+```
+
+This should merge the GDSes using magic and you'll end up with your version of `./gds/caravel.gds`. You should expect hundred of thousands of magic DRC violations with the current "development" state of caravel.
+
## Managment SoC
The managment SoC runs firmware that can be used to:
- Configure User Project I/O pads
diff --git a/openlane/README.md b/openlane/README.md
index d62bd35..9218d7d 100644
--- a/openlane/README.md
+++ b/openlane/README.md
@@ -17,7 +17,7 @@
**NOTE:** We are developing caravel using openlane:rc5 which is the current develop branch. openlane:rc5 will be merged to master once the caravel chip is finalized.
-**NOTE:** rc5 (current openlane develop) and rc4 (current openlane master) are using two different concepts of cell padding. rc4 is modifying the LEF, while rc5 is relying on openroad to handle the cell padding. Also, rc4 is using the standalone version of openDP while rc5 is using the one integrated in the openroad app. This affects the concept of PL_TARGET_DENSITY and while in rc4 it was preferred to have PL_TARGET_DENSITY=(FP_CORE_UTIL-(5~10)/100). Now, in rc5 it is preferred to be PL_TARGET_DENSITY=(FP_CORE_UTIL+(1~5)/100).
+**NOTE:** rc5 (current openlane develop) and rc4 (current openlane master) are using two different concepts of cell padding. rc4 is modifying the LEF, while rc5 is relying on openroad to handle the cell padding. Also, rc4 is using the standalone version of openDP while rc5 is using the one integrated in the openroad app. This affects the concept of PL_TARGET_DENSITY and while in rc4 it was preferred to have PL_TARGET_DENSITY=(FP_CORE_UTIL-(5\~10)/100). Now, in rc5 it is preferred to be PL_TARGET_DENSITY=(FP_CORE_UTIL+(1\~5)/100).
FP_CORE_UTIL should be relaxed as well as it became more representative of the actual core utilization, which wasn't so much the case earlier. So, the perception of these two variables as well as CELL_PAD changed between rc4 and rc5 which necessitates a change in the configurations of almost every single design.
CELL_PAD should be 4~6 for the skywater libraries in rc5 unlike rc4 which was 8.This will be included in the release notes when rc5 is released as well as the openlane wiki.