The TransistoriZed logo should be here! But... curses! Your browser does not support SVG!

homelist of postsdocsγ ~> e-about & FAQ


Running Cadence / Mentor on new kernels

Both Cadence's Virtuoso and Mentor's Architect and Calibre family of tools require old linux infrastructure. The supported as of 2016 is usually RHEL 5 or 6. The problem is, I don't want to run RHEL at home, as it acts as a time-machine flying me 10 years into the past. It's a pain, although, a quite stable one.

Here's some quick insturctions on how you can prevent the following error messages and launch Virtuoso or Calibre on newer systems.

"Invalid Linux major version"

WARNING: HOST gyrator DOES NOT APPEAR TO BE A CADENCE SUPPORTED LINUX CONFIGURATION.

The strategy for this fix is very simple, but yet I am including it here as I've been asked by my group for help about this way too often now. Both design environments, when launched, use bash scripts to identify the running environment and invoke their corresponding binary executables.

In the case with Mentor's Calibre tools, the preloaded skill in Virtuoso looks for and invokes: "./pkgs/calibre_base.aoi/bin/calibre_vco". The latter executes some checks on the OS before launching Calibre's aoi executable. We look for the following if statement and hence, modify the case conditions.

... 
  if test -r /etc/redhat-release
  then
    major_rev=`grep release /etc/redhat-release 2>/dev/null \
                 | sed -e 's/.*release *//' \
                 | sed -e 's/\..*//' \
                 | sed -e 's/ .*//'`
    case "$major_rev" in
      5)     echo ixl ;;
      [6-9]) echo aoi ;;
      *)
         echo "ERROR: Invalid Linux major version '$major_rev'" >&2
         echo
         exit 1
         ;;
      esac
.
.
.... and so on

You can also remove the exit flags, or even forge the whole if branch (althoug I would not recommend it).

The same procedure applies to Virtuoso. You start by locating the staring korn shell with e.g. "which virtuoso", then you will find out that the script invokes something like "{ROOT_DIR}/share/bin/.cdnWrapper_core". Then by looking at the wrapper, you will find out that it looks for the "${oabindir}/sysname" script. By opening the last you find out that it performs some checks using stadard shell commands (uname -a).

Then you look for the following if branches:

...
    case $machine in
        ia64 )
          sysname="linux_rhas21_ia64$compiler"; sysnames="$sysname $sysnames";;
        *86 | *86_64 )
            case $version in
                2.4.* )
                  compiler="_gcc411"
                  sysname="linux_rhel30$compiler"; sysnames="$sysname $sysnames";;
                2.6.[0-9]-* )
                  compiler="_gcc44x"
                  sysname="linux_rhel40$compiler"; sysnames="$sysname $sysnames";;
                2.6.* | 4.1.*)
                  compiler="_gcc44x"
                  sysname="linux_rhel50$compiler"; sysnames="$sysname linux_rhel40$compiler $sysnames";;
                * )
                  check_global;;
            esac;;
... and so on ...

And here you can modify the conditions to the wanted kernel. In my case, just adding an additional OR | operator with my OS's kernel does the job.

The same applies for PVS, Spectre and the whole family of tools. I should warn however that using such CAD tools with an unsupported platform may lead to unexpexted results. In my case, I have noticed that such a new kernel, negatively affects the stability when performing SPICE simulations with Spectre/Ultrasim. Getting fake SPICE results without any error messages is the least that you want from a circuit simulator.

Date:Sun Mar 29 18:45:21 CET 2016

Comments

No comments yet
*Name:
Email:
Notify me about new comments on this page
Hide my email
*Text: