ADE Assembler: variable values with leading zeros interpreted as octal in ICADVM20.1

Dear dontpanic,

dontpanic said:

We recently switched to ICADVM20.1 and started to get weird results in many old testbenches. After a close lookup, it turns out that all the variables with values starting with zero ("0") are being interpreted as octal!

Yes. It appears this is a known issue as detailed in the On-line support article:

Virtuoso Known Problems and Solutions
Product Version ICADVM20.1, March 2021

at URL:

support.cadence.com/.../techpubDocViewerPage

which includes the following:

Problem: Entering leading zeroes in numeric fields results in octal interpretation

Description: If a number is immediately preceded by a zero, SKILL interprets this as an octal number.

Solution: Use the Backspace key to delete the zero before you type a new number.

I don't think the suggested "Solution"  is to your liking though! I am not privy to any potential date for correcting the behavior nor a release in which the known issue will be corrected - sorry!

Shawn

The manual that Shawn mentions isn't strictly speaking related to this issue - it's a general point that numeric fields on forms in Virtuoso will interpret integers as SKILL does, where leading zeros indicate octal. This is not new, and there's nothing that's going to be fixed. In this case, we're talking about global variables in ADE, and the field for these isn't a numeric field, so that manual isn't really relevant here (even though the symptoms are similar).

The problem in this case is that global variables in ADE Explorer/Assembler (and indeed ADE XL) are first evaluated in SKILL to allow complex functions to be used, before passing to the simulator anything else. There have been some changes to this flow recently to try to preserve parameters within such expressions so that they can be swept within an analysis in Spectre, but it's not that change that causes this problem. I checked, and expressions with numbers starting with 0 in global variables have always been treated as octal since IC617 was first released with Assembler (that's when Assembler was first released). I suspect it goes back even further with ADE XL (I did not check that). So this is not new, and I am surprised that you have existing test benches that weren't broken before (maybe they were run in ADE L before? ADE L didn't evaluate any design variables in SKILL and passed the expressions through to the simulator, so that could well be a difference).

I haven't spotted any reports of this being an issue with anybody else (and I can understand why it's a pain), but I can't see any plan to alter this behaviour (it would be quite hard). Potentially I can imagine some SKILL code to fix these automatically would be possible...

Andrew

The manual that Shawn mentions isn't strictly speaking related to this issue - it's a general point that numeric fields on forms in Virtuoso will interpret integers as SKILL does, where leading zeros indicate octal. This is not new, and there's nothing that's going to be fixed. In this case, we're talking about global variables in ADE, and the field for these isn't a numeric field, so that manual isn't really relevant here (even though the symptoms are similar).

The problem in this case is that global variables in ADE Explorer/Assembler (and indeed ADE XL) are first evaluated in SKILL to allow complex functions to be used, before passing to the simulator anything else. There have been some changes to this flow recently to try to preserve parameters within such expressions so that they can be swept within an analysis in Spectre, but it's not that change that causes this problem. I checked, and expressions with numbers starting with 0 in global variables have always been treated as octal since IC617 was first released with Assembler (that's when Assembler was first released). I suspect it goes back even further with ADE XL (I did not check that). So this is not new, and I am surprised that you have existing test benches that weren't broken before (maybe they were run in ADE L before? ADE L didn't evaluate any design variables in SKILL and passed the expressions through to the simulator, so that could well be a difference).

I haven't spotted any reports of this being an issue with anybody else (and I can understand why it's a pain), but I can't see any plan to alter this behaviour (it would be quite hard). Potentially I can imagine some SKILL code to fix these automatically would be possible...

Andrew

I remember a similar issue where the ternary operator worked in ADE L, but did not work in ADE XL, Explorer or Assembler. This was fixed eventually, see support.cadence.com/.../ArticleAttachmentPortal