Skip to content

TSMC 28nm - Cadence CUI flowkit

To get access to the design flow, you can either clone the repositories below or use the direct download links. The core part of the scrips is open and common among all design flows. The main repositories that include technology specific information, require a valid 3-way NDA for the specific technology. For more info contact asic.support@cern.ch.

The flow is developed and supported by the CERN ASIC Support Service with contributions from the HEP community. Any contribution, be it minor or major, is very welcome. Please see Contributing guide.

Flow setup instruction

1. Clone or download the repository

Clone with https:

git clone --recursive https://gitlab.cern.ch/asic-design-support/digital-design-flows/hep-tsmc28/hep-digital-flow-tsmc-28nm.git

Or clone with ssh:

git clone --recursive ssh://git@gitlab.cern.ch:7999/asic-design-support/digital-design-flows/hep-tsmc28/hep-digital-flow-tsmc-28nm.git

Or download a .tar file:

Download latest release v2025.04

This repository contains the main Flowtool file (flow.yaml) and other configuration files (inside config/). These files are project-dependent, so you need to edit them (see below).

You should have one submodule folder populated (common-scripts), which contains technology-independent flow steps and scripts.

This submodule is project- and technology-independent and should not be modified unless you have specific needs. This structure allows to keep the flow steps updated, without overwriting your project configuration. When an update on the submodule is available, a simple git submodule update --remote --merge will get you the latest version.

2. Edit the configuration files

  1. config/setup.yaml contains design and tool related variables

    • flow_root must be adjusted to point to the 'impl' directory in the flow repository.
    • rtl_list and/or rtl_listfile must be altered/filled to point to your RTL sources.
    • rtl_include_dirs must be filled with the RTL include directories (if any).

  2. config/setup_mmmc.yaml contains the MMMC definitions (change this only if needed)

  3. Put your SDC files inside config/constraints/.
    Don't forget to associate them to the correct mode in the MMMC config.

  4. Fill in the file config/cds.lib to include your base cds.lib (usually in your home folder) and any other needed cds.lib (for macros, IPs, etc.).
    By default (with an RTL-only design), no changes to the cds.lib are needed, and it will be copied to the work directory automatically

  5. Put your CPF or UPF power intent files inside config/power_intent/.

3. Familiarize with the flow

The file flow.yaml is the main configuration file to manage the Flowkit execution. The file is composed of different sections:

  • Flow Setup section: can be disregarded.

  • Feature Definition section: lists and describes the available flow features. You can enable optional features by adding them to the "features:" YAML key, or by passing them on the command line when invoking Flowtool with the -enabled <feature> option.

  • Flow Step Definitions section: reads in the TCL files where the flow steps are defined. Should you have a file with custom flow steps, add it to the user_flow_steps list. The flow_current key contains the list of flows (defined in the Flow Definitions section) that will be run by default by Flowtool.

  • General Flow Configuration section: reads all the other YAML configuration files.

  • Flow Definitions section: defines the flows and all the steps inside them. There are many possibilities to customize the flow, which are beyond the scope of this README. Some tips are described in the comments at the beginning of the section.

4. Run the flow

Create or go to any working directory you like. Ensure that all neccessary changes in setup.yaml and setup_mmmc.yaml have been made. Following that, the flow may be invoked using the command:

flowtool -file <path to main repository>/flow.yaml [options]

Some useful options are:

  • -predict summary and -predict verbose to get a prediction of the steps that will be executed without actually running the flow

  • -from <step> and -to <step> to run the flow only from or to a specific step (-flow <flow> is a shorthand for -from <first step of flow> -to <last step of flow>)

  • -interactive loads the configuration files and open an interactive session of the tool, but does not execute anything (use run_flow <step> inside the tool to run step by step)

  • -verbose to see the live output of the tool session

5. Examples

  • Run a prediction of all flow steps that will be run:

    flowtool -file <path to main repository>/flow.yaml -predict verbose

  • Run the whole flow with limited output info:

    flowtool -file <path to main repository>/flow.yaml

  • Run the whole flow with the full tool output:

    flowtool -file <path to main repository>/flow.yaml -verbose

  • Run the synthesis flow only:

    flowtool -file <path to main repository>/flow.yaml -flow synthesis

  • Run until a particular step:

    flowtool -file <path to main repository>/flow.yaml -to place.block_finish

  • Load the configuration and flow steps and open an interactive session of the tool:

    flowtool -file <path to main repository>/flow.yaml -interactive

  • Run the flow with an interactive session open:

    flowtool -file <path to main repository>/flow.yaml -flow implementation -interactive_run

  • Run with a single tool session for each tool. By default, it opens a new session at every flow. This saves runtime, but you get aggregated logs and reports.

    flowtool -file <path to main repository>/flow.yaml -isolate tool

6. Notes for triplicated designs

This flow provides the tmr_design feature, which turns on some additional steps to take case of particular constraints for TMR designs, like preserving voters and special placement distance constraints. However, every designer has its own preference for implementing triplication, and so these steps will never be general enough to cover all possible use cases. By default, this these steps are disabled, so that the implementation flow can be used also for other use cases. To enable the extra flow steps, you may either add -tmr_design to the features: attribute in flow.yaml, or you can use flowtool <your_arguments> -enabled tmr_design.

If you are using this flow to implement a TMR design, you should take a look at the special TMR steps and customize them to suit your needs, naming conventions, particular design choices, etc, or add new ones from scratch. These steps are for example:

  • c_set_preserve_objects

  • c_set_dont_touch

  • c_unset_dont_touch

  • c_tmr_set_place_distance

  • c_tmr_set_tieoffs_distance

  • c_tmr_create_regions (this is an example and it's not included in the flow)

Maintainers

Contributing

All types of contributions, being it minor and major, are very welcome! Feel free to create issues or create a branch and generate a merge requests on the repository. For more info contact asic.support@cern.ch.

Flow-script library submodule

All the currently supported flow share the same scripts library "flow-scripts".

You can consult the flow-scripts submodule release description and changelog.

Flow release changelog

[v2025.04]

Contributors:

Description:

  • tsmc-28 #24
    • The export_timing_model step was not finishing in reasonable time in version 23.X in tempus.
    • Moved back Liberty files and SDF generation to Innovus and improved procedure
  • common-scripts #104
    • The set_preserve_objects step is the step that was added to preserve instances and nets named as *_preserve, since it is common practice. Usually the designers might add in the SDC constraints or in the scrips somewhere a statement to preserve or apply a dont_touch on such instances. This step was allowing to do so by default.
    • The step is now called for both triplicated and not triplicated designs.
  • common-scripts #103
    • Removed subflow that was meant to run an additional optimization step in innovus, with settings closer to the Tempus default settings.
    • Those settings are too "design specific" and make no sense to keep this step. If the user wants to change the settings for the optimization, they can do it according to the design and technology needs.
  • common-scripts #101
    • Flow was failing on re-invocation of export if the OA library already exists.
    • This is a well known issue from Innovus. The applied workaround consists in sed the cds.lib file from within the scripts.
  • common-scripts #106
    • if using -isolate tool feature, the derate factors are applied multiple times.
    • This bug was introduced in the 2025.03-0 release
  • common-scripts #105
  • make the DB portable between designers removing absolute paths
    • Used the suggested approach and script of @pevicent
  • common-scripts #100
    • Catch errors when external executable eventually don't return successfully and report the error
  • common-scripts #20
    • Add export LEF and DEF steps

Merge-requests:

[v2025.03]

Contributors:

Description:

  • Renames the corners and analysis views to comply with the conventions used by TSMC
  • fix SI netlisting script
  • Move CI to common repo
  • Update features definition and other improvements
  • Flow compatible with both v22.xx and v23.xx

Merge-requests:

[v2025.02]

Contributors:

Description:

  • Issue 95
    • Update Cadence flowtool base scripts to DDI v23.XX
    • Flow compatible with both v22.xx and v23.xx
  • Issue 51:
    • Fix codespell errors for passign projects linting checks
    • Update flow steps names for consistency
    • Changes for linting
  • Issue 94
    • Update naming conventions for complex ports, data structs and generate modules to simplify SEE injection
  • Issue 92
    • support for LDB compiled libraries and for tmp in local disk
  • Issue 51
    • Fix codespell errors for passign projects linting checks
    • Update flow steps names for consistency
    • Changes for linting.
  • Issue 93
    • fix minor bug for TMAKE flow in remove_std_cells_lib.

Merge-requests:

[v2025.01]

Contributors:

Description:

  • Issue 86
    • removed features control for report_defer and sta_glitch
  • Issue 87
    • Create subflow to avoid polluting flow.yaml file with schedules, report_inline and report_none features
    • Currently the flow was not clear with mix of enabled and scheduled subflows. In this case the complexity is handled behind.
  • Issue 88
    • Created standalone signoff_checks flow
    • Before signoff was scheduled from design finishing. Now a standalon flow schedle in parallel all the signoff checks:
Parallel execution order:
                                        ____Signoff STA (tempus)
             _____ Extract (Quantus)___/___ IR static (voltus)
signoff ____/_____ DRC (Calibre)       \___ IR dynamic (voltus)
  • Issue 89
    • created scheduling sub-flows for: report_synth, report_place, report_postcts, report_postroute

  • Reorganization of files

  • Issue 36

    • Report_lint missing in synthesis
  • Issue 47
    • Increase max_net_name_length in the ihdl generated script to avoid problem when generating schematic
  • Issue 41
    • Remove -turbo_all option from Calibre command
  • Issue 75
    • Generalise procedure for handling libraries into common repo

  • Created common_procedure.tcl file

  • Issue 69

    • Allow multiple signoff schedules run in parallel making copy of QRC command file
  • Issue 70
    • Update timing reports in a more coherent structure and naming across the flow
  • Issue 71
    • Added assemble design subflow and steps for flat signoff STA
  • Issue 72
    • Moove SDF export to signoff STA in tempus
  • Issue 73
    • Remoove tmr distance for tie-low and tie-high cells. It is not needed

  • Issue 74

    • Handle creating missing paths to avoid errors when running flow not linearly

  • Issue 61

    • Update TMR dont_touch constraints
  • Issue 62
    • update tmr_set_place_distance procedures
  • Issue 63
    • Update TMR voters reporting
  • Issue 64
    • Add step check_voter_connections
    • Check from @mandorno to check the registers that goes to a voter, only goes to a voter.
    • It creates a report to be evaluated by the user, according the design specific approach.
  • Issue 65
    • Fixes in postroute_advanced_opt step
    • this step was previously not usable
    • the step is disabled by default but it can now be enabled
  • Issue 66
    • Improve eco_drc_fix step
    • The eco_route -fix_drc had limited capabilities.
  • Issue 67
    • Improve TMR voters checks
    • Check that the voter instances are not removed while proceeding in different design phases
    • It creates a report to be evaluated by the user, according the design specific approach.
  • Issue 68
    • Improve TMR distance checks including clock source origin in reporting
    • The check was reporting instances according regex on the name conventions. Now it does in addition based on the source of the clock tree.
    • It creates a report to be evaluated by the user, according the design specific approach.
  • Issue 84
    • List triplicated and non-triplicated latches in addition to flip-flops
    • Follow-up from !21 @pevicent suggestion
  • Issue 85
    • Remove base cell names dependencies in scripts
    • Follow-up from !21 @pevicent suggestion
  • Issue 83
    • Generalize power layers names for technology independence
    • Follow-up from !21 @pevicent suggestion
  • Changes for linting.

Merge-requests:

[v2024.12]

Contributors:

Description:

  • Issue 60
    • Update non-default routing rules for CTS
  • Issue 58
    • Set cts_update_clock_latency to false for top-level implementation.
    • If not explicitly specified (with the command set_db cts_update_clock_latency false), Innovus CTS engine applies by default the concept of “Source Latency Update”, calculating and employing updated SDC constraints for clock pin latencies. Those latencies are derived according to the results obtained during the clock tree synthesis step (in particular the achieved insertion delay) and are necessary to ensure that “after CTS, when clocks are switched to propagated mode, I/O timing and inter-clock timing is consistent with the ideal mode timing model”. In a top-level flow, this setting should be off. For a block level design, is up to the designer.
  • Issue 59
    • Convert clock tree latencies from liberty file for hierarchical design.
    • The concept of Clock latency update takes into account the achieved clock insertion delay inside the block. If you don’t use the ILM model suggested by Cadence Support, one way to provide information about the clock tree depth inside a hierarchical module to the top level CTS engine is to use the command convert_lib_clock_tree_latencies, which instructs the top level of the design about the clock tree path contained inside you macro block.
  • Issue 82
    • Generalize CTS steps to be independent on the technology layers naming convention. Follow-up from !19 comments
  • added init_innovus_preconfig for messages settings
  • Issue 55
    • Fix elif {[is_flow -inside ..]} bug was preventing settings to be applied when needed.
  • Issue 56
    • Update Innovus set_db attributes
  • Issue 57
    • Suppress errors on TSMC libraries replicated instances
  • Issue 58
    • Set cts_update_clock_latency to false for top-level implementation.
    • If not explicitly specified (with the command set_db cts_update_clock_latency false), Innovus CTS engine applies by default the concept of “Source Latency Update”, calculating and employing updated SDC constraints for clock pin latencies.
  • Issue 52
    • update tempus setting for signoff STA
  • Issue 53
    • Add OCV derate settings in Tempus signoff STA
  • Issue 54
    • Add OCV settings in multiple steps since it is not mantained reloading the database
  • Minimal reorganization of the code porting the flow.yaml and the innovus config inside the common-scripts repository (#50)
  • Fix some codespell errors (#51)
  • Reassign step owner to cern for custom steps
  • A bit of cleaning

Merge-requests:

[v2024.04]

Contributors:

Merge-requests:

Description:

  • Issue 42
    • the common scripts were not (yet) tech agnostic as there was a SDF* in the scan chain declaration, therefore set the scan chain naming as a config
  • Issue 43
    • There was no step to write the netlist at the synthesis stage
  • Issue 44
    • The way the physical cells were defined was not yet tech agnostic only apply set_dont_use if scan chain cell exists
  • Added CI tests
  • Updated for 2024 tool releases
  • Bug fixes

[v2023.12]

Contributors:

Description:

  • Refactored repository for Tmake integration
  • multiple changes in structures
  • impruved support for multiple technologies
  • Multiple issues closed
  • most of changes are in the common-scripts repository

[v2023.03]

Contributors:

Description:

  • Reorganized the structure of flow repositories using submodules
  • Moved flow on 2023 Europractice releases

[v2023.01]

Contributors:

Description:

  • Added Calibre DRC and LVS steps
  • Added custom message suppression
  • Modified cds.lib creation step
  • Bug fixes
  • Added Gitlab CI for release generation
  • Added config directory variables in setup.yaml
  • Added Voltus XY file support to setup.yaml
  • Moved signoff flow to design finishing
  • Moved out export and physical verification flows
  • Bug fixes

[v2022.11]

Contributors:

Description:

  • Bug fixes
  • Fixed missing flow for TMR feature
  • Fixed bug when using multiple libraries in the MMMC
  • Fixed README
  • Removed old Stylus flow and scripts. Flowkit is now the main flow.

[v2022.05]

Contributors:

Description:

  • Initial release

Terms and conditions

BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.