load a skill into the terminal

Hi,

I'm not entirely sure I understand your question, but I'm assuming that you want a DFII session to read a SKILL syntax file from the command line.  One way to do this is to use the "-restore" command line option:

 -restore filename   Restores a saved session from filename.

E.g.

icfb -restore toto.il

Or you can read in SKILL in the .cdsinit file.  Or maybe you are trying to read SKILL syntax at a unix-like prompt?  There is the executable "skill" which when started gives you a prompt and accepts SKILL syntaxbut it does not contain all of the contexts that are loaded in icfb, icms etc. so it will not understand db*, le*, or sch* functions etc. Of course you could also starticfb etc. without graphics which will also give you a command line prompt in your terminal, for example:

 icfb -nograph

I don't think that you can pipe SKILL commands at the command line prompt into a DFII executable (if this is what you are trying to do?), but you can start an external process from within DFII and communicate with it.  Here you would use the ipcBeginProcess and other ipc* prefix functions for 2-directional communication.

If this is not what you are looking for, please re-word your  request and try again.

Hope it helps.

I know the command restore, but it's to load a skill at the startup of icfb.

In my flow, i have to execute some commands to store some view ... and i will automatized them, so i have to

launch this command by a script at any time and not at the startup.

Nobody use this ?

 If i am not clear, please tell me ;-)

I am not familiar with what you are describing, but let me suggest two things you can try.

hiRegTimer(t_callbackString x_tenthsofSeconds)

This command allows you to register a Skill function to be run after a specified amount of time. If you search SourceLink for this command you should be able to find a sample routine that allows you to create a "scheduler" for running commands in the future, even repetitively. If you are trying to save data on a regular basis, you could use this to run some command 500 seconds in the future and then the command itself could call hiRegTimer again to run 500 seconds later.

If you are looking for an "auto save" type feature, you should checkout dbSetAutoSave.

Finally, the ipcSkillProcess command allows you to initiate a shell script that can write back information through a Unix file descriptor to the Cadence process that started it.

I hope this helps.
-Derek

 Also take a look at the dbRegPostSaveTrigger(), ddRegTrigger() and deRegUserTriggers() functions.  You can use those to execute custom code when certain events happen, such as when a schematic/symbol is saved, a ddObj is manipulated, etc.

Andrew. 

Thanks Derek & Andrew,

This could be a possibility, but my script is very complex in tcl wish made some layout update, when a user execute it. And for the moment, the skill neded is written in a file and the prompt say to the user, please load( "toto.il"), i just want to make it automatically by the script. "toto.il" has not all time the same syntax, so it's very difficult to use the comand skill given in the latest posts. 

At the moment, i have found a trick, i launch icfb with the command

icfb -restore my_startup.il &

 and in my_startup.il, i define some variables command1 = "load1.il", ..., ... At the end my tcl script could execute the command into the terminal:

echo "(load command1) | OpusClient

It's not very Good, but for the moment it's work ... :p

I think, this chalenge will interessed you... ;-)

Thanks. 

Remi

One approach may be to launch the tcl script/process from within virtuoso using the ipcBeginProcess command.  Then use ipcReadProcess to read output from the tcl process, whether it be SKILL code to execute directly or just a file name to load in.

 Andrew.

 Hi Remi,

Andrew's suggestion is a good one that I have had success with in the past.  The DFII session is the 'master' which starts the external tcl/wish process using ipcBeginProcess() . At this point you can choose either synchronous or asynchronous communication depending on your needs.

For example, with synchronous communication, you start the external script, wait for it to complete (effectively blocking the DFII session) and then the user can continue working after the external script is done.

With asynchronous communication you run the external script and effectively the communications occur in the background. This might be a little more complex but it gives greater flexibility. You define a data handler and an error handler, for example, to handle messages coming from the external process on stdout and stderr respectively. This also means that the DFII session will not be blocked, it can be used for other things while the 'slave' script is processing.

This method will allow you flexibility to automate things on the DFII side also, for example, when something arrives from the script on the data handler, it can process the data according to what you want to do.  For example, you might have:

 msg: "Missing data, try again"

cmd: load("toto.il")

So depending on the first item, the action might be to print a message, or to execute an action. You have control over the format and the communication "protocol" so make it fit your needs, the above is just a suggestion.

 Hope this helps!

Regards,

Lawrence.