Stats

More Content

Odd net flipping behavior in OrCAD Capture 22.1 when using netgroups

SimpleFix

We made a schematic and PCB with multiple CAN transceiver ICs which are connected to an MCU using NetGroups for each CAN channel, and on one of them (only one, the rest are correct), I see in the layout CAN3.RXD is going to the TXD pin (pin1) of the transceiver and CAN3.TXD is going to the RXD pin (pin4) of the transceiver, but the schematic is correct! Somehow these nets flipped between the schematic and export to OrCAD PCB. I exported the Telesis netlist and checked it in Notepad and it is incorrect there too, so it appears the issue is on the Capture side, not PCB side. I checked the properties of the nets in Capture, and they have the correct net name, so does not appear to be a net alias. Questions are: 1. how to avoid this in the future and 2. how to check the rest of the schematic for similar switching of the nets. 

OrCAD capture 22.1 S007

Thank you for any help!

  

Parents
  • 0

    Are all the channels using the same components? If not, could it be that there is something that went awry in the symbol definitions for this channel (ie the pins are not what they seem)?

  • 0 in reply to Minet

    Yes, all the channels are using the same components. 

    Here is the CAN2 schematic which created a correct netlist/layout and it is the same symbol for the IC. As you can see the swapping above on CAN3 happened on the RXD signal too which doesn't directly connect to U255, it connects to the two resistors R258 and R259, so it appears the swapping happened at the netgroup level or where it enters the block. The side of the netgroup connecting to the MCU and the top level also looks correct. Really an odd error. The problem is since the netlist export is incorrect, there is no way to do a text-level compare to find this kind of issue on the rest of the schematic or any other schematics in the future.

  • 0 in reply to SimpleFix

    Are all the CAN signals going to one MCU? Could the pins be swapped there for this channel? I wonder if you made a new schematic and place only the MCU and the CAN transceiver, and route just the CAN3 channel, and export, if you would see the same error - ie can you isolate the behaviour somehow?

    The other thing I was also wondering is if it is a net alias but you mentioned in the first message that you have checked that, and I guess if they names were duplicated then there would be a short, not a swap. This is a really disturbing error.

    Do you have any custom scripts you are running, perhaps during export?

Reply
  • 0 in reply to SimpleFix

    Are all the CAN signals going to one MCU? Could the pins be swapped there for this channel? I wonder if you made a new schematic and place only the MCU and the CAN transceiver, and route just the CAN3 channel, and export, if you would see the same error - ie can you isolate the behaviour somehow?

    The other thing I was also wondering is if it is a net alias but you mentioned in the first message that you have checked that, and I guess if they names were duplicated then there would be a short, not a swap. This is a really disturbing error.

    Do you have any custom scripts you are running, perhaps during export?

Children
  • 0 in reply to Minet

    Yes, all of the signals are going to one MCU. We are not using any custom scripts at all, just the normal export to OrCAD PCB / Allegro process. 

    I made a copy of the project then tried fixing the issue by deleting just the netgroup from the CAN3 schematic page so the RXD and TXD nets reverted back to Nxxxxxx net, and then a placed the CAN3 netgroup back down, but when I used auto connect to bus on the Nxxxxx nets, Capture made a noticeable break in the nets with the CAN3.TXD and CAN3.RXD nets on the left going to the netgroup and the Nxxxxxx nets on the right going to U255 and the resistors, which I found really odd (below picture). I had to manually connect the nets to the netgroup entry to get it to work. Once I put everything back and saved it, the netlist issue was still there. Then tried deleting all of the nets tied to U255, R258, R259, and the testpoints, and saved it, then replacing everything and saving it, and the issue was still there. Finally, I tried deleting the netgroup and its port from the block schematic page, going back to the top level page and synchronizing up on the block which deleted the CAN3 port from the block, and saving it, then putting everything back, and finally the issue was fixed. The CAN3 netgroup remained connected to the MCU on the top level and the MCU connections in the MCU block were untouched. 

    I did notice one thing: in the modify netgroup definitions CAN3 had RXD before TXD, unlike all the rest of the CAN channels which had TXD followed by RXD. The order of the netgroup definitions shouldn't affect the connection if done one by one and the original schematic shows the correct connections, so I don't think this is the root cause, but regardless something interesting.

    Again, it is scary this issue could persist, but even more concerning is there is no really good way to check for the error, because DRC did not find it and a netlist export has the issue in place, so no good way to flag the issue.

    Thanks.

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.