Stats

  • Locked Locked
  • Replies 3
  • Subscribers 125
  • Views 13945
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Long symbol label expressions disrupting Zoom to Fit

CADcasualty

I have some symbols that I've made in a Virtuoso schematic (version 6.17.709) that have some ILLabels labels containing code which evaluates to just a few characters to be displayed beside the symbol. Here's one of the labels:

if(cdfParseFloatString(ilInst->simM)==1 then sprintf(nil "%g/%g" 1e6*cdfParseFloatString(ilInst->w) 1e6*cdfParseFloatString(ilInst->l)) else sprintf(nil "%g@%g/%g" cdfParseFloatString(ilInst->simM) 1e6*cdfParseFloatString(ilInst->w) 1e6*cdfParseFloatString(ilInst->l)))

When I do a Zoom to Fit command for a schematic containing the instance, the resultant view yields an enormous amount of blank area because Virtuoso is assuming the full textual length of the label code is part of the stuff that needs to be catered for as viewable. The actual schematic ends up being tiny and I always have to do a manual zoom-in to see everything afterwards.

I guess the opposite situation could also occur i.e. the actual label text might be quite small but it evaluates to something really big that would subsequently be badly cropped with a Zoom to Fit. Zooming based on *evaluated* labels would keep everybody happy, but just ignoring labels altogether for figuring out a zoom would also be OK with me (because people very often put their schematic within a border frame).

Is there a way to configure Virtuoso to not yield all this gratuitous blank space? Many thanks in advance.

Parents
  • skillUser

    Although not answering your question, you could create a simple function that is a wrapper around the code that you mentioned such that the function name is short. The code for this can be located in the library either directly in a libInit.il file or in a file loaded by that (the libInit.il is automatically loaded when the library is first accessed in a session), so that the code definition is "in" the library that it is used in.

  • CADcasualty
    in reply to skillUser

    Thanks for your response - I had already thought of that but wanted to keep the amount of files I need to maintain down to a minimum. In hindsight - your suggestion is probably a better way to go because if I need to tweak the function then I only need to do it in one place. I have run into this zooming issue a few times before so I still think it's useful for Cadence to change the way it figures out how to do a Zoom to Fit so that it fits the stuff you'll actually see vs the stuff you won't.

Reply
  • CADcasualty
    in reply to skillUser

    Thanks for your response - I had already thought of that but wanted to keep the amount of files I need to maintain down to a minimum. In hindsight - your suggestion is probably a better way to go because if I need to tweak the function then I only need to do it in one place. I have run into this zooming issue a few times before so I still think it's useful for Cadence to change the way it figures out how to do a Zoom to Fit so that it fits the stuff you'll actually see vs the stuff you won't.

Children
  • Andrew Beckett
    in reply to CADcasualty

    The way that fitting is done is quick because it merely uses the bounding box (bBox) information that's in the database already. This propagates up from the symbols to the containing schematics (same for layout too). If we needed to use the evaluated labels to determine the bounding box, it would be much more expensive because it would have to keep re-computing the bounding box all the time, including evaluation of the labels. We already try to optimise when the labels are re-evaluated (only when visible. for example) to improve performance - but this would completely defeat that optimisation because we'd need to evaluate them to determine whether they're on the screen or not.

    So the right solution is indeed to make the function a shorter length rather than the close-to-war-and-peace expression you have right now.

    Regards,

    Andrew.

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.