schematic vs symbol pinorder.

I have checked the schematic cross view and "ignore terminals with net expressions and no terminal in the other view" is set.

I'm not entirely sure what you've done (probably best to follow up with customer support to take a look properly at your data), but in my view worrying about ensuring portOrder consistency is not important. For the most part, only the verilog netlister uses the portOrder, and even then only for stopping views - and it doesn't matter whether it's inconsistent as only the view used affects the order. There are some unusual cases when the CDL netlister uses it (auCdl), but in those cases it also is only the stopping view that matters - no requirement for it to be consistent across views. 

In my view it's best to turn off the check because otherwise you spend a lot of time fixing stuff that doesn't matter!

This article explains how to disable the check.

Most of the netlisters use the CDF termOrder instead - for stopping views, and for intermediate levels of hierarchy it will use the CDF termOrder provided that it's consistent with the terminals on the view used (if it's not consistent, it will use a built-in sorted order). You can ensure that the CDF termOrder is updated by setting these .cdsenv vars:

; turn this on if you want changes to the pins on the symbol to trigger CDF updates
auCore.misc updateCDFtermOrder boolean t
; turn this off if you don't want to be asked about updating the CDF
;auCore.misc queryCDFtermOrder boolean nil

Regards,

Andrew

Hi Andrew,

It';s not the pinorder that bothers me, it's the warning created at symbol  check and save which states that the global inherited pins in the schematic are NOT in the symbol view. Well, they are not supposed to be, but they appear in the symbol's pinorder list whereas prior to this they did not. I have taken this up with support.

By the way if I use an implicit inherited connection, the problem doesn't occur, just with explicit pins in the schematic.

Sorry, your earlier use of the term "global pins" threw me (I wasn't paying enough attention and only read your earlier post rather too quickly). Global pins are a bad idea and should be avoided at all costs, but it sounds as if you are talking about explicit inherited connections which have a default net name which is global. The pins (or rather terminals) themselves are not global - they are inherited connections.

The default behaviour is to not flag pins on the schematic which have net expressions on the terminals and are missing on the corresponding symbol. If they are being flagged in a cross-view check, then it's because this option has been turned off - I've highlighted the cdsenv that controls this too:

The portOrder will (I think) have the missing pins on the symbol too - that's because of the attempts to keep the portOrder (pin order) consistent between the views - although I wouldn't get too hung up on that. Most of the netlisters will end up having to netlist the pins on the instance and subckt definition anyway in order to connect them up - you just have the convenience of being able to miss out wiring up the pins on the instance and connect by property instead.

Notice (and this is good practice that we recommend) that when using explicit inherited connections you give the pin names simple names (i.e. no exclamation mark in the terminal name itself) as that means you can generate layout with sensible (non-global looking) pin names but yet have the benefits of inherited connections still.

Regards,

Andrew

Thanks, this is consistent with what support told me. If you notice my post above, you'll see that I DID have the cross view check selected appropriately. However your comment regarding "bang" signal names in the layout is spot on. The chip I taped out la few weeks back  had just this, and now knowing that, for example I name the pin "vplus", the property name "vdd" an the default net name "vplus!", I should eliminate this issue.

I've been appraised that there is a second "inherited connections" RAK which covers this in greater detail that the one I did got through some time back. When I get time, I'll look that over, but for now my issue is solved.

Thanks again for your time and effort.

Thanks, this is consistent with what support told me. If you notice my post above, you'll see that I DID have the cross view check selected appropriately. However your comment regarding "bang" signal names in the layout is spot on. The chip I taped out la few weeks back  had just this, and now knowing that, for example I name the pin "vplus", the property name "vdd" an the default net name "vplus!", I should eliminate this issue.

I've been appraised that there is a second "inherited connections" RAK which covers this in greater detail that the one I did got through some time back. When I get time, I'll look that over, but for now my issue is solved.

Thanks again for your time and effort.