What special about schEditPinOrder?

Having taken a look at the function, it's essentially a procedural abstraction (so you don't need to worry about the precise details of where it stores the portOrder) of setting the portOrder property on the view. However it also appears to mark the symbol as modified (when you update the schematic portOrder) - not entirely sure why it does that. There's also some code in there to clean up some old (obsolete) Verilog netlisting properties, but practically these probably won't exist.

The main question is whether you need to even bother. The portOrder checks are mostly a historical annoyance because the only thing that really needs them is the Verilog netlister, and even then only for leaf cells (stopping views) which are going to be netlisted implicitly (connect-by-order rather than connect-by-name). That information only comes from the stopping view which needs to be carefully set up anyway - and there's little need to have the portOrder consistent with other views. So I generally recommend turning off off the check because it's just an irritant with little added value. See:

• How to disable port order checking for text view vs symbol view?
• Role of portOrder or pin order and CDF termOrder in Verilog, auCdl, Spectre and Verilog-AMS Netlisters

In your code above, there's not particularly any need to run schVIC - this is the cross-view check, other than checking that the terminals themselves are consistent between the views. 

Hope that helps!

Andrew

Hi Andrew,

The thing is, besides Cadence tools we are using other tools like Calibre, Totem etc. Because of this sync between port orders of spectre, auCdl, symbol etc. is very important for us.

So, in our case, we care very much about proper and synced port order :)

However the auCdl netlister, spectre netlister, and so on do not use portOrder. They use the termOrder in the CDF in the simulation information - so I doubt very much whether any of the external tools you mention are sensitive to the portOrder property, which is pretty much only used for the purpose I described. As a result, I really don't think it matters about having the portOrder property synchronised.

The termOrder in the CDF can be updated automatically on symbol save by using these two env vars:

; the env var below is set to nil by default. If this is turned on, and the pins on the symbol changes, then it will update the CDF (or ask if the
; query env var is set to t)
auCore.misc updateCDFtermOrder boolean t
; the env var below is t by default, but you can set it to nil to not ask the user if they want to update the CDF but do it anyway (if the one above is set to t)
auCore.misc queryCDFtermOrder boolean t

Andrew

Yes, I know that auCdl and Spectre using CDF termOrder.

We have a case when we simulate DSPF view for Totem simulation. DSPF port order created from CDL port order. Save statements for ports generated from DSPF by order and then simulation results from FSDB file going back to Totem that expects same signal order as port order in DSPF. So spectre termOrder should be same as auCdl. auCdl should match symbol for LVS. Besides we had a lot of cases when schematic port order somehow becomes different from symbol and there are flashing X after check and save and no GUI option to fix this. So currently I am using schRegPreCheckTrigger to sync symbol port order to schematic port order and also setting CDF termOrder for spectre and auCDL. This has worked fine so far. 

I am also not sure what problems may cause a portOrder mismatch between schematic and symbol, so I prefer to force sync all

That's what the article I mention is for - it just suppresses the check. The check is pretty much just noise, which is why I suggest turning it off. From years of experience, the symbol/schematic portOrder mismatch can't cause any issues with flows - even with the Verilog netlister if they are out of sync it shouldn't matter because it's only going to use the one on the stopping view (if there's a stopping view involved).

If you suppress the check, then the flashing markers will stop.

So that would be my recommendation rather than adding more code to bolster a superfluous and unnecessary check! If you really do want to continue with fixing the portOrder, by all means you can do so.

Andrew

Ok, I see. So setting envSetVal( "schematic" "vicCheckPinOrder" 'boolean nil) will also stop check of port order consistency between schematic and symbol? 

That's right.

Andrew

BTW, I just noticed this article was published recently: SKILL script to update both pinOrder of symbol view and termOrder property for auCdl, auLvs, and spectre simulators on schematic check and save; SKILL script to find all cells in the library for this mismatch

(not sure this is strictly necessary given the other options, but I thought I'd put it out there).

Andrew