I have encountered a strange issue. We have some skill code that processes some simulation data and gives the user a form with a list of devices. The user can select to go to the device, this is done in the background using skill - going down in hierarchy, finding selecting and zooming to the device. The descent is done with geSwitch.
Now the user wants to use calculator to do some calculations at the schematic level of the device. Usually a function is selected - let's say vt - and the schematic is brought into focus so the user can select a net. But there is some sort of trigger on the calculator that, for some reason, it not only brings the schematic into focus but it goes back to top.
On the other hand, if I descend manually through the schematic, when I select vt it keeps the hierarchy level. So as far as I can tell, geSwitch does something different than manually descending in schematic which confuses the calculator. I believe the calculator thinks it needs to go to the cell view it was started from, but this does not happen for manual descent.
First question is is this how calculator works in this situation? I could be some custom trigger I am not aware of...
Second of all is there something that can be done to prevent this, maybe something else than geSwitch or something added to the code to keep the hierarchy level when calculator function is selected?
I hope I explained the issue sufficiently, it is rather difficult to put in words. Thank you.
Which IC subversion are you using (Help->About will tell you)? Also, which ADE flavour (ADE L, XL, Explorer, Assembler) are you using?
I just tried this in ADE Explorer and when I first launched the calculator having descended (using the normal descend command) it did reopen the design at the top level (in another tab). However, from that point onwards, if I descend using geSwitch or the descend read command, it doesn't pop to the top. My initial thought was to suggest using dePush instead of geSwitch, but since geSwitch calls dePush inside, I doubt that will make a difference.
So from my observation of this (using IC617 ISR22), other than the initial press of "vt" in the calculator, it doesn't pop to the top - and when it does pop to the top, it does that regardless of how you've descended.
Assuming you're using a current version of the tools, this might be best handled through customer support so that we can see your code and if there's something wrong (with Explorer or Assembler - we're not going to fix ADE L or XL if the issue only occurs there), we can file a change request with R&D to get it fixed. Or maybe we can suggest how to change your code to make it behave properly.
Thanks for the answer. Sadly for me I am debugging some code I did not write and as such it takes me time. My test was IC617 ISR14.
I tried clicking the vt in calculator when on top and looking closely at the window it still seems to do something, so I assume the calculator reopens the cell view or something like that irrespective of the level, maybe it is a setting in it somewhere.
When searching for a hierarchy instance, the skill code went back to the top and started down again, and to go to the top it simply used geChangeCellView on the top lib/cell/view which it had stored. So when going down again and pressing vt, the calculator would go right back to top, so I assume the calculator did not like the geChangeCellView and did it again itself in the background. Going to the top other ways (using schHiReturnToTop or geReturn) yields other issues with the code that goes down / finds instance / selects instance (it reaches the hierarchy level but geSelectObject no longer works for some reason). I will probably live with the calculator not working properly rather than try to debug/change to much old code.