How is the order of ports/terminals in portOrder/termOrder defined?

Hi Sjoerd,

The order that is returned by cv~>terminals is not defined, essentially it would be random, so I wouldn't recommend using it for setting the termOrder, and this also explains why cv~>terminals~>name is not useful as an order but it is useful to obtain the values.  As you have noted the portOrder is the outputs, inputOutputs then inputs, each sorted alphabetically. I believe the terminal order that is used if termOrder is not defined is the same as the portOrder method. I would recommend setting termOrder in a consistent way, maybe the same as portOrder - for a given (analog) simulator, the termOrder for that simulator (in the simInfo section of the CDF) is used, so it is very important.

Hopefully this helps a little?

Best regards,

Lawrence.

Hi Lawrence,

Thank you for your detailed answer.

Since we're using Verilog as well, I understood from some of the documentation I've read that the portOrder cv property is important. Is there a special procedure to add the portOrder, or is simply a matter of:

cv->portOrder = list( ... )

Thanks in advance.

With kind regards,

Sjoerd

Hi Lawrence,

Thank you for your detailed answer.

Since we're using Verilog as well, I understood from some of the documentation I've read that the portOrder cv property is important. Is there a special procedure to add the portOrder, or is simply a matter of:

cv->portOrder = list( ... )

Thanks in advance.

With kind regards,

Sjoerd

Hi Sjoerd,

Some thoughts on all of this.

The portOrder property is really not very important. It only affects the Verilog netlister and doesn't impact any ADE netlisters which are CDF based (see later). Even with the Verilog netlister, it only really matters if you're using implicit netlisting (i.e. not connect by name, but connect by order) and even then it only truly matters at a stopping view. I've got a CCR asking that we should stop doing all the portOrder checks and at least have an option to turn them off (it's not been implemented yet though). The ADE netlisters use the CDF termOrder in the simInfo for the specific netlister.

If the component is a leaf level then they must exist (actually I don't think that's true for portOrder if explicit netlisting is chosen). For order-based netlisters such as spectre, auCdl etc, then termOrder must exist at the leaf (stopping view) level because it has no idea what the order should be. Certainly for ADE netlisters, if the termOrder is missing or incorrect (i.e. references pins that no longer exist), then it reverts to a default order (alphanumerical – might be outputs, then inouts, then inputs – can't remember). Similarly the Verilog netlister also has a default order if portOrder isn't there (and the order doesn't matter if using explicit netlisting, which is always wise to use).

My suggestion would be to set this:

envSetVal("auCore.misc" "updateCDFtermOrder" 'boolean t)
; maybe below if you don't want to be asked to update the order
envSetVal("auCore.misc" "queryCDFtermOrder" 'boolean nil)

These update the termOrder in the CDF if the pins on the symbol are changed (it's done when you save the symbol). This tends to keep the termOrder updated and stops you getting so many warnings during netlisting. In practice these warnings should not matter because if there's any inconsistency in the termOrder then it will revert to a default order. For portOrder I typically just stop worrying about trying to get them consistent because it really doesn't matter any more (essentially if the portOrder is different between the symbol and the switch view, provided it consistently uses one or the other, all is OK; if it uses a different value for the instance and the definition of the module, that's a bug in the netlister).

So to summarize, I think people end up worrying far too much about termOrder/portOrder for hierarchical blocks – not helped by the popups when there's a portOrder discrepancy! Hopefully the above settings (plus Lawrence's input) will avoid you having to write too much code...

Andrew

Hi Andrew,

As always, a very detailed and well written response. Thank you for your time and effort.

I'll make sure that in our global cdsinit file (we split the setup in global/site/process/project init files) the variables are set (the two you mention).

We're relying on Verilog netlists for top-level verification, and a colleague ran into problems because the termOrder/portOrder was inconsistent. After he fixed that inconsistency, the simulation ran without any problems. Therefor, I'll be writing a little bit of code to create a menu item which, once selected, fixes all termOrder/portOrder entries. Just to make it as low-effort as possible for my colleagues.

With kind regards,

Sjoerd

Hi Sjoerd,

If you still have the data and can reproduce the problem, it would be great if you can contact customer support so that we can try to fix the root cause rather than relying on  you having to uncover such issues and fix them manually.

Regards,

Andrew.

Hi Andrew,

I'll get in contact with the colleague who ran into problems. Hopefully he can easily reproduce it.

The verilog netlister, at what view does it look for portOrder information? Does it look at the stop-view (VerilogA) or at the schematic view?

With kind regards,

Sjoerd

Hi Sjoerd,

I believe (without testing it, as I'm on vacation at the moment) that it would use the stopping view (which wouldn't be verilogA, since that's not a view anything to do with the Verilog netlister; note that VerilogA views wouldn't normally be stopping views in spectre either because they might contain hierarchy in the textual view). It wouldn't be the schematic anyway - it would be either the placed master (typically the symbol) or the stopping view, but I would expect it to be the stopping view.

Andrew