checkHalfWidthPathSeg always enforce

If you look in the documentation, you'll see that this controls half width path segments in the middle of the path. It always checks for the first/last segments being less than half width. These are the ones which cause danger because they can potentially be misinterpreted by tools that read mask data.

In IC615, there's a new option of "never", which will then not check the first or last segment or indeed any of the segments (note this is just talking about paths, not the pathSeg objects which make up parts of IC61 wires).

Even before this enhancement, it doesn't enforce it (it just notifies you of the half-width segment via a popup). So I'm not sure I see the "dumb bug" you describe.

Regards,

Andrew.

 OK, not explaining myself clearly and I probably have confused pathSegs with plain ol' paths.  The variable is more than likely referring to pathSegs not paths so I was off the mark completely.

Here's the problem described in a couple of ways:  I am drawing a path that is, say, 1 unit wide.  I want to bend it and stop the last segment at a length of .5 units wide.  Tool won't let me; workaround is to draw the path longer than 1 unit and chop it off.  And, if I have a bunch of things selected, one of them being a path like this, and I want to stretch the lot making the path less than half width the tool won't let me.

Incredibly frustrating. I want to turn this behavior off completely.  Am I doing something dangerous?  In my world (custom RF), no. 

Another example is a large array of resistor units and I need to hook some end-to-end ( a series configuration).  I need a fat, stubby hunk of metal 1, i.e. wider than long.  The piece of metal does not sit out in space causing problems; it Tbones in a perfectly acceptable way with the metal present in the resistor pcell  If the metal did sit out in space or was dangerous then drc/erc would catch it.

I look forward to the IC615 release.  It would be nice if I didn't get the pop up.   If I'm turning off the "feature" then I obviously don't care.

 And, what I mean by "dumb" in "dumb bug" is not the issues present in 6.1.X but the general tendency of Cadence to "Windows-ize" the user experience by dumbing things down and trying to anticipate "mistakes" and keep the user from making them (also referring to the iconization and missing textual menu items).

Thank you,

--lin

Hi Lin,

What version are you using? The variable is for paths, not pathSegs (as I mentioned in my previous post, I think). If I draw a path in IC614 latest hotfix (6.1.4.500.10), I get a popup if the last segment is less than half the path width. So if I draw a path with width 1um, and then bend and have the last segment as 0.5um (so the end is coincident with the edge of the path), I get no popup. If it's less than half, I get a popup, but it still lets me do it.

If I set it to enforce, it doesn't let me have the last point less than half the path width - it rejects the last point. Again, using 0.5um as the last segment on a 1um path, it also allows this. I can turn enforce off, and it works as in my first paragraph.

I can also do the fat stubby hunk of metal 1 that you describe (provided I don't have enforce mode on).

The default is "off" by the way (which means off for intermediate segments, and notify for end segments, to reflect the old behaviour in previous releases). The "never" is being added to be completely off.

If this behaviour is not happening in the subversion you're using, maybe there's a bug - which is why it would be useful to know the subversion, so I can see if I can track it down.

There's always a trade off with preventing mistakes. If there is a good reason to allow something, then we should make it configurable. Some of the "dumbing down" may be where we try to automate things to make things easier, particularly in a world of complex design rules in 28nm/40nm processes, but I do understand what  you're saying. It's very hard to make everyone happy all the time - we need to retain flexibility without making the tool hideously complex to use.

Not quite sure what you mean by "iconization and missing textual menu items" though.

Regards,

Andrew.

 Hi Andrew,

I'm on version 6.1.4.500.5 too.  Try stretching a path below it's half width.

By "iconization and missing textual menu items" I mean all those little icons that now clutter up the real estate on my screen.  "Show incomplete nets" in layout must be accessed by clicking on the little shape--no pull down menu.  There are other items.  Yes, I know I can "customize" my workspace but the workspaces do not carry from tool to tool and are buggy and do not always load properly.  Moreover in the increasingly dense world of microelectronics, every inch of screen space is precious; stealing this space for commands most often accessed by bindkeys or pull down menu is annoying.

A note:  Semantically the movement towards icons (as opposed to text) is viewed as advantageous to non-native language speakers and the increasing rate of illiterate population.  Some semiotics pundits think that eventually only the elite will be able to read and the rest of the population will only use icons.  There's a part of me that's just naturally offended when a company like Microsoft or Cadence adopts icons as the primary user interface.  Sorry.

Hi Lin,

Unfortunately I don't have that specific hotfix. I tried an earlier version, and saw the correct behaviour - it gives the popup, but still lets me do it.

Ah, hang on, I'd not twigged you were talking about stretching the path rather than entering it in the first place. You didn't say that in your first post (but you did say it later, so my apologies, I'd missed that).

There's a CCR for this,  767393. Unfortunately that's not fixed in IC615, as R&D ran out of time to get it done. There's a workaround, which is to create the "path" using pathSegs (e.g. use Create Wire), but we really should fix this, I agree.

Icons should not be the primary user interface. They are an alternative user interface. Now there have been occasions when we've messed up - but that's not the intention. I tried several versions of IC614, before and after the one you're using - and Connectivity->Nets->Show/Hide Current Incomplete Nets (or Selected Incomplete Nets) is there as a menu item. I think it wasn't in the past though - initially the lack of show/hide incomplete nets was an oversight - the assumption was that people would have the annotation browser up, and use that to toggle the incomplete nets. I think an icon was then quickly added, and the menu came back later.

If there are bugs with the workspaces, please contact customer support. Note you can use the F11 bindkey (by default) or the little eye window with an eye icon in the workspace toolbar, or  Window->Assistants->Hide All (or Show All) to toggle all the assistants on and off. Similarly you can create your own workspaces (and default workspaces) so that you have no toolbars at all, if you like.

There are different classes of users - some find bindkeys intuitive, some like menus, some prefer icons. The icons have tooltips over them so you can read (assuming you're not illiterate!) what they do, and then re-use them without have to go to multi-level pulldown menus. A lot of the point of having multiple input methods is to allow people with different levels of experience to have the ability to find the command they want, and also to provide a variety of input methods, which is important for RSI and so on. We should not be forcing anyone to have to use icons, so if you see something that's on an icon only, please let us know - I wholeheartedly support that functionality should be on menus too. Of course, if it's an assistant already, then it may not make sense to clutter the form with a menu as well, but for functions for the main canvas, I certainly agree.

Regards,

Andrew.