undefined function uiLoadTrigger in si.log

Hi Fred,

I assume you're not calling uiLoadTrigger in the libInit.il file - if so, it's a private function and should't be called.

I did find some reports if this showing if the libInit.il contained calls to envLoadFile() which loaded a cdsenv file containing "ui" entries, but I think this was fixed a very long time ago (I didn't yet do any experiments).

Before me doing any experiments, which IC subversion are you using? In other words, what does help->about report?

Regards,

Andrew.

Andrew,

Yes. It turns out loading cdsenv is the culprit.

 ;; load library .cdsenv file
    ;fred  when( ddObj = ddGetObj(libName nil nil ".cdsenv")
    ;fred     printf("\tLoading %s/%s ... " libName ddObj~>name)
    ;fred     if( errset(PasEnvLoadFile(ddGetObjReadPath(ddObj))) then
    ;fred        printf("done!\n")
    ;fred     else
    ;fred        success = nil
    ;fred        printf("failed!\n")
    ;fred     )
    ;fred  ) ; ** when ddObj **

Is PasEnvLoadFile(ddGetObjReadPath related?

Thanks.

Fred

Hi Fred,

I checked, and PasEnvLoadFile is a wrapper around envLoadFile, and is loading the .cdsenv file in the root of your PDK library. I tried an example I had which has this construct using IC617 ISR19 and that works fine - no errors in "si" when doing CDL netlisting.

When I get into the office today, I'll check again with ISR12.

However, I see that you've now logged a case with customer support, so probably best to avoid duplication of effort and let the AE who gets assigned this work through the problem.

Regards,

Andrew.

Andrew,

Did you enable CDS_FILTER_CDSENV_WARNINGS ?

If we can get workaround here, I will ask to close that case. And I will avoid such duplication in future.

Thanks for your kind help.

Fred

Hi Fred,

zssfred said:

Did you enable CDS_FILTER_CDSENV_WARNINGS ?

No, should I have done? You didn't mention it before. I tried in ISR19 with and without this env var (set to "yes"), and it made no difference - I still don't see the undefined function message.

A workaround would almost certainly be to put this in the libInit.il before the PasEnvLoadFile call somewhere (although we really should fix the underlying problem if there is still one in current ISRs):

unless(isCallable('uiLoadTrigger)
  procedure(uiLoadTrigger() t)
)

Regards,

Andrew.

Andrew,

No, I did not. I just recalled this envvar setting when I replied last post.

Your hacking works well in my test. But not sure whether if really helps to solidify the .cdsenv setting on purpose in gui layout mode.

In si batch mode, the ui triggers should be irrelevant, I think.

Anyway, I will try isr19 after the long time of downloading.

BTW, may I have your email? The AE already sent mail to me and I can add you into the loop.

Thanks.

Fred

Hi Fred,

I checked with ISR12 and couldn't see the problem. However, I checked again and realised that I'd looked at the wrong .cdsenv file and so it didn't have any ui entries. When I added those into the .cdsenv file inside the library containing the PasEnvLoadFile call in the libInit.il then I see the problem in IC617 ISR12 and ISR19. 

This is what should be fixed. However, I can't really see any good reason why a PDK should be setting ui cdsenv settings - look in the file in the library for anything such as:

ui accelInput boolean nil
ui focusToFieldSelectsText boolean t

anything with ui at the beginning. It's a strange thing for a PDK to set, in my opinion.

The workaround code I gave should be harmless. In an environment that supports a user interface, it won't do anything, and in executables such as "si", it just prevents the ui trigger from failing (there's nothing the ui trigger could usefully do anyway).

No need for me to provide my email address (I certainly wouldn't in a public forum anyway) - please provide this info to my colleague that you're working with and they can file a CCR to get this addressed. I'm in the loop on too many things already - so can afford to not be included on this one! (although maybe the AE you're working with can put me on cc for the CCR they file so I can see it).

Regards,

Andrew.

Andrew,

The purpose why we use .cdsenv in a PDK is to enable stretchable handler if we just merely provide PDK library to users. It looks like this way won't work at all.

We have to still suggest users to load .cdsenv via .cdsinit. That should be a working way, right?

I will forward your post to the AE.

Thank you so much!

Fred

Hi Fred,

There's no problem with setting .cdsenv variables as whole - it's specifically any "ui" variables in the .cdsenv file that cause the problem. I'm not sure what  you mean by "stretchable handler" but I don't think that's a "ui" cdsenv variable. If you don't have ui variables in the .cdsenv file loaded from libInit.il then you won't hit this bug.

Regards,

Andrew.

Andrew,

Andrew Beckett said:

I'm not sure what  you mean by "stretchable handler"

"stretchable handler" means Options->display->"Stretch Handles".

Is it a ui trigger?

Thanks.

Fred

No, that's

layout displayStretchHandles boolean t

As I said, the issue is caused by any variable in the .cdsenv file which has "ui" as the first word on the line. Presumably you have some of these?

Regards,

Andrew.

No, that's

layout displayStretchHandles boolean t

As I said, the issue is caused by any variable in the .cdsenv file which has "ui" as the first word on the line. Presumably you have some of these?

Regards,

Andrew.

If you choose to save to ~/.cdsenv in "Display Options", you will see lots of  "ui".

Thanks.

Fred

zssfred said:

If you choose to save to ~/.cdsenv in "Display Options", you will see lots of  "ui".

That doesn't mean they're anything to do with the layout editor though. It saves all loaded variable partitions, and of course the ui has already been loaded at virtuoso startup. I'd remove them from the file if they're not needed - in general, I'd say that a PDK should limit the user preferences it enforces to just those strictly necessary, as otherwise the user's personal preferences get overridden by those from the PDK. So some care should be taken on the choice of which variables to set in the PDK.

Regards,

Andrew.

Instead we want to unify the user preferences for harmony interoperability and communication and better efficiency needed by whole team’s productivity. That is another philosophy though it inccurs habbit challenge in the very beginning. Agree to remove these “ui” entries if they cause errors. But where can I find the documents about them?  At least, I can’t find any about uiLoadTrigger...

Thanks.

Fred

Hi Fred,

More details on the "ui" env vars can be found easily in the documentation. For a start, most of them arise from the Options->User Preferences in the CIW - so hit Help on that form and it takes you to the relevant document (chapter 6 Customizing Your Design Environment in current versions of the Virtuoso Design Environment User Guide manual). If  you search through that chapter for .cdsenv there are various links to specifying parts of the form using cdsenv which take you to sections of Chapter 7, Specifying Environment Settings - this covers the ui variables in detail.

You will not find anything on uiLoadTrigger. This is a private (internal) function which is triggered when the cdsenv is loaded containing "ui" entries and takes care of synchronising the UI-related forms (such as the User Preferences and Log Filter forms). You would never call it yourself - it only shows up because of this bug where it is attempting to call the function in an environment where it isn't defined.

Whilst I completely understand about unifying user preferences, I don't think doing this via the libInit.il is a good idea. Some of the user preferences are indeed user preferences and don't necessarily impact cross-usage efficiency. By setting them in the libInit.il, you rob the user of the ability to customise them personally. What I would do is set the things that truly are technology-specific there (e.g. default snap spacings, what the default multi-part path template is, that kind of thing), but other unified preferences I would set via a central .cdsenv file which is loaded at startup (probably via the CSF - Cadence Search File mechanism). That allows users to inherit the default settings and most likely use them, but still gives the ability to override them if they want to. The disadvantage of doing this in the libInit.il is that the file is loaded the first time you access the technology library - which will override anything you have previously set in the environment.

Of course, this depends on how much a company wants to force how individual users work. My experience is that users vary considerably and forcing everyone to adopt the same settings for absolutely everything tends to lead to frustration. I've seen this in PDKs in the past where completely different bindkeys were loaded - and the PDK was being provided outside the company that created it; we were always being asked how to stop those bindkeys from being redefined every time they used that PDK.

Regards,

Andrew.

Andrew Beckett said:

More details on the "ui" env vars can be found easily in the documentation. For a start, most of them arise from the Options->User Preferences in the CIW - so hit Help on that form and it takes you to the relevant document (chapter 6 Customizing Your Design Environment in current versions of the Virtuoso Design Environment User Guide manual). If  you search through that chapter for .cdsenv there are various links to specifying parts of the form using cdsenv which take you to sections of Chapter 7, Specifying Environment Settings - this covers the ui variables in detail.

The issue here is there are two "Options" menus -- one in CIW and the other in Layout window. It looks like the settings in "Options" menu in layout window won't yield lines beginning with "ui" if you choose to save them to a file. But now it will save all the settings of whole virtuoso environment including the ones from the "Option" menu in CIW. The ideal design should be just saving all what you are seeing not the whole universe. And users can combine or concatenate different parts by themselves.

Andrew Beckett said:

You will not find anything on uiLoadTrigger. This is a private (internal) function which is triggered when the cdsenv is loaded containing "ui" entries and takes care of synchronising the UI-related forms (such as the User Preferences and Log Filter forms). You would never call it yourself - it only shows up because of this bug where it is attempting to call the function in an environment where it isn't defined.

And is it possible to indicate it is a cadence-internal function by some symbol or hints? It took me too long time in debugging after assuming it is user-defined or PDK-defined function. In my experience, it is really rare to meet cadence-internal function.

Andrew Beckett said:

My experience is that users vary considerably and forcing everyone to adopt the same settings for absolutely everything tends to lead to frustration. I've seen this in PDKs in the past where completely different bindkeys were loaded - and the PDK was being provided outside the company that created it; we were always being asked how to stop those bindkeys from being redefined every time they used that PDK.

Instead we prefer the absolute uniform for we only use this PDK internally. We have seen lots of headache when different people use different color and bindkey and

dislay-setting etc in collaboration like meeting or co-debugging in one cube.

Thanks.

Fred

Fred,

There are several Options menus (in schematic, layout, layout XL, ADE XL, CIW) and places where cdsenv can be saved. The CIW has Options->Save Defaults which gives more control over which partitions get saved, but the others (such as those in the layout options menus) are trying to avoid you losing stuff if you overwrite an existing file. Giving all the flexibility of the Options->Save Defaults on every form would just over-complicate things.

zssfred said:

And is it possible to indicate it is a cadence-internal function by some symbol or hints?

Nowadays (since about IC442 timeframe - so the last 19 years or so) we've had a much stricter rule that newly created internal (private) functions have an underscore at the beginning. There are a few exceptions here and there, and certainly anything older does not necessarily follow this rule (we were not going to risk destabilising the code by renaming lots of functions). In general though, we recommend that customer code uses a prefix that begins with an uppercase letter, and we use lowercase prefixes. Anything that is not in cdsFinder (with a small number of exceptions) is private - although of course it could be a user-defined function that is not following the naming convention.

Bugs happen though - I'm glad that a CCR to get this fixed has been filed now. I'm sure contacting customer support would have saved you the time in trying to track this down...

Regards,

Andrew.

Andrew,

Amazing, you always promptly respond! Need you sleep?( joking, :-) never mind.)

Monolithic cdsenv file is easy to save but hard to trim. It is just a trade-off.

It is not simple for people not like you guru to map the lines in cdsenv file to the visual presentations in form/menu.

As for function naming convention, I already add our company's name in upper case as prefix. But that is only guaranteed in my code. :-(.

Hope I can be updated about the progress of this CCR.

Many thanks for your kind help!

Fred