Stats

More Content

Orcad 22 netlist gives errant rat in Allegro

bustercrabby

This has never happened before so I'm confused.

I have two symbols in my schematic that each have a pin called PAD. Both are 'Power' pins. Both have no connects attached and show up as 'Is No Connect' in the pin properties window.

After recreating the netlist and importing it into Allegro, there is a rat showing a connection between the two pins that are not supposed to be connected. Any thoughts on why this is happening? I think it is on the Orcad Netlist side as opposed to the Allegro side.

Thanks for any help you can give,

bustercrabby

Parents
  • 0

    Five years ago, I encountered the exact same issue while reviewing TI’s DLP reference designs.
    The root cause was that the NC pins of two components were defined with the Power pin property.
    Even though there were no visible connections drawn in the schematic, Cadence automatically tied these pins together under a shared NC power net, simply because they had identical pin names and the Power attribute was enabled.

    This hidden connection is nearly impossible to spot visually in the schematic.
    However, once the netlist was imported into Allegro PCB Editor, the unintended electrical connection became obvious.
    It is extremely difficult to troubleshoot this kind of short circuit, especially for components with high pin counts. 

    It is recommended that when designing component symbols, the power pin property should never be assigned to non-power pins. Due to OrCAD's legacy design mechanism, any pins sharing the same name with the power attribute enabled will be internally connected by the software in the background, even without any wiring in the schematic.

  • 0 in reply to Zhifeng Jin

    We stopped defining pins as power because of this problem. Having a "hidden" net on a schematic is no good.

    Another issue we found was assigning Flash memory data pins as "I/O".

    When setting up propagation delays, all I/O pins in a single net were set as drivers AND receivers. This caused multiple driver/receiver pairs in the propagation delay constraints. 

    We changed these to be "input" pins.

    The power pin problem has been present for at least twenty five years. I'm surprised it still has not been resolved.

Reply
  • 0 in reply to Zhifeng Jin

    We stopped defining pins as power because of this problem. Having a "hidden" net on a schematic is no good.

    Another issue we found was assigning Flash memory data pins as "I/O".

    When setting up propagation delays, all I/O pins in a single net were set as drivers AND receivers. This caused multiple driver/receiver pairs in the propagation delay constraints. 

    We changed these to be "input" pins.

    The power pin problem has been present for at least twenty five years. I'm surprised it still has not been resolved.

Children
No Data
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.