Stats

  • Locked Locked
  • Replies 9
  • Subscribers 165
  • Views 4882
  • Members are here 0
More Content
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

Use of a "null" padstack

microsoftpc
Before release 16.0, we used a null padstack. The null padstack was used as a placeholder padstack on a surface-mount connector in which certain pins are not used , for keying purposes. In some other cases different pins were not used and/or a different number of pins were not used. They were all alternate symbols for the same part number component. Alternate symbols for the same default symbols must have the same number of pins. For example, on a 24-pin connector, pins 23 & 24 may not be used, where on another alternate, pins 1,3 & 5 may not be used. Before, I was able to define the null padstack by creating a definition on a non-electrical layer that was not used, for example, FILMMASK_TOP. There, no DRC's would appear on any electrical layers. This worked well when producing gerber files and ipc356(not ipc356A) netlist that were checked in Valor. IPC356A is not translatable in Valor.

Now, in release 16.0 and above, padstacks are now required to have some kind of definition on an electrical layer. If I define anything on a electrical layer, even as a circle shape with no dimension, DRC’s will occur as in its spot to a plane or trace or via.

Cadence responded this to my situation: The electrical symbol would has to match the physical. That being said the physical has 22 pins, either pins 1/3 missing or 23/24.You would then need the elec. to have the same pins missing. If you want the ipc netlist to come out - and meet the spec - then you will need several sym sets. I don't believe there is a 'one size fits all' answer here.
Has anybody used a padstack in the same situation that I described in rel 16.0 and above? If so, how did you define the padstack? Was there  any DRC's as a result? Any suggestions would be much appreciated.
  • microsoftpc

    Hi Mike

     Unfortunately, my situation is not an edge connector so when I create the padstack to have a very small definition on a electrical layer, it causes DRC's. I do not know how to post a picture of my problem as you did to show you. If you can tell me I will try showing you the situation that I have. Thanks for the suggestion though.

  • microsoftpc
    This is what I have set in my env file for rel 16.2:

    set padstack_allow_null

     However this still not allow me to save the "null" padstack as a single layer padstack. Perhaps that is the wrong syntax. If it is the wrong syntax can you show me the correct way, thanks.
  • microsoftpc
    Yes, that is where I first noticed what was going on. I thought that the format of the ipc356 netlist was changed in rel 16.01. I opened SR #41413618 and have since then narrowed the problem to the "null" padstack after several hotfixes assigned and failed on this issue. The Cadence response that I posted is their stand on this. Can you please keep me posted on the results from your SR as Cadence stance on "null" padstacks is "do at your own risk".
  • microsoftpc

    Unfortunately I tried that and in my situation, this would create possible DRC's and small reliefs on shapes. Hopefully my picture will come through to show you what I mean.

    It was suggested to me that in rel 16.2 to use the env variable "padstack_allow_null". I couldn't get this to work and could not get a response from the person who sent it on what the correct syntax was. I opened and SR about this with Cadence and the variable name is suppose to called "padstack_allow_null" and the value is "TRUE". This needed to be done as a system env variable and cannot be used just in the env file. Still this did not working. After writing to Cadence on what I did, they were able to re-produce my issue and are investigating it further. That would be SR #41558182. Hopefully something will come out of this SR,

Cadence Guidelines

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.