armleo / OpenLane

OpenLane is an automated RTL to GDSII flow based on several components including OpenROAD, Yosys, Magic, Netgen, Fault and custom methodology scripts for design exploration and optimization.
https://openlane.readthedocs.io/
Apache License 2.0
0 stars 1 forks source link

Digital Guide Feedback- Final milestone #17

Open dralabeing opened 2 years ago

dralabeing commented 2 years ago

The following is specific feedback to updates here: https://armleo-openlane.readthedocs.io/en/merge-window-4/docs/source/digital_guide.html

  1. Title- Change to reflect the specific flow. " A bottom-up Digital Design Flow using a Memory Macro" I believe this section shows the macro hardening flow.

  2. Fix "This example covers creation of simple memory macro and top wrapper for it The guide generates the layout files for the submacro, then builds a top level chip register file containing two instances of the generated memory submacro ." to This example shows you how to create a simple memory macro in the OpenLane flow with a wrapper. Learn how to generate the layout files for the sub-macro, then use the generated memory sub-macro in a top level chip register file."

  3. Please refer to the writing guidelines to re-write this: **_One of the common mistakes people make is copying existing designs, like designs/inverter and then they face issues with their configuration. Always create new designs using -init_design_config. It will ensure that your configuration is the absolute minimum.

Example of the common issues people face: They copy inverter design, rename it. Then run the flow and the router crashes with error 10. This is caused by enabled “basic placement”, which works only for designs with a couple of dozen standard cells, not hundreds. So when you change the basic inverter with a design containing many cells router will not be able to route your design, therefore crashing with cryptic message._**

The Dos and Don'ts in general should not be verbose text but highlight through a Note or Warning ! e.g Warning! Do not copy existing design configuration files since this could lead to problems. Always create a new config file for your added design.

State that config.json is the design configuration file. Show a simple tcl example as well since users are more familiar with tcl.

  1. Then we need to create/copy the RTL files. -> Guideline !.. Create or copy RTL files... (not you will need to ....) Add a small description to show functionality of the memory macro being created. This note below is a bit confusing.. What is the definition of a small macro? Any instruction to design variables should be part of design configuration section. But this should definitely not be part of a Note that refers to a prior experience that the user may not be familiar with. "Originally we used a very small macro block as an example, however there is known issue: Small macro blocks do not fit proper power grid, therefore you need to avoid making small macro blocks. For this, set the FP_SIZING to absolute and configure DIE_AREA to be bigger than 200um x 200um for sky130."

  2. This link doesn't exist: configuration can be found here.

  3. DESIGN_IS_CORE controls the metal levels used for power routing, set it to false to use only lower metal layer levels. Check definition. This variable defines whether your design as a core or a reusable macro. For macros, set this to 0/false. Check if this controls the power routing metal layers, this could be done by FP_PDN_CORE_RING. This also controls power routing metal levels such that setting it to false/o will only use lower levels.

  4. Why is this set to false? FP_PDN_CORE_RING is set to false to disable a power ring around the macro block. This should be true as this macro is being hardened in the flow shown in the GUI image. This is confusing.

  5. Run the flow on the macro block -> This should be Hardening the macro. ./flow.tcl -design mem_1r1w -tag full_guide -overwrite -> Explain this step and arguments.

Point to link here: https://openlane.readthedocs.io/en/latest/docs/source/hardening_macros.html

  1. Analyzing the flow generated files ->Pending sdf files reading https://github.com/The-OpenROAD-Project/OpenLane/issues/1274 is a good Issue to fix to make it simpler.

  2. Create chip level-> Chip Level Integration: Create Chip Level Register File using the generated macro

  3. Blackbox creation->https://github.com/The-OpenROAD-Project/OpenLane/issues/1291. Creating a verilog black-box vs instantiating a parameter. The use model in this document needs to reflect a good design flow practice and OL support.

  4. Analyzing the results->Analyzing Results Describe what this does .. In this section you will analyze the flow results using the GUI - specifically timing paths... etc Analysis should show these: Intermediate results of placement, CTS, Global route, Congestion heat maps, Timing paths at top-level etc. Show GUI images of these rather for the top -level register file. "Change the FP_ASPECT_RATIO value to 2. This will make the flooplan a rectange instead of square and the rectangle will be double in height compared to width." -> Spell check the entire document, not the spelling mistake in rectangle. The very tall aspect ratio looks odd, change die area perhaps incrementally rather than the aspect ratio to get a good placement with reasonable wirelengths. Also, ask the user to try multiple placement options manually including halos and channel spacing and see impact on routing and performance.

  5. Add a sub-heading to show generated files/logs etc. Currently it is subsumed under Analyzing the results

It is recommended to check the reports for power, timings, etc. This allows to get better understanding of the underlying flow. Replace by Note as "Check reports for power, timing and area to get a good understanding of the flow results"

  1. Exploring your designs This looks like viewing reports rather than Design exploration. Change to Viewing Reports

  2. Debugging LVS issues due to PDN issues _> Debugging LVS issues in Power routing Also show an example of DRC errors which are also very common.

dralabeing commented 2 years ago
  1. Also add extraction of parasitics- spef file creation and using that in chip-level timing. Include a Signoff section for Timing and Power.

Please ignore this since there are still pending issues : https://github.com/The-OpenROAD-Project/OpenSTA/issues/116

vijayank88 commented 2 years ago

Few things that I captured: https://armleo-openlane.readthedocs.io/en/merge-window-4/docs/source/digital_guide.html

  1. Update rectange to rectangale
    Change the FP_ASPECT_RATIO value to 2. This will make the flooplan a rectange instead of square and the rectangle will be double in height compared to width.
  2. There is 4 directories logs reports results and tmp. In each of these directories there is multiple directories. Directories are named according to the stage they belong to.

    Update as follows:

    There are 4 directories `logs` `reports` `results` and `tmp`. In each of these directories there are sub-directories available. Those are named according to the stage they belong to.

https://armleo-openlane.readthedocs.io/en/merge-window-4/docs/source/openram.html

  1. Update missmatch to mismatch

  2. FP_SIZING is set to absolute and it will tell the floorplan to use DIE_AREA as final macro block’s size. The we set the DIE_AREA.

    The we set the DIE_AREA Please complete this sentence.

  3. The instance name needs to be taken directly from synthesis netlist without escape symbol at the beggining.

    Update beggining to beginning

  4. This topic https://armleo-openlane.readthedocs.io/en/merge-window-4/docs/source/openram.html#drcs-inside-sram-macros need to be reviewed clearly I think. There GRT_OBS to avoid drc error specific to SRAM macros co-ordinates. You can't skip entire magic drc check by default.

dralabeing commented 2 years ago

@kareefardi If possible we should point to the use of odb use over read/write DEF for better performance in general. I know this is pending but please comment if we can use this to effectively point to the user. https://github.com/The-OpenROAD-Project/OpenLane/pull/1244

kareefardi commented 2 years ago

I agree. The pull request is almost done and merged. Once it is merged, If we have enough time we can try and update the guide.