Passing parameters into an ocean script...

The simplest way is to set a UNIX environment variable before the code is loaded, and then you can use getShellEnvVar("CELLNAME") or whatever from within the OCEAN script.

Regards,

Andrew.

Thanks Andrew. Please don't take this personally, but IMHO that's got "hack" written all over it.

Is it worth logging a request to allow ocean scripts run from the command line to allow passed parameters, or is that just a lost cause? Another possible thought - can an ocean script pause to accept a user input in response to a generated prompt and take that answer to modify the program flow? I usually don't like doing such things because the pausing for a response means the script can't be run in a regression suite- although in that case your suggestion would work).

I agree it's a bit of a kludge. There's a function in SKILL called argv() but this doesn't work with "ocean" or "virtuoso" - but I think it's reasonable that there ought to be a way of getting the command line arguments passed in so that you could do:

ocean -restore yourCode.ocn mylib mycell myview

and then retrieve these additional arguments somehow. So yes, go ahead and file a support request so that we can get this into R&D.

You could potentially use gets() to read from standard input, but I'm not sure how well that would work (I've never tried it with ocean).

Regards,

Andrew.

Thanks - I'll file that support request. In the meantime, I did try embedding a gets() command within my ocean script but the program just marched right past it and kept going to the end of the script :-(.

Another thought. I might just make 3 small "header" ocean scripts that basically just specify the schematic to simulate and then call a core ocean script to put the circuit through its paces and plot the results. How does one ocean script call (or jump to) another?

What I'd do is wrap your common code in a function definition:

procedure(MyCommonOCEAN(lib cell view)
   ...
   ...
   ; the ocean code you had originally

)

Then in the three scripts, do:

load("commonCode.ocn")
MyCommonOCEAN("mylib" "mycell" "schematic")

or similar - that way you are cleanly communicating with the common code. Then you can just do "ocean -restore file1.ocn" or "ocean -restore file2.ocn" to run the individual variant.

Regards,

Andrew.

Thanks Andrew. Your example just made me think of something. I'm at home so I can't try this out, but rather than having 3 separate "header" scripts and a common code script, why couldn't I just write *everything* as a single procedure. All I'd have to do is load it first and then I could just invoke the procedure and pass all the parameters I want that way. It is a two step process (for the first run only), but it's only one file to worry about... 

Yes, that would work, of course.

Andrew.