Stats

  • Locked Locked
  • Replies 4
  • Subscribers 143
  • Views 16337
  • 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

Highlighting specific paths across nets and instances in schematics

Herge

Highlighting specific paths across nets and instances in schematics

Background

The idea is to create a "current-path"  highlighter. Out of simulations we have "current paths" as collections of device terminals on a certain net where a given current is flowing through. Not all terminals on this net have current flowing through only some devices participate in the current path, that will also span multiple nets and multiple devices. But let's concentrate on a single net, and the associated list of device terminals through which the current is flowing.

  1. We want to highlight only those segments on the net which form paths linking the terminals listed as being active.
  2. We want also to mark the device terminals with in-coming or out-going arrows depending on the sign of the current, also annotated in two lists

Present understanding of the problem

After reading through documentation and question/answers posted on the discussoin fora, I think the situatoin is as follows :

  1. In order to get the list of all wireSegments, we would have to query the figures from the nets.
  2. In order to "understand the connectivity of wireSegments, we need to find how they share vertices based on the point coordinates. There is no other way to find that two wireSegments share a common vertex.
  3. In order to "understand the connectivity of wireSegments to device terminals", we need to obtain the bounding boxes of those terminals in the coordinate space of the cellview (not that of the instance master) and find which wireSegment has a vertex falling in that box.
  4. Once that is done we can build a graph model representing the connectivity of wireSegments and terminals and apply some search algorithm in order to find which wireSegments participate in the wanted paths.
  5. Once we have the list of segments we can include them in some highlight group.

Questions

I would like to get your feedback on the points above :

(a) Is the procedure outlined above correct ?

(b) Did I miss something in the DB organization which would allow us to implement a simpler solution ?

(c) Does anyone have some scipts or programs to do this ?

Looking forward to your inputs. Thanks,

Renaud

Parents
  • skillUser

    Hi Renaud,

    [a]

    I believe that your understanding is correct for (1) and (2) - you query the figures on a net to get the wire/line segments (is this in a schematic, I'm guessing 'yes'), and as far as I know there is no storage of sequence of one net segment to another so, yes, you would need to follow connectivity through the common vertices.  If you didn't need to limit to only certain parts of the net then you could easily mark/highlight the whole net.  Likewise for (3) the overlap of the pin box (device terminal) with the line (wire segment), I think you need to work this out rather than being able to pull it directly from the database. It looks like (4) and (5) are correct.

    [b]

    I don't think that you are missing anything, a certain amount of 'manual labor' is required, even though some of the database storage is convenient.

    [c]

    Here is a snippet of code that can be used to find a 'wire' object that overlaps an instance pin, where "inst" is the instance database object ID

    foreach(instTerm inst~>instTerms
      if(pins = instTerm~>term~>pins then
        dir = instTerm~>direction
        unless(onep(length(pins))
          warn("%s - Terminal %s has more than one pin, using first one\n" getCallingFunction() instTerm~>name)
        ); unless
        pinCenter = centerBox(
          dbTransformBBox(car(pins)~>fig~>bBox inst~>transform))
        shapes = dbShapeQuery(cv list("wire" "drawing") list(pinCenter pinCenter) 0 0)
        if(shapes then
          wire = car(shapes)

    ...

    Hopefully this will help you a bit.

    Best regards,

    Lawrence.

Reply
  • skillUser

    Hi Renaud,

    [a]

    I believe that your understanding is correct for (1) and (2) - you query the figures on a net to get the wire/line segments (is this in a schematic, I'm guessing 'yes'), and as far as I know there is no storage of sequence of one net segment to another so, yes, you would need to follow connectivity through the common vertices.  If you didn't need to limit to only certain parts of the net then you could easily mark/highlight the whole net.  Likewise for (3) the overlap of the pin box (device terminal) with the line (wire segment), I think you need to work this out rather than being able to pull it directly from the database. It looks like (4) and (5) are correct.

    [b]

    I don't think that you are missing anything, a certain amount of 'manual labor' is required, even though some of the database storage is convenient.

    [c]

    Here is a snippet of code that can be used to find a 'wire' object that overlaps an instance pin, where "inst" is the instance database object ID

    foreach(instTerm inst~>instTerms
      if(pins = instTerm~>term~>pins then
        dir = instTerm~>direction
        unless(onep(length(pins))
          warn("%s - Terminal %s has more than one pin, using first one\n" getCallingFunction() instTerm~>name)
        ); unless
        pinCenter = centerBox(
          dbTransformBBox(car(pins)~>fig~>bBox inst~>transform))
        shapes = dbShapeQuery(cv list("wire" "drawing") list(pinCenter pinCenter) 0 0)
        if(shapes then
          wire = car(shapes)

    ...

    Hopefully this will help you a bit.

    Best regards,

    Lawrence.

Children
  • Herge
    in reply to skillUser

    Thank you. Very helpfull.

    One more question: do you think it is possible to augment the data-base by storing "custom" data, for example on the wire-segments in order to speed up the current highlighting operations (at a later time or when doing it multiple times) ?

    And also a second question: I assume that all operations detailled previously and above could be triggered from an external program using OA access functions ?

    Regards,

    Renaud

  • skillUser
    in reply to Herge

    Hi Renaud,

    Yes, this is one of the great things with the Cadence database and SKILL - you can 'tag' objects or add custom properties in a persistent way that will be stored in the database for later recall - you can use the API functions (dbCreateProp, dbCreateEnumProp, dbCreateHierProp, dbCreateRangeProp) to create data, or you can use ~> and assignment (e.g. netId~>myHilightProp = t).

    Best regards,

    Lawrence.

  • Andrew Beckett
    in reply to Herge

    You could store user properties on the wire segments, for example, or create groups to store related data. Of course, you might have some synchronisation issues as users edit the data.

    Even if you could use an external program using OA access functions (information on which would come from Si2 rather than Cadence since we don't document them ourselves), that external program can't create hi lights and things like that because those APIs are only available within Virtuoso. So I'm not sure it would be particularly beneficial to do it outside.

    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.