This purpose of this tutorial is to demonstrate running a simple design through the Cadre group backend design flow (“Cadre Flow”).

The sample design included in this version (v1.0) is a simple 8-bit adder. The purpose of such a simple design is so that the turnaround time from RTL to signed-off GDS takes minutes and not days. It allows the user to view each step of implementation and understand how the flow works. We plan on creating other tutorials that feature more complex designs and exhibit more behaviors that would be found in making a state-of-the-art SoC.

Cadre Flow includes several components used for designing SoCs:

Directory Structure

By default, Cadre Flow uses a default directory structure for storing source files and generated files. These paths are customizable, but that is beyond the scope of this tutorial.

Source files/directories

blocks/ - This is an optional directory that is used for hierarchical designs. It is not used in this tutorial. - This is a Makefile fragment that is used for setting project parameters and paths. A majority of the required parameters are already set in the include file, which is sourced by this file. This file can also be used to override any defaults found in include

Makefile - This is the main Makefile for the project. All of the default rules are located in the Makefile file, which is sourced by this file. This file can be used to add additional rules or override the default rules.

scripts/ - This directory contains user plugin scripts and design parameters

that allow the user to customize steps of the flow.

src/ - This is a directory that contains all of the source files for the project (Verilog, SystemVerilog, memory specs, etc.). The exact source directory structure inside of the src directory is quite flexible and user customizable.

Generated files/directories

Running the Cadre Flow

There are several rules included the the default makefile, which are generally sequentially dependent. The steps are:

  1. make synth - runs synthesis synthesis using Design Compiler. The synthesized netlist ends up at results/dc/adder.mapped.v
  2. make init - runs initialization of the netlist for APR using Innovus. The checkpoint ends up at checkPoints/init.enc.
  3. make place - runs initial cell placement for APR using Innovus. The checkpoint ends up at checkPoints/place.enc.
  4. make cts - runs clock tree synthesis (CTS) for APR using Innovus. The checkpoint ends up at checkPoints/cts.enc.
  5. make postcts hold - runs post-CTS hold time fixing for APR using Innovus. The checkpoint ends up at checkPoints/postcts hold.enc.
  6. make route - runs global route for APR using Innovus. The checkpoint ends up at checkPoints/route.enc.
  7. make postroute - runs detailed route and optimization for APR using Innovus. The checkpoint ends up at checkPoints/postroute.enc.
  8. make signoff - runs the QRC signoff-quality extraction engine to do timing analysis and backend (routing) DRCs. The checkpoint ends up at checkPoints/signoff.enc. It also creates the final unfilled GDS at results/innovus/adder.gds.gz
  9. make drc - runs dummy fill and DRC with all DRC decks using Calibre. The filled design is merged with the seal ring GDS and the final GDS ends up at results/calibre/
  10. make lec signoff - runs formal verification between the post-synthesis netlist and the post-APR netlist.
  11. make lvs - runs Layout Vs. Schematic signoff using Calibre.
  12. make primetime - runs timing and signal integrity signoff using PrimeTime SI.
  13. make voltus - runs power signoff using Voltus.
  14. make export - copies all files required to create a block design into the export folder. Because adder is a chip-level design, it will export the final GDS into the export folder as well (which is the only file you will need to submit to the fab).

Because of the Makefile dependencies, you can simply run make export to create the final GDS and copy it to the export/ directory. To make the design and run all signoff steps, you can run make all.

Examining Results

To examine the results for almost any step, you can simply run make debug * where * is the name of the step as described in Section 3.

All reports (including for the steps not listed above) will be available in the reports/ directory under that tool’s specific directory.