Cadence Documentation

Table of Contents

1. Install License Server
2. Onboard New Users
3. Offboarding of Users
4. Directory Structures
   1. ASIC Document Links
   2. Sharepoint Directory Structure
   3. Github Directory Structure
5. Git Usage
   1. Git Introduction
   2. Stage & Snapshot
   3. Branch & Merge
   4. Update/Syncing
   5. Graphical Tools
      1. Git Cola
         1. Staging Files
         2. Committing Files
         3. Push Files
      2. Git DAG
   6. Github SSG Key
6. Xenter Project Environment
   1. Project Environment Introduction
   2. Revision Control Using Git
   3. Project Directory Structure (Virtuoso)
      1. CAD Repository
      2. Chip Repository
      3. User Work Area
         1. Getting Started with D-ASI/D_ASIC/DA_ASIC, P-ASIC, and SmartICS Projects
         2. Getting Started with IE_ASIC
         3. Getting Started with TI_ASIC
      4. Library Repository
      5. SmartICS Repository
   4. Layout
      1. DRC
      2. LVS
   5. Naming Conventions

Install License Server

1. Cadence uses a FlexLM license server to distribute licenses on demand to engineers.

2. The license server can be hosted on Windows or Linux. Note that the license you install on the server will be tied to the MAC address of the network card in use. The MAC must never change else a new license will need to be installed.

3. Install the lsb-tools dependency. Redhat/Fedora/Rocky

   dnf install redhat-lsb-core

   Ubuntu/Debian

   apt update && apt install lsb-release

4. Download the most recent hotfix for the Lic+Config_Utils package from downloads.cadence.com to the linux server.

5. Extract the package:

   tar xf Hotfix_LCU22.01.003_lnx86_1of1.tar

6. Extract the tools package

   tar xzf LCU22.01.003_lnx86.Hotfix/CDROM1/kits/SftShrTools19.03-p001lnx86.t.Z

7. Open the tools folder:

   cd LCU22.01.003_lnx86.Hotfix/CDROM1/kits/tools.lnx86/

8. Copy the contents of the bin folder to the location you want to install the license server such as /opt/cadence/bin.

   mkdir -p /opt/flexlm/cadence/bin && cp bin/* /opt/flexlm/cadence/bin

9. Add /opt/flexlm/cadence/bin to the system PATH

   echo 'PATH=/opt/flexlm/cadence/bin:$PATH' >> /etc/profile

10. Download the license file to the xenter home directory and then move it to /opt/flexlm/cadence

    cp ~/home/xenter/license.txt /opt/flexlm/cadence/license.dat

11. Set the license file path environment variable in /etc/profile to make it system wide.

    echo 'LM_LICENSE_FILE=/opt/flexlm/cadence/license.dat' >> /etc/profile

12. Update the SERVER and DAEMON lines in license file with the correct hostname and path to cdslmd.

    SERVER lm.int.xentermd.com 0a620089b50a 5280
    DAEMON cdslmd /opt/flexlm/cadence/bin/cdslmd

13. Now you can start the license server with this command:

    lmgrd -c $LM_LICENSE_FILE

14. Create a system user for FlexLM

    useradd -r flexlm

15. Create a systemd service to start at boot:

    touch /etc/systemd/system/flexlm.service

16. Edit the new flexlm.service file and add in the following:

    [Unit]
    Description=Licence manger for Cadence
    After=network.target
    
    [Service]
    Type=simple
    User=flexlm
    WorkingDirectory=/opt/flexlm/cadence
    ExecStart=/opt/flexlm/cadence/bin/lmgrd -z -c $LM_LICENSE_FILE
    SuccessExitStatus=15
    Restart=always
    RestartSec=30
    
    [Install]
    WantedBy=multi-user.target

17. Enable the new systemd service:

    systemctl daemon-reload
    systemctl enable --now flexlm.service

Onboard New Users

The cadence environment requires sourcing of variables and filepaths for the various configurations and executables so that the user can easily start up the environment and begin working on their project. This script is automatically applied to every user that logs in as its located in /etc/profile.d/cadence.sh. Updates made to these files are thus global and apply to all users.

There is also a /home/dev folder which contains each of the projects that the engineers are collaborating on. Most of the project data will be found here.

To onboard a new user, all you need to do is execute the new_cadence_user.sh script. The script is located in the it_scripts repository on the corporate github account and should be installed to the system PATH as well. Run the script with admin privileges and answer the prompts to create a new user. Choose a temporary password for the user which you will have them change once you start configuring the user development environment. The script will generate SSH keys that you will need to distribute to the user.

User’s will utilize a VNC connection tunneled over SSH to access the server. This requires each user to have a SSH and VNC client set up on their computers. I recommend bitvise and tigervnc. Most any VNC/SSH client will work, but they all have nuances. From experience, TigerVNC and Bitvise seem to provide the simplest and best user experience. Thus this guide will use screenshots from those applications. The same concepts will apply though if you decide to use different VNC/SSH clients. Note that each VNC connection uses a port, meaning that each user will have their own dedicated port for VNC connections. This port is automatically chosen by the script thats run and you can see what the port number is by looking at the user’s systemd service file: /etc/systemd/system/vnc_username@.service. You will need to know that port number for later.

1. Provide SSH keys to user and configure ssh client. Bitvise has a key manager you can use to import the key. This is recommended as it doesnt require the user to remember where the key file is. You can import and then delete the key file.

   

   Bitvise SSH Client

2. Once you have imported the key to Bitvise, change the password for the key. You can do so using the Bitvise key manager.

   

   Bitvise Key Manager

3. Enter the username and port info in Bitvise.

4. Next, configure the SSH tunnel. Click on the C2S (Client to Server) tab and then click add. Fill in the following information:

   • Listen Interface: 127.0.0.1
   • Port: 59XX (Put the User’s VNC port here.)
   • Destination Host: cadence.int.xentermd.com
   • Port: 59XX (Put the User’s VNC port here.)
   • Comment: Put the user’s work email here

   

   Bitvise Client to Server Tunneling

5. Test that you can open a ssh connection. If there is a message in the bitvise logs about a tunnel failing to open, revisit step 3 and ensure that you entered the information appropriately. If the info is correct, then check that the service has been started for that user on the Cadence server. You can see a list of all VNC services and their status using this command:

   systemctl list-units vncserver_*.service

6. Save the Bitvise settings as a profile in the user’s OneDrive Documents folder. Click on the save button on the left side of Bitvise to save the profile. This makes it easy for a user to load the settings and not have to worry about remembering every little detail.

7. Open a terminal using bitvise and execute the following command to set the vnc password for the user. Just set it as 123456 as that is easy for the users to remember and the vnc password does very little from a security POV. The SSH tunnel and SSH authentication provide the security instead of VNC.

   vncpasswd

8. Open TigerVNC and put in the following: localhost::59XX (replace 59XX with the appropriate port number for the user)

9. The user should now have a VNC session they login to. Once the initial setup is complete, it’s a 2 step process for the user’s to login each time:

   1. Login to server via SSH and establish tunnel
   2. Run TigerVNC and connect

Offboarding of Users

To revoke user access, run the del_cadence_user.sh script in the it_scripts repository on the corporate github account. The script will show you a list of existing users on the system. Type the name of the user you want to delete and confirm the prompts to delete that user. The script will then remove the VNC service for the user, delete their home directory, and then delete the user login as well. Thus, you must backup a copy of any important files in that user’s home directory that are to be retained after their departure. The former employee’s direct report should be given the retained files.

Directory Structures

ASIC Document Links

Document	Description
<path>/<ASIC Name>Design.docx	Design document for ASIC. This document contains all of the electrical characteristics. Block information. Simulation and test results for the <ASIC Name> design
<path>/<Project Name>_PRD.docx	Product requirement document. Technical specification document that the ASIC belongs to that contains preliminary information on how the <ASIC Name> is supposed to function and basic decisicion information on why the architecture was decided.
<path>/<ASIC Name>DesignReview.pptx	PowerPoint presentation used for internal/external team review of ASIC.
<path>/<Block Name 1>DesignReview.pptx	PowerPoint presentation used for internal/external team review of block.
<path>/<Block Name 2>DesignReview.pptx	PowerPoint presentation used for internal/external team review of block.

Sharepoint Directory Structure

<Group Name>                    # This is the SharePoint group that the Project directory belongs to.
└── <Project Name>              # Project the the ASIC belongs to.
    ├── <ASIC Name>             # Chip top level directory
    │   ├── doc                 # documents pertaining to desgn
    │   │   └── pic             # pictures that are contained in the documents in the doc directory
    │   ├── lay                 # eda tool schmatics/layout and  simulation views pertaining to design
    │   ├── <ASIC Database>     # top level layout contains complete IC gds database except for digital block implementation
    │   ├── <ASIC Database>_dig # cadence database for digital block implementation
    │   ├── KiCad               # models and schematics drawn in KiCad in order to communicate the design to other people 
    │   │   ├── <Project 1>     # KiCad project 
    │   │   ├── <Project 2>     # KiCad project 
    │   │   └── lib             # KiCad library specific to projects
    │   ├── vlog                # verilog synthesizable code and local testbenchs for designer
    │   │   ├── sva             # assertions
    │   │   ├── reg             # register block
    │   │   └── tb              # local testbench designer owned
    │   ├── verif               # verification directory for testbenches. Verification owns this area.
    │   │   ├── ams             # Analog mixed-signal simulation
    │   │   ├── env             # system verilog simulation enviorment setup. Block and variable definitions.
    │   │   ├── sim             # simulator setup files
    │   │   └── tests           # Define various tests to run
    │   └── spnr                # synthesis place and route scripts
    │       ├── ATPG            # automatic test pattern generation
    │       ├── IN              # input scripts for defining chip
    │       ├── LEC             # logic equivalence checking
    │       ├── OUT             # output files generated by synthesis and place and route. Verilog, gds, timing files
    │       ├── RPT             # synthesis place and route output reports
    │       ├── synthDb         # Automaticaly generated scripts for synthesis and place and route generated by genus
    │       └── timingReports   # timing reports for synthesis and place and route.
    ├── <ASIC2 Name>            # Chip top level directory
    ├── doc                     # documents pertaining to desgn
    │   └── pic                 # pictures that are contained in the documents in the doc directory
    └── KiCad                   # models and schematics drawn in KiCad in order to communicate the design to other people 
        ├── <project 1>         # KiCad project 
        ├── <project 2>         # KiCad project 
        └── lib                 # KiCad library specific to projects

Github Directory Structure

<ASIC Name>                     # Chip top level directory
├── doc                         # documents pertaining to desgn
│    └── pic                    # pictures that are contained in the documents in the doc directory
├── lay                         # eda tool schmatics/layout and  simulation views pertaining to design
├── <ASIC database>             # top level layout contains complete IC gds database except for digital block implementation
├── <ASIC database>_dig         # cadence database for digital block implementation
├── KiCad                       # models and schematics drawn in KiCad in order to communicate the design to other people 
│   ├── <project 1>             # KiCad project 
│   ├── <project 2>             # KiCad project 
│   └── lib                     # KiCad library specific to projects
├── vlog                        # verilog synthesizable code and local testbenchs for designer
│   ├── sva                     # assertions
│   ├── reg                     # register block
│   └── tb                      # local testbench designer owned
├── verif                       # verification directory for testbenches. Verification owns this area.
│   ├── ams                     # Analog mixed-signal simulation
│   ├── env                     # system verilog simulation enviorment setup. Block and variable definitions.
│   ├── sim                     # simulator setup files
│   └── tests                   # Define various tests to run
└── spnr                        # synthesis place and route scripts
    ├── ATPG                    # automatic test pattern generation
    ├── IN                      # input scripts for defining chip
    ├── LEC                     # logic equivalence checking
    ├── OUT                     # output files generated by synthesis and place and route. Verilog, gds, timing files
    ├── RPT                     # synthesis place and route output reports
    ├── synthDb                 # Automaticaly generated scripts for synthesis and place and route generated by genus
    └── timingReports           # timing reports for synthesis and place and route.
    
<ASIC2 Name>                    # Chip top level directory

<Project Name>                  # Project top level directory
├── <ASIC Name link>            # link to <ASIC Name> repository
├── <ASIC2 Name link>           # link to <ASIC2 Name> repository
├── doc                         # documents pertaining to desgn
│   └── pic                     # pictures that are contained in the documents in the doc directory
└── KiCad                       # pictures that are contained in the documents in the doc directory
    ├── <project 1>             # models and schematics drawn in KiCad in order to communicate the design to other people 
    ├── <project 1>             # KiCad project 
    └── lib                     # KiCad library specific to projects

Git Usage

Git Introduction

We use git for revision control. Basic Git commands are provided below. The git repositories are already set up, setup commands are omitted from this document. The main functionality you will use is staging changes and committing them. You will need to navigate to the working directory (P_ASIC, D_ASIC, etc.) to commit changes.

Stage & Snapshot

Git uses a staging area. Files that have been modified need to be added to the staging area and then committed. The most basic commands are provided below to do so. When you commit it saves a new snapshot of the repository.

Command	Description
git status	Shows modified files in working directory, files staged for next commit
git add [file]	Add a file as it is now to staging area
git rm [file] –cached	Unstage a file while retaining the changes in working directory
git reset HEAD [file]	Unstage a file while retaining the changes in working directory
git diff	Gives log of what is changed but not staged
git diff –staged	Diff of what is staged but not yet committed
git commit -m “[description]”	Commit your staged content as a new commit snapshot. Put a description of the commit (changes made). The -a option can be used to include all changed files so you don’t have to use git add for every file

Branch & Merge

Command	Description
git branch	List your branches (a * will be next to currently active branch)
git branch [branch-name]	Create a branch at the current commit
git checkout	Switch to another branch and check it out into your work directory
git merge [branch]	Merge the specified branch’s history into the current one
git log	Show all commits in the current branch’s history

Update/Syncing

A remote in Git is a version of the project hosted on a different server/machine. Origin is the default alias for the remote repository stored on Github. The local repository will need to be synced to this remote.

A push to the remote repository might be rejected if your local repository is out of date (there are updates on the remote that are not in local), then you will need to use git merge. Merge conflicts may need to be resolved, but because virtuoso creates lock files this should limit conflicts.

Command	Description
git remote add [alias] [url]	Add a Git URL as an alias
git remote	List remote repositories that are configured
git fetch [alias]	Fetch down all the branches from a Git remote
git merge [alias]/[branch]	Merge a remote branch into your current branch to bring it up to date
git push [alias] [branch]	Transmit local branch commits to the remote repository branch
git pull	Fetch and merge any commits from the tracking remote branch

Graphical Tools

Git has a number of graphical tools to help with pulling/staging/committing/pushing from the online repository. Two of the main tools are Git Cola and Git Dag. Both tools are located under the Programming tab in the Applications menu.

screenshot-1

Git Cola

This tool is used for pulling/staging/committing/pushing. After opening the tool.

Opening screen Git Cola

You now have the ability to Open, Clone, or create a new repository. The main usage would be to open an existing repository. Once you have opened a local repository it will show up in the list as a black folder.

Main screen Git Cola

• Once a repository is open Git Cola will then show the following screen.
• Files with a green triangle in front of them are files that have been staged and are ready to be committed.
• There is then the modified symbols. Git has detected that those files have changed since the last commit.
• A red circle with a line through it means that that file has been deleted
• Files that aren’t in the database are denoted with a “?” in front of them.

Staging files

Right click on the file that you want to stage and select Stage Selected. You can select multiple files to be staged by holding down the shift key to select multiple files in a row. You can add or subtract files from a selection by holding down the ctrl key.

Staging a file

Committing files

Committing a file adds the file to the local repository. Add a message about what the file is about and then hit commit. This will update or add all staged files to local repository.

Committing a file

Push files

Pushes the local repository to the cloud. Often it is a good idea to Pull before you push to make sure that you have the latest version of the repository.

Pushing and Pulling the database

Git DAG

This is a useful tool to examine a file in the repositories history. The first screen is the exact same as Git Cola. Once a repository is open the next screen has four sections. The upper left section contains all of the commits. If you click on a commit it will show the files that the commit affected in the bottom right screen. If you click on one of the files in the bottom right frame. The lower left frame will display a diff with the version of the file before if it is a text file. The upper right corner frame contains a graph representing the push/pull history of the repository and any branches.

Git DAG main screen

Github SSH Key

As a user new to Xenter you must make sure to set up an SSH key in your GitHub account in order to securely transfer files between the Xenter servers and GitHub servers. To do this you must have a GitHub account that is linked to XenterMD. IT can help you get this set up and, while doing so, can even help you set up your SSH key in GitHub. If they do not, then follow these steps to add your SSH key to your GitHub account.

1. Login to your GitHub account.

2. After signing in and authenticating click on the circle in the top-right corner with a downward- pointing triangle (see Figure 7) and select Your Organization.

   

   GitHub Options Icon

3. On the left side panel, under Access, select SSH and GPG keys (see Figure 8)

   

   Left side panel options

4. Select New SSH key in the green box (see Figure 11).

   

   New SSH key selection box

5. This will open up the following form (see Figure 12).

   

   New SSH key form

6. Open a terminal window in Linux and change directories to home/your_user_name/.SSH and list the contents of that directory. You should already have an SSH key there. If you do not have an SSH key (*.pub file) there, then skip to Step 11 for instructions on how to create an SSH key then come back to Step 7 to complete the process.

7. Use your preferred editor to open the file in the form of id_xxxxxxx_username.pub.

8. Copy the contents of the .pub file and paste them into the SSH key form as the key.

9. Enter a name for the key (Xenter SSH Key, for example).

10. Click the green Add SSH key selection box and you are all set.

11. If you do not have a *.pub file in your .SSH directory you can create a new SSH key yourself with this command:

    ssh-keygen -a 500 -t ed25519 -f ~/.ssh/id_john.doe_ed25519 -C "john.doe@xentermd.com"

12. This will start a dialog as follows:

    • Generating public/private rsa key pair.
    • Enter file in which to save the key (/home/username/.ssh/id_rsa):

13. Enter a name for the key (for example id_github).

14. The dialog will continue:

    • Enter passphrase (empty for no passphrase):

15. If you want this ssh key to be password protected, then enter a passphrase, otherwise just hit enter.

16. The dialog will then ask you to enter the same passphrase again. Enter the password you enters in Step 14 or just hit enter again if you did not create a passphrase.

17. You have created your new SSH key. The dialog will return with a randomart image. If you list the contents of the directory again you will find two new files: id_github and id_github.pub. You can now return to Steps 7 – 10 to complete the process of adding an your new key to your GitHub account.

Xenter Project Environment

Project Environment Introduction

This document defines the standardize project environments on Xenter’s Linux server. The intent is to improve collaboration and visibility of project development among users. Having a standardize directory structure allows for easier CAD support and future automated roll out of project directory creation.

Revision Control Using Git

Each users needs a github.com account and will be given access to https://github.com/XenterMD for revision control. See XenterGit.odt for git usage.

Project Directory Structure (Virtuoso)

There are shared main project directories and user project directories. Virtuoso creates lock files that prevents users from editing the same cells in the shared project areas. This avoid merge conflicts for git revision control. All work should be done in the /home/dev/[IC] directories using the OA database that was created for that chip. Right now the two IC’s that we are focused on are D-ASIC and P-ASIC. There are top level block OA libraries for these blocks that work should occur in.

/home/dev/
├── ARCHIVE
├── CAD
├── DA_ASIC             # Time multiplexed analog version of D-ASIC
├── DA-ASIC             # Pure analog version of the .018 guidewire
├── D-ASIC              # Current .018 guidewire sensor interface ASIC
├── downloads
├── DTV_Proto1
├── E_ASIC              # Possible collaboration with dolphin semiconductor for energy harvestor
├── IE_ASIC             # Built xfab energy harvestor ASIC
├── lib
├── lost+found
├── P-ASIC              # Built transceiver ASIC for use with .018 guidewire
├── SIM_DEBUG_DIGITAL
├── SmartICS            # Top level P-ASIC/D-ASIC project
├── TI_ASIC             # IVUS ASIC project
├── tools
├── TSMC
└── users

CAD Repository

Github repository: https://github.com/XenterMD/CAD.git

Main project path: /home/dev/CAD

The CAD repository contains the project definition files affecting multiple users.

The project cds.lib (proj.lib) defines locations for shared OA (OpenAccess) libraries.

The project bashrc (cadence.bashrc) will be sourced from each users .bashrc file. The project bashrc defines:

• Project environment variables
• CAD tool paths
• CAD script path
• License path

Chip Repository

Chip	Git URL
D-ASIC	https://github.com/XenterMD/D-ASIC.git
P-ASIC	https://github.com/XenterMD/P-ASIC.git
DA-ASIC	https://github.com/XenterMD/DA-ASIC.git
DA_ASIC	https://github.com/XenterMD/DA_ASIC.git
E_ASIC	https://github.com/XenterMD/E_ASIC.git
IE_ASIC	https://github.com/XenterMD/IE_ASIC.git
TI_ASIC	https://github.com/XenterMD/TI_ASIC.git

Each chip top level is in its own repository/directory. The contents includes shared OA libraries and documentation. Work that is related to tapeout (design, verification) needs to be in the chip repository.

User Work Area

Getting Started with D-ASI/D_ASIC/DA_ASIC, P-ASIC, and SmartICS Projects

Users create a work area under /home/dev/users/$USER. Note that by default /home/$USER is not visible by others so shared project related work should be avoided in user home directories.

The cds_oa directory is where users will launch Virtuoso and can create an OA scratch library. To create your user Virtuoso work area, open a new terminal and run:

c90nm_setup

This will create your user project directory and copy the project cds.lib.

Getting Started with IE_ASIC

Change to the IE_ASIC directory. Run the /home/dev/CAD/xt018/xt018nm script.

Getting Started with TI_ASIC

Change to the TI_ASIC directory. Run /home/dev/CAD/bin/tsmc13rf script.

Library Repository

Github repository: https://github.com/XenterMD/C9.git

Main project path: /home/dev/lib/C9

The library repository contains externally supplied project files including PDKs, standard cell libraries, IPs, etc.

SmartICS Repository

Github repository: https://github.com/XenterMD/SmartICS.git

Main project path: /home/dev/SmartICS

The SmartICS directory contains the top level assembled chip to be submitted for tapeout.

Layout

This describes the best practices for layout at Xenter.

DRC

To Run Calibre drc for C90 Skywater please use

cal_drc_c90 Libname cellname <options> Calibre drc options are -b = Base drc -l = latchup Rule -sf = Soft Rule -st = Stress Rule The script creates gds file in ./verification/gds drc results in ./verification/drc/<cellname>/<cellname>.db

LVS

To run Calibre lvs for C90 Sykwater tech please use

cal_lvs_c90 Libname cellname

Caliber lvs scripts creates Cdl netlist in ./verification/cdl/<cellname>.cdl gds file in ./verification/gds lvs results in ./verification/lvs/<cellname>

Naming Conventions

This section contains all of the naming conventions to use at Xenter.