Strange numbers in Virtuoso 6.1.5

Julian,

We had one customer report this to us a while ago, and they were using RHEL6 and they moved back to RHEL5 and the problem went away. I don't see the problem in RHEL6 myself though - so it's probably not as simple as that.  A couple of things that would be useful to know:

1. What OS distribution and version are you using?
2. What is the value of the $LANG variable (type "printenv LANG" in the terminal window)?

Thanks,

Andrew.

G'day Andrew,

 The OS is OpenSuse 11.4.

> printenv LANG
en_US.UTF-8
> uname -a
Linux nanosrv 2.6.37.1-1.2-desktop #1 SMP PREEMPT 2011-02-21 10:34:10 +0100 x86_64 x86_64 x86_64 GNU/Linux

Thanks,

Julian

Julian,

I did a bit more searching, and the majority of reported cases (there have only been a handful) have been on unsupported OS distributions (e.g Ubuntu and CentOS).

Your kernel version is a fair way ahead of even RHEL6.1 (which is supported for IC615).

We've been unable to reproduce the problem with any supported OS. Not sure why it would fail in this way though.

Can you try using a supported OS distribution and version (supported versions are shown on the Support & Training->Computing Platform Support at the top of the web page)?

Regards,

Andrew.

Andrew,

Your list indicates that SLES 11 is supported for IC 6.1.5. I am surprised that there are any significant differences between this and OpenSUSE 11.

I have no access to another machine to try alternate installations and several other users of this machine that are not affected by this problem.

Julian

Julian,

I wouldn't expect there to be massive differences either - but in the absence of other information and empirical evidence that moving to a supported OS fixed it, that's why I was making the suggestion.

However, your point that other users on the same machine are unaffected is interesting. Maybe there's something in your environment which gives a clue.

Can you post the output of "env" and also what "locale" shows?

Regards,

Andrew.

 G'day Andrew,

 The other users on the machine are affected by the same bug, they just are not using transistors that are small enough to cause problems. Calculated numbers above 1.2ps appear to be fine.

 Others are still using IC5141 with no problems.

More playing with the problem has me even more confused.

If I set an ADE varable to "1f" it displays as "1e155", but when I click on it to edit the value in the edit box is 1f again. Fortunalty this also netlists correctly.

If I choose to override the drain diffusion area it allows me to replace "480e155" with "480f", which I beleive to be correct. This also netlists correclty - just means that I must update the drain diffusion every time I adjust the width. This is 500.9 - 500.1 keeps the "480e155" even if I type "480f".

Julian

 > env
LESSKEY=/etc/lesskey.bin
NNTPSERVER=news
MANPATH=/usr/local/man:/usr/share/man
HOSTNAME=nanosrv
XKEYSYMDB=/usr/X11R6/lib/X11/XKeysymDB
HOST=nanosrv
TERM=xterm
SHELL=/bin/bash
PROFILEREAD=true
HISTSIZE=1000
SSH_CLIENT=10.1.3.101 51325 22
MORE=-sl
OLDPWD=/data/SIL180/julian
SSH_TTY=/dev/pts/47
CDK_DIR=/data/ON06/PDK/NCSU_PDK/
JRE_HOME=/usr/lib64/jvm/jre
USER=julian
LS_COLORS=no=00:fi=00:di=01;34:ln=00;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=41;33;01:ex=00;32:*.cmd=00;32:*.exe=01;32:*.com=01;32:*.bat=01;32:*.btm=01;32:*.dll=01;32:*.tar=00;31:*.tbz=00;31:*.tgz=00;31:*.rpm=00;31:*.deb=00;31:*.arj=00;31:*.taz=00;31:*.lzh=00;31:*.lzma=00;31:*.zip=00;31:*.zoo=00;31:*.z=00;31:*.Z=00;31:*.gz=00;31:*.bz2=00;31:*.tb2=00;31:*.tz2=00;31:*.tbz2=00;31:*.xz=00;31:*.avi=01;35:*.bmp=01;35:*.fli=01;35:*.gif=01;35:*.jpg=01;35:*.jpeg=01;35:*.mng=01;35:*.mov=01;35:*.mpg=01;35:*.pcx=01;35:*.pbm=01;35:*.pgm=01;35:*.png=01;35:*.ppm=01;35:*.tga=01;35:*.tif=01;35:*.xbm=01;35:*.xpm=01;35:*.dl=01;35:*.gl=01;35:*.wmv=01;35:*.aiff=00;32:*.au=00;32:*.mid=00;32:*.mp3=00;32:*.ogg=00;32:*.voc=00;32:*.wav=00;32:
XNLSPATH=/usr/share/X11/nls
HOSTTYPE=x86_64
FROM_HEADER=
PAGER=less
CSHEDIT=emacs
XDG_CONFIG_DIRS=/etc/xdg
MINICOM=-c on
MAIL=/var/mail/julian
PATH=/home/julian/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/usr/lib64/jvm/jre/bin:/usr/lib/mit/bin:.:/usr/local/mentor/ixl_cal_2011.1_24.16/bin:/usr/local/cadence/MMSIM101/tools/bin/:/usr/local/cadence/INCISIV102/bin:/usr/local/cadence/INCISIV102/tools/bin:/usr/local/cadence/AUSSURA6/tools/bin/:/usr/local/cadence/AUSSURA6/tools/assura/bin:/usr/local/cadence/IC615/tools/bin/:/usr/local/cadence/IC615/bin/
CPU=x86_64
JAVA_BINDIR=/usr/lib64/jvm/jre/bin
SSH_SENDS_LOCALE=yes
INPUTRC=/home/julian/.inputrc
PWD=/data/SIL180/PDK/m6_mim4f_builtin
JAVA_HOME=/usr/lib64/jvm/jre
EDITOR=xterm -e /usr/bin/joe
LANG=en_US.UTF-8
PYTHONSTARTUP=/etc/pythonstart
CDS_Netlisting_Mode=Analog
LM_LICENSE_FILE=5280@cad4.ee.unsw.edu.au:1717@cad4.ee.unsw.edu.au
PRE_PATH=/home/julian/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/usr/lib64/jvm/jre/bin:/usr/lib/mit/bin:.
GPG_TTY=/dev/pts/47
TECHDIR=/data/GF65/PDK/chrt65lpe/Calibre/
QT_SYSTEM_DIR=/usr/share/desktop-data
SHLVL=1
HOME=/home/julian
SDL_AUDIODRIVER=pulse
ALSA_CONFIG_PATH=/etc/alsa-pulse.conf
LESS_ADVANCED_PREPROCESSOR=no
OSTYPE=linux
MGC_HOME=/usr/local/mentor/ixl_cal_2011.1_24.16
LS_OPTIONS=-N --color=tty -T 0
WINDOWMANAGER=/usr/bin/startkde
G_FILENAME_ENCODING=@locale,UTF-8,ISO-8859-15,CP1252
LESS=-M -I -R
MACHTYPE=x86_64-suse-linux
LOGNAME=julian
XDG_DATA_DIRS=/usr/share
SSH_CONNECTION=10.1.3.101 51325 10.10.1.10 22
SOCV_KIT_HOME=/usr/local/cadence/INCISIV102
LESSOPEN=lessopen.sh %s
DISPLAY=localhost:11.0
XAUTHLOCALHOSTNAME=nanosrv
LESSCLOSE=lessclose.sh %s %s
ASSURAHOME=/usr/local/cadence/AUSSURA6
INCISIVE=/usr/local/cadence/INCISIV102
G_BROKEN_FILENAMES=1
JAVA_ROOT=/usr/lib64/jvm/jre
COLORTERM=1
mc=() {  . /usr/share/mc/mc-wrapper.sh
}
_=/usr/bin/env

> locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

The problem appears to be in the function aelSuffixNotation - and I think what happens is that it displays various values after passing through that function. However, the value is probably being stored exactly as you entered it.

Looking at your environment, and based on what you say, it almost certainly is an OS problem (maybe a problem with one of the shared libraries - it's hard to tell).

Can you try using:

export LANG=C

before starting virtuoso (I think you're using bash not csh) - does that help?

Can you also try in the CIW:

aelSuffixNotation(1e-12)
aelEngNotation(1e-12)
sprintf(nil "%1.4e" 1e-12)

and post what these output?

Regards,

Andrew.

No change in behaviour after "export LANG=C"

aelSuffixNotation(1e-12)
"1e122"
aelEngNotation(1e-12)
"1e122"
sprintf(nil "%1.4e" 1e-12)
"1.0000e-12"
sprintf(nil "%1.4e" 1p)
"1.0000e-12"
aelSuffixNotation(1.2e-15)
"1.2f"
aelSuffixNotation(1.2e-12)
"1.2p"
aelSuffixNotation(480f)
"480e155"
aelSuffixNotation(480.1f)
"480.1e515"
aelSuffixNotation(480.1e-15)
"480.1e515"

Julian

Julian,

After writing some C code (replicating what's going on in the tools) and some experimentation, I now see the same problem when I'm running on my RHEL6.1 machine, and running virtuoso in 64 bit mode. It doesn't happen for me in 32 bit mode. Perhaps you can try running "virtuoso -32" to see if that helps? The same behaviour is true for my little C program; compiled in 32 bit mode, it works fine, but compiled in 64 bit mode I see the problem.

I believe I understand the root cause in the code as to why this is happening (and I have an alternative implementation which seems to fix it), so I will file a CCR to get this fixed. I'll post the CCR number once I've done that.

Regards,

Andrew.

Julian,

The CCR number is 995099. You might want to contact customer support and get a duplicate filed so that you can track when the fix is available on Cadence Online Support.

Regards,

Andrew.