• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Community Forums
  2. Custom IC SKILL
  3. Problem with viaGenerateViasAtPoint function

Stats

  • Replies 11
  • Subscribers 139
  • Views 2325
  • Members are here 0

Problem with viaGenerateViasAtPoint function

CG20240827312
CG20240827312 3 months ago

Hi all, i have written a skill program to place a metal path of M4 on a custom cap(already till say M3) and then drop vias both on top and bottom. The first part draws the paths at desired location and second part uses viaGenerateViasAtPoint() to drop auto via at the point given by me. The issue is that the code works randomly, sometimes it drops vias and other times it Shows VIA-1015 :overlap not found. I tried separating both parts in different functions but of no use. If i run viaGenerateViasAtPoint in ciw after drawing m4 via code, it places auto vias but through code its just random. Thanks for reading, please do provide debugging strategy for this,

  • Sign in to reply
  • Cancel
  • Andrew Beckett
    Andrew Beckett 3 months ago

    Without using the code, the example layout which has a problem, and the version you're using, it's going to be really hard to give suggestions. I suggest you log onto our support platform at http://ask.cadence.com and then use the Case menu to submit a support case.

    Andrew

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • CG20240827312
    CG20240827312 3 months ago in reply to Andrew Beckett

    Thanks for the reply andrew, i will surely put the code very soon and that might help you identify the issue.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • CG20240827312
    CG20240827312 3 months ago in reply to CG20240827312

    Hi andrew, The issue resolved by replacing window id with the cell view id in the viaGenerateViasatPoint() function.Thanks

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • Andrew Beckett
    Andrew Beckett 3 months ago in reply to CG20240827312
    CG20240827312 said:
    The issue resolved by replacing window id with the cell view id in the viaGenerateViasatPoint() function.

    If you'd shared the code, that would have made it possible to identify the problem - of course, guessing all possible mistakes in the dark is not easy!

    Andrew

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • CG20240827312
    CG20240827312 3 months ago in reply to Andrew Beckett

    No issues, actually i do not get access to my office laptop for me to write whole code, anyways can you please help me with this:As i mentioned earlier i have created some pathhs and vias over a cap and groped them using dbcreatefiggroup() and dbAddgigftofiggroup (), now i want to sync copy this group on all the selected caps (set of abutted rows and columns): 

    for each(cap gegetselectedset()

    cf=dbCopy(figgroup cv cap~>transform)

    }

    but for some reason this creates some offset on its x cordinate(2*cap~>x cordinate). I tried debugging but of no use. Thanks

     

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • Andrew Beckett
    Andrew Beckett 3 months ago in reply to CG20240827312

    Again, rather hard to know without seeing what you are doing. My guess is that using the transform of the capacitor instance is not giving you the transformation you need. In essence, cap~>transform will give you the transformation of the origin of the cap cell to wherever it's placed. You will be shifting the figGroup by this same transformation - so unless the figGroup is created around the origin it may end up being offset in some way. dbCopyFig is expecting a transformation to describe the relative shift from the current location of the figGroup to where you want it to end up being - and I can only guess that's not what you've got here.

    Andrew

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • CG20240827312
    CG20240827312 3 months ago in reply to Andrew Beckett

    I get it,i was not understanding the way transform works, i get it now. The code works fine now with X cordinate as iam passing:

    list(car(cap~>xy)-car(figGroup~>origin) ) cadr(cap~>xy)-cadr(figGroup~>origin) cap~>orient  as transform

    However the y cordinate is causing an issue now  because the cap rows are placed alternatively flipped and hence doing that is giving weird values for y codinate. Its making it complicated

    Is there a function that let me place these fig group at desired location?

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • ebecheto
    ebecheto 3 months ago in reply to CG20240827312

    I had the same feature need a month ago, But i did not do it for else than "R0" transform. You might need to adapt.

    it is only the substraction of the local position of the center of the figGroup before relative displacement with dbMoveFig.

    Here is my function :

    ;ineed('dbMoveFigAbs t)
    
    ;xy=8.92:0
    defun(dbMoveFigAbs (@optional (inst css()) (xy 0:0 ))
    "dbMoveFig is a relative displacement, i want an Absolute positioning."
    "For pins, since it is a bBox, i cannot move xy (i guess)"
    "not done for transform list(0:0 'R0') for simplicity"
    ;xy0=centerBox(inst~>bBox);=> (26.465 -0.5)
    dbMoveFig(inst nil list(mapcar('difference xy centerBox(inst~>bBox)) "R0"))
    )

    ++

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • CG20240827312
    CG20240827312 3 months ago in reply to ebecheto

    hi , the code you gave works exactly same as what i had done in my previous reply, it is creating some random offset while converting from R0 to MX( might be). The code i wrote earlier works fine if only R0 devices are selected . Thanks

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • Andrew Beckett
    Andrew Beckett 3 months ago in reply to CG20240827312

    The trick is to compute the correct transformation. If you start by translating the figGroup back to the origin, and then concatenating the transform of the capacitor, you'll get it placed in the right location.

    For example, my figGroup is the blue shapes and the other coloured shapes above are instances of a cell with each of the 8 different orientations. 

    I then have figGroup assigned to the blue shapes (which are in a figGroup, with it's origin at the lower left - the same as the origin of the capacitor cell), and select the 8 instances, and run this code:

    moveToOrigin=list(-xCoord(figGroup~>origin):-yCoord(figGroup~>origin) "R0")
    foreach(cap geGetSelSet()
        dbCopyFig(figgroup cv dbConcatTransform(moveToOrigin cap~>transform))
    )

    then it ends up like this:

    As you can see, the copies have the correct orientations.

    Andrew

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
>

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.

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information