Annotations are just way too overpowering

OK, time for me to eat some humble pie :-/. It turns out there is considerable control available over what annotations can/can't be displayed (via the View -> Annotations -> Setup... menu). I formally withdraw the first paragraph of my post and accuse myself of ignorance and violating the law of RTFM (just beating Andrew to the punch here). Sorry about that :-(.

That being said, I really wouldn't mind knowing if there are viable answers to the thoughts in my 2nd paragraph...

It's more of a case of NQGTPOTMY than RTFM (Not Quite Got To That Part Of The Manual Yet) ;-)

Unfortunately the second part can't be done currently. Interestingly I was only discussing this in a meeting  a week or so back, but it's the kind of thing I'd like to see in the future - control of annotation of other quantities (I'd like to add things like noise contributions, distortion contributions, the value of the 2nd harmonic from a PSS result etc). CCR 1096295 is for the harmonic balance idea, CCR 631948 for annotating noise contributors (also talks about the more general request).

So might be worth contacting customer support and asking for a duplicate to one or other of these...

Regards,

Andrew

I suspect this might be some caching behaviour interfering with things here. I'll have to try it out (hopefully tomorrow). Which IC subversion are you using (just in case it matters)?

Regards,

Andrew.

6.1.7-64b.500.9

I've been trying for over an hour to get the same function as you suggested working for a cdsTerm and I'm darned if I can make it work (and I don't know why). Any ideas on this? I'm trying to pass in a terminal name e.g. "D"

CADcasualty said:

I've been trying for over an hour to get the same function as you suggested

Don't waste more time on it - I'll look tomorrow (it's evening where I am, and so will look in the morning when I can put together some worked examples).

Regards,

Andrew.

OK, there were two issues:

1. The "new" (it's newish now) annotation flow checks to see if there are actually cdsParam() labels on the instance, and if not, it returns an empty string. The simplest way around this is to temporarily switch back to the old annotation flow though to workaround this. Not entirely sure why it does this check - it may be so that all the data can be cached in one hit, but not sure it has to be that way.
2. For cdsTerm labels, it turns out that the cdsTerm macro quotes the argument, so that means that you can use cdsTerm("D") but not cdsTerm(termName) because it looks for a terminal literally called termName (it's because strictly speaking you can just to cdsTerm(D) without the quotes). So I had to use the expansion of the cdsTerm macro, which is a private function - you can find this out yourself easily enough as you can see how macros expand, but it could change in future.

Here's the updated code. I'd suggest contacting customer support and asking for a public way of doing this lookup on another component approach, as the way I'm doing it is a bit of a hack...

procedure(CCFcdsParam(instName index)
  unwindProtect(
    ;--------------------------------------------------------------------
    ; use dynamic scoping to temporarily set ilInstPath
    ;--------------------------------------------------------------------
    let(((cvId ilInstPath~>cellView) ilInstPath)
      ;------------------------------------------------------------------
      ; New annotation flow checks for presence of cdsParam labels on
      ; instance, so have to temporarily switch back to old annotation flow
      ;------------------------------------------------------------------
      envSetVal("auCore.misc" "useNewAnnotationFlow" 'boolean nil)
      ilInstPath=dbFindAnyInstByName(cvId instName)
      cdsParam(index)
    )
    envSetVal("auCore.misc" "useNewAnnotationFlow" 'boolean t)
  )
)

procedure(CCFcdsTerm(instName termName)
  ;----------------------------------------------------------------------
  ; use dynamic scoping to temporarily set ilInstPath
  ;----------------------------------------------------------------------
  let(((cvId ilInstPath~>cellView) ilInstPath)
    ilInstPath=dbFindAnyInstByName(cvId instName)
    ;--------------------------------------------------------------------
    ; need to use what cdsTerm expands to because the cdsTerm macro
    ; quotes the terminal name unfortunately.
    ; CAVEAT EMPTOR - uses private function below
    ;--------------------------------------------------------------------
    _artTestCdsTerm(termName)
  )
)

Regards,

Andrew.

Almost there! CCFcdsParam is now always showing something now without having to prod the referenced cell first, but it's *only* showing the component parameters when I want it show other things e.g. DC Operating Points. The CCFcdsTerm procedure seems to be working OK so far (although I haven't tested that as extensively).

Also, it looks like we might not need the private function for CCFcdsTerm because it seems you can do:

evalstring(strcat("cdsTerm(",termName,")"))

OK, I’m going back on the approach of switching to the old annotation flow temporarily for the cdsParam(N) label display issue. The problem with that is that because the new annotation flow is active in the rest of the session (probably a good thing, since then you can benefit from the balloons, and the improved annotation setup form), when you ask to display the operating point data from ADE, it only changes that in the new annotation flow. So the cdsParam() function (when in old-annotation-flow mode) continues to display the component parameters.

So I’m suggesting instead an alternative (and I think cleaner) approach that doesn’t require switching back to the old annotation flow. Rather than removing all the cdsParam() labels from the symbols, leave them there but change them to be invisible. This can be done on the label objects themselves and doesn’t require you to mess around with the layer purpose visibility.

In the symbol editor, have all the annotation labels as normal (cdsParam(1), cdsParam(2) etc). Select them all and in the CIW do:

geGetSelSet()~>isVisible=nil

They’ll then vanish, but they are still in the database. The good news is that the new annotation flow still sees them - both on the annotation setup form, and also in the code that cdsParam() calls. Using the code below will then work when in both component parameter and dc operating point mode (note, you can only reference whatever cdsParam(N) labels are on the symbol, visible or not, this way). Good suggestion to use evalstring for this too.

procedure(CCFcdsParam(instName index)
  ;--------------------------------------------------------------------
  ; use dynamic scoping to temporarily set ilInstPath
  ;--------------------------------------------------------------------
  let(((cvId ilInstPath~>cellView) ilInstPath)
    ilInstPath=dbFindAnyInstByName(cvId instName)
    cdsParam(index)
  )
)

procedure(CCFcdsTerm(instName termName)
  ;----------------------------------------------------------------------
  ; use dynamic scoping to temporarily set ilInstPath
  ;----------------------------------------------------------------------
  let(((cvId ilInstPath~>cellView) ilInstPath)
    ilInstPath=dbFindAnyInstByName(cvId instName)
    ;--------------------------------------------------------------------
    ; Rather than using expansion of cdsTerm macro (could use
    ; expandMacro and eval) simpler to just use evalstring in this
    ; case. Can't call directly because the macro quotes the argument
    ; preventing evaluation 
    ;--------------------------------------------------------------------
    evalstring(strcat("cdsTerm(\"" termName "\")"))
  )
)

Regards,

Andrew.

Sorry for the late reply - I've been away for a few days.

I can't thank you enough for your help getting all of this up and running!! I've been able to take your suggestions and make an unobtrusive net voltage monitor, a bias leg monitor, and a cell that displays the cdsParams of another instance. I've attached a screenshot of part of one of my schematics showing those cells in action.

The only thing I still wish for is being able to directly access the various simulation or model aspects without having to go through the awkwardly indirect route of cdsParam() i.e. it'd be great to directly access e.g. the gm of mp42 etc.

Glad you got it all working - that looks good!

If you don't want to go via the cdsParam() approach, you could simply use OP(strcat(geGetInstHier() "/" instName) "gm") - the main downside of that is that you then won't get the ability to change what is annotated via the menus in ADE, or using the annotation setup form in the schematic - up to you.

Regards,

Andrew.

Glad you got it all working - that looks good!

If you don't want to go via the cdsParam() approach, you could simply use OP(strcat(geGetInstHier() "/" instName) "gm") - the main downside of that is that you then won't get the ability to change what is annotated via the menus in ADE, or using the annotation setup form in the schematic - up to you.

Regards,

Andrew.

Thanks Andrew - I'm actually also very interested in your other approach. I did try a search for "op" and "op(" to read more but their are too many keywords containing or ending in "op" that contaminate my search results. Can you please point me to the documentation for this.

Run cdsFinder from the UNIX prompt (or type startFinder() in the CIW) and search for "OP". Look in the resulting matches (it's in upper case), select the OP entry and then press "More Info". That will take you to the relevant documentation for this function. It's the same function used in the calculator when you press the "op" button.

Regards,

Andrew.

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.