Going forward (whether cleaning-up migrated designs or creating new schematics from-scratch), we had intended to standardize on a port symbol that was more appropriate from a design-review standpoint... something that was graphically more informative.

So, we had intended to use con_hier_i.1, con_hier_o.1, and con_hier_bi.1 (also from the 'builtin' partition). We chose those for a couple of reasons:

2) The “con_hier” (port) symbols are reminiscent in appearance to the older interpage (annotate) connector symbols, yet offer enough graphical distinction to inform users if they are using the correct symbol for hierarchical connection

We thought we were "good to go" in adopting the "con_hier..." port symbols, until some recent debug revealed an anomaly with their Pin Type properties.

Symbol

Pin Type

Comments

builtin:in.1

builtin:con_hier_i.1

IN

OUT

Why opposite?

builtin:out.1

builtin:con_hier_o.1

OUT

IN

Why opposite?

builtin:bi.1

builtin:con_hier_bi.1

BI

BI

(these match, as expected)

I am wondering if Mentor could provide any insight into why the "con_hier..." versions are different with respect to the Pin Type direction? Our local AE has suggested that the symbol pin type (for the "con_hier..." versions) may be incorrect.

More importantly, is it safe to proceed with using the "con_hier..." symbols as ports... despite their apparently reversed Pin Type... ? Or if we adopt them in their present state, will this cause problems for us down the road (e.g. DRC check errors, etc.)?

In my limited testing, there doesn't appear to be an issue... so far.

For example, if in the Special Components (speccomp.ini), I have defined my ports as follows...

Port

Symbol

Port_IN

builtin:con_hier_i.1

Port_OUT

builtin:con_hier_o.1

Port_BI

builtin:con_hier_bi.1

... then, if I attach "con_hier_i.1" to a net called "alpha" and ensure the container block symbol pin named "alpha" has its direction defined as "IN", I don't seem to get any errors (despite the fact that this port symbol has a pin type of "OUT").

However, seeing this difference makes me a little nervous to proceed with the “con_hier...” symbols (for new/updated designs) without first understanding the potential consequences. After a couple of years of fits and starts, we are about to embark on a widespread migration in earnest, and I wouldn’t want to have users implement defective symbols for port usage if it may cause us to have to revise schematics and re-train once again later on.

It sounds like this is a "bug". I will discuss with other members of my team.

Based on your reply, we will likely create a different version of the port symbols and include them under a separate partition of our corporate central library (i.e., we will probably not reference any ports that appear in the 'builtin' partition as presented by the standard install).

It was a result of a difference of interpetation. If the signal enters into the IN pin of the composite block, then the signal logically goes OUT of the IN port pin to go in to the next pin in the chain. Therefore IN symbol types would have pins with the OUT pin direction.

Attachments

Gary, I believe I understand your comment. And Olivier's graphic supports that rationale. Oliver's graphic is also consistent with the way the "con_hier" port symbols are constructed.

Per Oliver's comment, this paradigm (an "input" port has a Pin Type of OUT, an "output" port has a Pin Type of IN) is how things "should" be. Yes?

Based on this interpretation, I could be confident in proceeding with adoption of the con_hier_i, con_hier_o port symbols throughout our designs?

Yet, the 'builtin' in.1, out.1, and bi.1 symbols which are auto-placed by DxDesigner during migration implement an opposite paradigm ("input" port has Pin Type IN, "output" port has Pin Type OUT). Other voices within Mentor (Michal above, our local AE, etc.) are steering us toward this paradigm as the safer bet, and seem to imply that the "con_hier" versions carry some risk.

... which set of port symbols does Mentor recommend as giving us the best chance at minimizing future issues?

(or is there some other option that hasn't been mentioned yet)

I have to confess that all of this has me scratching my head: Given a port symbol (whose Symbol Type is PIN), then under what circumstances is the difference in its Pin Type (IN vs. OUT... or for that matter, BI) important? I already "get" that a composite block symbol's pins have a directionality, and that I can assign whatever pin-type symbols I want to be the "in", "out", or "bi". But as for the pin-type symbols themselves (the ones to be used as ports), does it matter whether their actual Pin Type is IN, OUT, or BI?

I'd also be interested to hear what approach other customers have taken, and what we might have to watch out for.

The set of symbols you use does not matter. I suspect the reason why we provide 2 sets is historical (I bet: before and after hierarchy support in viewdraw/DxDesigner schematic editor).

The majority of our customers who design hierarchically stick to the con_hier_XX symbols for hierarchical ports. A few have created their own symbols. Graphics is not important (apart from the esthetical aspect) as long as the symbols you adopt are properly pointed to in the appropriate Special Component section of the settings. This is the information used by the tool to automatically insert the ports while pushing through hierarchy after you've created a block. It is also used by Verify (DRC utility) to check block symbol pin versus underneath hierarchical port consistency (provided you abide by the opposite Pin Type / Port direction convention discussed earlier in the e-mail thread)!

My personal choice? I would do like the majority of our customers and use the con_hier_XX symbols (BUT CHECK THE PIN TYPE BEFORE!).