Mutation of function input parameter

Hi Dragan,

There's not really enough to go on here. My first thought was that there's a built-in function called which but that shouldn't cause a problem here; in SKILL mode variables can match function names, and in SKILL++ using a variable called which would simply mask the function.

Another possibility is that one of the functions you're calling - findCornersByValues or listsIntersection is setting a variable which internally without having declared it in a let. Because of dynamic scoping this can easily happen - for example if you do:

defun(MyLowerFunction (a b)
  prod=a*b
  diff=a-b
  prod+diff
)

defun(MyUpperFunction (diff)
  let((prod result)
    prod=diff*diff
    printf("prod=%L diff=%L\n" prod diff)
    result=MyLowerFunction(diff 3)
    printf("prod=%L diff=%L result=%L\n" prod diff result)
  )
)

If you then call MyUpperFunction(4) it will output:

prod=16 diff=4
prod=12 diff=1 result=13

The prod and diff assignments inside MyLowerFunction are altering the current dynamically scoped variables - essentially those local to MyUpperFunction (diff is local because its an argument, and prod is in the let). If MyLowerFunction had been called elsewhere, diff and prod may have ended up as global variables. Essentially with dynamic scoping each variable is like a stack - with the latest argument list or let putting a new placeholder for the value on a stack, and that is popped off when the scope ends.

Of course, I'm completely guessing here because I can't see the entire code. However, given that your patchForLoadCornerNames function is failing to declare many local variables (cornerNames0, which0, values0, sameWhich, crnrNms, lI are all missing from the let), it's a distinct possibility that you're calling a downstream function that doesn't declare everything it should.

Also, I'd say that it's bad practice to have your functions without prefixes - they could easily clash with those of another application which uses similar names. We suggest using an upper case prefix since Cadence doesn't use those. That's not going to be the problem here - I just thought I'd mention it.

You might want to run your code through SKILL Lint in the SKILL Development Environment as it would catch these accidental global variables. Intentional global variables should also use a prefix - it will flag that though.

However, as I said, all of this might be nothing to do with the problem; I don't know what the variable is changing from and to, and I don't have all the code. So you'd need to either provide the complete code and data to demonstrate the problem, or do that via customer support.

Regards,

Andrew

Hi Dragan,

There's not really enough to go on here. My first thought was that there's a built-in function called which but that shouldn't cause a problem here; in SKILL mode variables can match function names, and in SKILL++ using a variable called which would simply mask the function.

Another possibility is that one of the functions you're calling - findCornersByValues or listsIntersection is setting a variable which internally without having declared it in a let. Because of dynamic scoping this can easily happen - for example if you do:

defun(MyLowerFunction (a b)
  prod=a*b
  diff=a-b
  prod+diff
)

defun(MyUpperFunction (diff)
  let((prod result)
    prod=diff*diff
    printf("prod=%L diff=%L\n" prod diff)
    result=MyLowerFunction(diff 3)
    printf("prod=%L diff=%L result=%L\n" prod diff result)
  )
)

If you then call MyUpperFunction(4) it will output:

prod=16 diff=4
prod=12 diff=1 result=13

The prod and diff assignments inside MyLowerFunction are altering the current dynamically scoped variables - essentially those local to MyUpperFunction (diff is local because its an argument, and prod is in the let). If MyLowerFunction had been called elsewhere, diff and prod may have ended up as global variables. Essentially with dynamic scoping each variable is like a stack - with the latest argument list or let putting a new placeholder for the value on a stack, and that is popped off when the scope ends.

Of course, I'm completely guessing here because I can't see the entire code. However, given that your patchForLoadCornerNames function is failing to declare many local variables (cornerNames0, which0, values0, sameWhich, crnrNms, lI are all missing from the let), it's a distinct possibility that you're calling a downstream function that doesn't declare everything it should.

Also, I'd say that it's bad practice to have your functions without prefixes - they could easily clash with those of another application which uses similar names. We suggest using an upper case prefix since Cadence doesn't use those. That's not going to be the problem here - I just thought I'd mention it.

You might want to run your code through SKILL Lint in the SKILL Development Environment as it would catch these accidental global variables. Intentional global variables should also use a prefix - it will flag that though.

However, as I said, all of this might be nothing to do with the problem; I don't know what the variable is changing from and to, and I don't have all the code. So you'd need to either provide the complete code and data to demonstrate the problem, or do that via customer support.

Regards,

Andrew