Annotations are just way too overpowering

Thanks for that - I'll certainly look into the documentation. So the bottom line is that this is working and I'm very happy and thankful to you for your help. However, I'm also having a couple teething problems but am feeling super guilty about taking up any more of your time. Given that I have a workable solution, I won't take any offense if you politely tell me to get lost (citing relationships between camels, inches and miles). That being said...

1. The following works, great but has an annoying side effect. I'm displaying the back-annotations in cell symbol but they annoyingly keep disappearing when I do things like check and save. They all come back after a redraw so it's more an annoyance than anything else. Here are some more details - the cell contains the following CDF parameters:

instName        to point to the desired instance
numDigits       for the displayed precision
Aspect1          e.g. gm, vdsat, vth etc.
Aspect2         (I have 5 of these altogether)

The cell symbol contains 5 ilLabels containing the text "myAbsAspect(1)", "myAbsAspect(2)" etc. The function myAbsAspect() is:

procedure(myAbsAspect(index)
let( ((inst_name ilInst~>instName) (inst_aspect evalstring(strcat("ilInst~>Aspect" sprintf(nil "%d" index)))) (num_digits ilInst~>numDigits) )
; abs() can't handle nil do the following
myAbsAspect = OP(strcat(geGetInstHier() "/" inst_name) inst_aspect)
if(myAbsAspect then aelSuffixNotation(abs(myAbsAspect) num_digits) else "")
)
)

After I run a sim to completion the ilLabels all display as nil (which is disappointing) but if I do a redraw everything populates with the proper back-annotations and it all looks great. The next disappointing thing is that every time I do a check and save all of the ilLabels become empty (not nil, but "") and again I have to do a redraw to make them all visible again. Any idea what's causing that?

2. When I run a sim I see many of these in the CIW:

*WARNING* (GE-2067): geGetInstHier: There is no graphical edit environment assigned to window(3) because the window is not a graphic editor window.
Make sure that your current window is a valid graphic editor window.
If it is a valid graph editor window, contact customer service to investigate this issue.

I'm actually on vacation this week, so I'm not going to be able to investigate further this week (I happened to be checking my email, which I probably shouldn't be doing, which is why I saw this!).

I'll try to find a little time to do this next week. To be honest, I think the cdsParam stuff has had quite a bit of tuning over the years to avoid problems with info not being available at certain times, so it might be a bit rash to directly use OP and geGetInstHier. I can imagine that the geGetInstHier problem is probably because the schematic window isn't the current window and the schematic is redrawn nevertheless. It probably should be passed the window id of the window being redrawn, but I'm not sure that's available. So maybe my idea wasn't so great...

Andrew.

Thanks for the comments, but I just wanted to set the record straight - I thought your OP() idea was awesome because it lets me annotate exactly what I want and where I want it. While the CCFcdsParam method didn't suffer from disappearance syndrome, it did mean having to edit all of my symbols (and all of my future symbols) to accommodate them and there was also the leg work of needing to define all of the cdsParams to the particular (and variable) aspects I want (which may also not so portable if somebody else has their own cdsParam definitions when they view my schematics). Anyway, have a good vacation and I hope to hear from you later :-) 

Just thought I'd add another issue to my post from 6 days ago:

3. After my simulation completes and the annotations show up I'm finding they aren't reflecting the state I was expecting/wanting. I expect the annotations to indicate the state at the end of the sim I just ran, but instead they're showing some other DC bias results. Specifically, I did a temperature sweep and upon completion the annotations show what's going on at 27C instead of the last point of the sweep. Can this behavior be changed?

1. A simple solution to one of the issues I mentioned in question 1 is to modify the check and save command to be check, save, redraw. 

The more I think about this, the more I think it's a bad idea to use the OP function in your labels. Using the cdsParam() redirection means that you can then choose to do Results->Annotate->Transient Operating Points and then annotate either the final transient operating point (as opposed to the initial DC operating point) or if using infotimes in the tran analysis, you can annotate the operating point at various times throughout the transient. If you use OP, you are stuck with the DC operating point - you'd have to use a different access function to access the final transient operating point or the infotimes operating points.

So I'd strongly recommend changing back to use the cdsParam() approach. I know it's a little indirect, but that indirection has its benefits in terms of being more flexible about what can be displayed in the labels, which is much of the point of the annotation system.

Regards,

Andrew.

Alright, I've done as you suggested. I'll continue to live in hope that some day Cadence will provide the functionality that started off this thread in the first place. Either way, your comments and code postings throughout this thread have been invaluable and I've been able to make some widgets that will work for me until then. 

And in case you don't already hear it enough, I'd be utterly stuffed without all of your continued assistance in these forums. I hope Cadence appreciate what a wonderful resource they have in you! 

Hopefully this thread isn't too old to require the starting a new one. I've been using my cdsParam widget to display only the parameters of the devices I'm interested in (see the diagram in an earlier post) for a couple months now and it it's working fine. The only thing I wish I could augment it with is that if the annotations are set to show (the default) component parameters then my schematic is cluttered with redundant information. Is there a way for the procedure that displays the widget information to detect which annotation types are being viewed? My intention is to vary what the widgets display based on what's being annotated.

There's a window property hiGetCurrentWindow()->paramDisplayMode which has the current annotation mode (although with the new annotation system, it's possible to have mixed annotations in the setup which display a mixture of design and operating point info) - this is the annotation mode as picked by ADE. The trouble then boils down to the same issue that you don't know the display window without the (currently private) information I've mentioned before.

I did just chase R&D to see if we can reach a conclusion on the way forward for making the display window available to label display functions.

Regards,

Andrew.

Thanks Andrew. It sure does seem like I keep painting myself into corners that require knowing these window IDs! Keep pounding on those R&D guys (and please post back if anything eventuates) :-).