2 function bindkey unfuctional in IC5141?

[Erik Wanta]

The following works in IC5033 but not in IC5141:
hiSetBindKey("Layout" "<Key>5" "leSetEnv(\"orientation\" \"MX\")
leHiMove()")

In IC5141 it just does the leHiMove(). Any ideas why it is not
changing the orientation in IC5141?
---
Erik

 

[Erik Wanta]

Looks like leSetEnv is being discontinued. The following didn't seem
to work however:
hiSetBindKey("Layout" "<Key>5" "envSetVal(\"layout\" \"orientation\"
'cyclic \"MX\") leHiMove()")

Any ideas why envSetVal("layout" "orientation" 'cyclic "MX") isn't
working?

Note: There are a number of environment variables that are no longer
compatible with leSetEnv and leGetEnv. The setting methods for the
environment variables are noted in this Appendix under the heading
Setting Method, which is included with the description of each
environment variable. Cadence recommends that you use only envSetVal
and envGetVal to determine the setting of, set, or reset environment
variables.
---
Erik

erikwanta@starband.net (Erik Wanta) wrote in message news:<84018314.0409020211.e5e86d9@posting.google.com>...

The following works in IC5033 but not in IC5141:
hiSetBindKey("Layout" "<Key>5" "leSetEnv(\"orientation\" \"MX\")
leHiMove()")

In IC5141 it just does the leHiMove(). Any ideas why it is not
changing the orientation in IC5141?
---
Erik

 

[Andrew Beckett]

leSetEnv is not being discontinued as far as I know. It's still used quite
extensively in the code.

It should keep the env vars in sync with the envSetVal() settings anyway, so it
shouldn't really make any difference.

Where did that Cadence recommendation come from? Is that in the docs somewhere,
or was it something an AE told you?

(I'll do some experimentation with this orientation issue when I can get in
front of a workstation, or boot my laptop up in Linux).

Regards,

Andrew.

On 2 Sep 2004 08:18:21 -0700, erikwanta@starband.net (Erik Wanta) wrote:

Looks like leSetEnv is being discontinued. The following didn't seem
to work however:
hiSetBindKey("Layout" "<Key>5" "envSetVal(\"layout\" \"orientation\"
'cyclic \"MX\") leHiMove()")

Any ideas why envSetVal("layout" "orientation" 'cyclic "MX") isn't
working?

Note: There are a number of environment variables that are no longer
compatible with leSetEnv and leGetEnv. The setting methods for the
environment variables are noted in this Appendix under the heading
Setting Method, which is included with the description of each
environment variable. Cadence recommends that you use only envSetVal
and envGetVal to determine the setting of, set, or reset environment
variables.
---
Erik

erikwanta@starband.net (Erik Wanta) wrote in message news:<84018314.0409020211.e5e86d9@posting.google.com>...
The following works in IC5033 but not in IC5141:
hiSetBindKey("Layout" "<Key>5" "leSetEnv(\"orientation\" \"MX\")
leHiMove()")

In IC5141 it just does the leHiMove(). Any ideas why it is not
changing the orientation in IC5141?
---
Erik

--
Andrew Beckett
Senior Technical Leader
Custom IC Solutions
Cadence Design Systems Ltd

 

[Erik Wanta]

Andrew:
The following note was found on sourcelink:

Note: There are a number of environment variables that are no longer
compatible with leSetEnv and leGetEnv. The setting methods for the
environment variables are noted in this Appendix under the heading
Setting Method, which is included with the description of each
environment variable. Cadence recommends that you use only envSetVal
and envGetVal to determine the setting of, set, or reset environment
variables.

Is there a difference between envSetVal and leSetEnv? Note that the
"setting method" for orientation is envSetVal. What is the expected
behavior after setting:
envSetVal("layout" "orientation" 'cyclic "MX")

Is it that it will give a new instance MX orientation to start with?

In the earlier IC5033 versions the bindkey I mentioned in my original
post worked. That is when I used the bindkey it would change the
rotation and move the instance.

I was thinking that maybe I could get around this in IC5141 by doing a
car(geGetSelSet())~>orient~>"MX" or something but I don't have access
to Cadence right now to test.
---
Erik

Andrew Beckett <andrewb@DELETETHISBITcadence.com> wrote in message news:<3cnfj01h5pn8or9p9v0sl6odk42d5j0dtr@4ax.com>...

leSetEnv is not being discontinued as far as I know. It's still used quite
extensively in the code.

It should keep the env vars in sync with the envSetVal() settings anyway, so it
shouldn't really make any difference.

Where did that Cadence recommendation come from? Is that in the docs somewhere,
or was it something an AE told you?

(I'll do some experimentation with this orientation issue when I can get in
front of a workstation, or boot my laptop up in Linux).

Regards,

Andrew.

On 2 Sep 2004 08:18:21 -0700, erikwanta@starband.net (Erik Wanta) wrote:

Looks like leSetEnv is being discontinued. The following didn't seem
to work however:
hiSetBindKey("Layout" "<Key>5" "envSetVal(\"layout\" \"orientation\"
'cyclic \"MX\") leHiMove()")

Any ideas why envSetVal("layout" "orientation" 'cyclic "MX") isn't
working?

Note: There are a number of environment variables that are no longer
compatible with leSetEnv and leGetEnv. The setting methods for the
environment variables are noted in this Appendix under the heading
Setting Method, which is included with the description of each
environment variable. Cadence recommends that you use only envSetVal
and envGetVal to determine the setting of, set, or reset environment
variables.
---
Erik

erikwanta@starband.net (Erik Wanta) wrote in message news:<84018314.0409020211.e5e86d9@posting.google.com>...
The following works in IC5033 but not in IC5141:
hiSetBindKey("Layout" "<Key>5" "leSetEnv(\"orientation\" \"MX\")
leHiMove()")

In IC5141 it just does the leHiMove(). Any ideas why it is not
changing the orientation in IC5141?
---
Erik

 

[Andrew Beckett]

Hi Erik,

I did some experiments, and found that the behaviour changed in IC5033 USR2 and
IC5141. It now always resets to R0 within the move function.

It's nothing to do with differences between leSetEnv and envSetVal. In fact,
there should be no usage differences between using these two functions (the
environments should always stay in sync; both exist for historical reasons -
primarily that leSetEnv existed before the common environment capability that
was added many releases back).

Anyway, a bit of research showed that the behaviour changed as a result of

PCR: 658273
Title: Set environment var orientation to R0 in first creation.

This was considered a bug by the customer in that case (with good reason - it
was rather inconsistent in its behaviour - setting the environment variable only
affected the first command, and was reset for subsequent commands). It was
changed to always reset each time - the point is that this environment variable
is used as an action rather than a state, and is used to communicate internally
between different parts of the tool.

However, it seems that your usage wasn't taken into account - effectively you
were taking advantage of this "bug" (not perceived as a bug by you).

So the following PCR was filed (for another customer originally, but also linked
to from an SR from one of your colleagues):

PCR: 726455
Title: leHiMove/leSetEnv function

This is fixed in IC5033 USR3, and I believe IC5141 USR1. The fix is to have
another env setting:

layout resetOrientation boolean t

(the default is above) - you can set it to nil if you don't want it to reset the
orientation in the move command, but pick up the orientation env var
directly.

Regards,

Andrew.

--
Andrew Beckett
Senior Technical Leader
Custom IC Solutions
Cadence Design Systems Ltd

 

[Erik Wanta]

Andrew:
Thank you for the additional information!

I am a little confused however. I would expect that if I set the
layout orientation variable that it would use the orientation that I
set for all future operations. If it resets it immediately then when
does it use the orientation I set?
---
Erik

Andrew Beckett <andrewb@DELETETHISBITcadence.com> wrote in message news:<fg60k0l9753qt4o8dk0mmtrmdgj13tn5gu@4ax.com>...

Hi Erik,

I did some experiments, and found that the behaviour changed in IC5033 USR2 and
IC5141. It now always resets to R0 within the move function.

It's nothing to do with differences between leSetEnv and envSetVal. In fact,
there should be no usage differences between using these two functions (the
environments should always stay in sync; both exist for historical reasons -
primarily that leSetEnv existed before the common environment capability that
was added many releases back).

Anyway, a bit of research showed that the behaviour changed as a result of

PCR: 658273
Title: Set environment var orientation to R0 in first creation.

This was considered a bug by the customer in that case (with good reason - it
was rather inconsistent in its behaviour - setting the environment variable only
affected the first command, and was reset for subsequent commands). It was
changed to always reset each time - the point is that this environment variable
is used as an action rather than a state, and is used to communicate internally
between different parts of the tool.

However, it seems that your usage wasn't taken into account - effectively you
were taking advantage of this "bug" (not perceived as a bug by you).

So the following PCR was filed (for another customer originally, but also linked
to from an SR from one of your colleagues):

PCR: 726455
Title: leHiMove/leSetEnv function

This is fixed in IC5033 USR3, and I believe IC5141 USR1. The fix is to have
another env setting:

layout resetOrientation boolean t

(the default is above) - you can set it to nil if you don't want it to reset the
orientation in the move command, but pick up the orientation env var
directly.

Regards,

Andrew.

 

[Andrew Beckett]

Hi Erik,

Really the env var was not intended for public use - but was made
public some time ago without it being thought through properly.
As a result, this use of it as a communication mechanism between
commands was not made consistent with use model you have for it. I'm
sure it could have been implemented a better way which satisfies
everyone, but at least there's a fix for now.

Andrew.


On 12 Sep 2004 02:46:51 -0700, erikwanta@starband.net (Erik Wanta)
wrote:

Andrew:
Thank you for the additional information!

I am a little confused however. I would expect that if I set the
layout orientation variable that it would use the orientation that I
set for all future operations. If it resets it immediately then when
does it use the orientation I set?
---
Erik

Andrew Beckett <andrewb@DELETETHISBITcadence.com> wrote in message news:<fg60k0l9753qt4o8dk0mmtrmdgj13tn5gu@4ax.com>...
Hi Erik,

I did some experiments, and found that the behaviour changed in IC5033 USR2 and
IC5141. It now always resets to R0 within the move function.

It's nothing to do with differences between leSetEnv and envSetVal. In fact,
there should be no usage differences between using these two functions (the
environments should always stay in sync; both exist for historical reasons -
primarily that leSetEnv existed before the common environment capability that
was added many releases back).

Anyway, a bit of research showed that the behaviour changed as a result of

PCR: 658273
Title: Set environment var orientation to R0 in first creation.

This was considered a bug by the customer in that case (with good reason - it
was rather inconsistent in its behaviour - setting the environment variable only
affected the first command, and was reset for subsequent commands). It was
changed to always reset each time - the point is that this environment variable
is used as an action rather than a state, and is used to communicate internally
between different parts of the tool.

However, it seems that your usage wasn't taken into account - effectively you
were taking advantage of this "bug" (not perceived as a bug by you).

So the following PCR was filed (for another customer originally, but also linked
to from an SR from one of your colleagues):

PCR: 726455
Title: leHiMove/leSetEnv function

This is fixed in IC5033 USR3, and I believe IC5141 USR1. The fix is to have
another env setting:

layout resetOrientation boolean t

(the default is above) - you can set it to nil if you don't want it to reset the
orientation in the move command, but pick up the orientation env var
directly.

Regards,

Andrew.