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...

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've had a couple thoughts since starting this post that I was hoping might yield something. For specific node voltages, I could make an instance whose symbol something unobtrusive (like a small arrow) with a single pin/terminal at the arrow head. I could make the pin label invisible and put a cdsTerm() there that would light up with the node voltage when viewing terminal labels is turned on.

Regarding the cdsParam(n) stuff - is the skill code behind those things available? I'm hoping to be able to make another symbol with it's own cdsParams running code that effectively can evaluate and display the cdsParams of a specific instance instead of just itself.

No, the code isn't available (it soon translates into something binary anyway). However, with a simple bit of wrapping, you can provide a simple function that you could use within a label on your symbol to return the value from another instance:

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

So what you'd need to do is write a function that does what you want, and can use ilInstPath to determine which instance your component actually is, and then call CCFcdsParam(...) within that to retrieve the display string from the other named instance. Your function would need to return a string with what is to be displayed. Then that function would be used as the value of an interpreted "ILLabel" on the symbol, just as cdsParam(n) is right now.

Does that help?

Regards,

Andrew.

Yes!!! This is very promising. Been playing around with it for a bit and it looks like I'll be going home on a Friday happy (for the first time in a while) :-). Thank you!

OK - I came across an issue with this method. It turns out that the symbol we made that uses your procedure only yields results if the target instance being referenced cycles through it's annotations becoming visible first. Once that's done this trick works. That makes things kind of messy because the whole point was to not even have cdsParam() annotations on the target instance. Is there any way around this?

Not quite sure what you mean by "cycles through its annotations becoming visible first", but I'm guessing that perhaps you are talking about the fact that if you've used the Annotation setup to stop the other instance from displaying anything in the cdsParam(n) slot then the function I provided above won't display anything either (because the annotation setup would then case cdsParam(n) to return an empty string).

An alternative would be to hide the instance and terminal labels (on the View menu) - this works by turning off the visibility of the device/annotate and annotate/drawing layer-purpose-pair for instance labels, and annotate/drawing8 for terminal labels. So if your labels are still interpreted labels but on a different LPP, then they will still show up. 

Would that work?

Regards,

Andrew.

I agree I didn't explain myself very well. Here's some additional background:
To prevent the ugly mess that occurs when annotations are turned on I made my own symbols for all the TSMC transistors - they don't have any cdsParams or cdsTerms and I made my own labels to show W/L etc. Those symbols exist with the cells of the official symbols in the TSMC library and I called them symbolx.
I have a design I'm developing in a project library that uses those TSMC symbols.
I used your CCFcdsParam procedure to make a cell called view_params that can show the cdsParams of another cell and that cell exists in yet a different (non-project) library. view_params takes a parameter (instName) which is the name of the instance I want to display the parameters for - see attached picture.

So I make my design in the project library with TSMC transistors using only symbolx devices and I place a few instances of view_params in open spaces so I can see the annotations for the devices they reference. I then run a sim. I can turn on annotations etc. and obviously the transistors aren't drowned in annotations, but the the view_param instances I placed don't show any annotations either :-(. Let's say I have a view_params cell referencing a transistor named mn1 and a view_params instance pointing to it - both aren't displaying any cdsParams. Having run a sim, if I now select mn1 and change it's instance from symbolx to symbol then right away I see that symbol change and be covered with tons of annotations. If I now redraw/refresh the screen all the annotations on the view_params cell referencing mn1 also show those annotations. If I now go back to mn1 and change it back to symbolx then mn1's annotations disappear but the view_params cell referencing mn1 continues to display mn1's annotations i.e. the view_params cell needed the cell it's referencing to be kicked in the pants once before it worked. I need to do this individually for each transistor being referenced by a view_params instance...

Hmm - I'm only seeing a generic box with a question mark inside it after attaching a screenshot of the view_params block. Hopefully you can see it.

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"