C
cafm
Guest
Hi guys
I had posted this a while back on comp.cad.cadance but got no reponse.
Thought I would repost once more. Hoping for some suggestions
-----------------------------------------------------------------------------------
HI guys
I am a novice electronics enginner currently working on DFT ans
sythesys. When I came in from college the one thing I though would
have help me in the industry was some more experience with scripting.
I had fed this back to my college juniors and they have started up on
that. Recently they ask me if i could document some best practicies
for writing scripts in the EDA industry and I came up the the
following article. before I send this to my juniors I would be much
obliged if you guys could take a look at it and critisize/review it.
Please do keep in mind that this is meant for novice engineers like
me
and other coming in from college.
Thanks in advance
(This can also be found at my blog at )
http://olympusmons.blogsome.com/2007/03/08/flops-and-scripts/
--------------------------------------------------------------------------------------
Here are some rules that I think make a good script be it in simple
shell or perl or other fancy languages.
So here goes....
ˇ Be Verbose Internally
Usually being loud mouthed and blowing your trumpet is something that
is cherished by most nerds but what to do, unfortunately its not
considered very professional, so you either wait for some else to
realise how ingeniously you have solved a problem or sad for one day
at the fact that that's one more piece of sheer brilliance not
recognized anf get on with you life. BUT coding lets you do exactly
the opposite....Even though it's the most commonly used
"yada...yada...yada"
about writing any script or program me thinks it's still not
emphasized enough......USE COMMENTS! On the other hand you might be
a
brilliant coder and don't care what other think, and of course you
might not want other to use your code >....but think of this, you
might need to use/modify after N days....and trust me its work that
extra 30% effort in writing comments will help save a 1000% effort
that might be needed to understand the script again
ˇ ...Externally...
Lets face it, command line scripting is not exactly a eye candy for
the user but still it is used since it serves purpose but say the
script starts executing. It has to execute 10 steps(think as separate
tool invocation) each of varying time. Once invoked the script and
the
shell go into a world their own with out printing out anything while
the invoker is biting his nails trying to figure out what the hell is
heppening? Did it crash? Has it gone to an infinite loop? ...once
done
the script may cleanly exit but by that time the invoker could have
had a heart attract, that is if he is able to resist the temptation
of
CTRL-C that is... But if the script would report or just sprout out
"Level n complete...." with the odd echo command after each step,
with
maybe a small statistics/summary of the last step run, we can save
some time from the reruns or maybe even some money for the medial
insurance company
ˇ /dev/null redirection
Just like too much of a good dish is poison; similarly it's a good
practice to use the /dev/null redirection wisely. There is no use
sprouting out 100 lines per second to the screen if the user is not
going to be able to read even one line is it? Say the script invokes
multiple tools in its flow and you know that the tool anyway saves
what ever it prints to a log file which the user can access once the
run is finishes then we can safely redirect the tool output to /dev/
null to avoid the user a headache. if the log file is not
automatically created, it would be useful r to redirect it to a log
file (and not the screen) unless you have specific reasons to keep
the
log file from being read
And if you are one of the perfectionist coders then you can go ahead
and grep some of the final results of the log file to the screen
while
the next process is being done.
ˇ Usage Check /function
Generally scripts are written to automate tasks, and most scripts do
take some arguments to provide some flexibility or extendibility to
their usage. 9 times out of 10 the script will be reused by someone
else. So if you were to leave the usage information (invocation
format ) hidden deep inside the code, the scripts usability is
greatly
reduced (unless of course you do 24 hour customer service for it) so
its advisable to always do some usage checks like for the correct
number of arguments, proper switches etc and also a sample usage
example to dump out when the usage is wrong. This can be a separate
function to not interfere with you "actual code"
ˇ Error Warning
Of course while running the scripts some errors are bound to happen
or
you might want to give some info to the user that must be easily
filtered out from the rest of the output. Its always better to use a
separate function to print the errors and warnings with a
Error: Error details Or Info: Info details so that it can easily be
searched for in the log file or grep`ed to a separate file. Also
using
a common function to report errors can help keep a count of the
errors
and related fail safe mechanisms
ˇ Exit function
If the script is long and good you might be exiting from different
locations under different conditions, so it would be good to have a
single exit function which is "aware" of global variable like error
count etc and exits using a standard mechanism, generating a small
concise report regarding the run
ˇ Log file
You might for a highly verbose script but it will be useless if the
run is too fast or the user is distracted during the run. There needs
to be a mechanism to be able to generate a log file of the output
during the run. The user can always "tee" the output to a log file
but
if you can generate a default log file that would be good
{
#code here
} | tee script.log
ˇ Modularize
If you write a lot of scripts or even not, its always to modularize
the code so that it can be
1) Easy to maintain
2) Easy to reuse
That's about what I can think of right now...
Statutory warning
I have written them with a electronic engineer's....hmm no....a EDA
tool
engineer's perspective. I think that this would be mostly translate
to
same in other uses of script.These are not exactly hard and fast
rules
and the relevant would depend on various parameters like
functionality, length etc of the script being written. I am greatly
indebted by the information that was passed to be by other
experienced
engineers in my team and hope that this is a good read for any novice
writing scripts for the EDA industry. If I have missed out anything
please do not hesitate to leave a comment
I had posted this a while back on comp.cad.cadance but got no reponse.
Thought I would repost once more. Hoping for some suggestions
-----------------------------------------------------------------------------------
HI guys
I am a novice electronics enginner currently working on DFT ans
sythesys. When I came in from college the one thing I though would
have help me in the industry was some more experience with scripting.
I had fed this back to my college juniors and they have started up on
that. Recently they ask me if i could document some best practicies
for writing scripts in the EDA industry and I came up the the
following article. before I send this to my juniors I would be much
obliged if you guys could take a look at it and critisize/review it.
Please do keep in mind that this is meant for novice engineers like
me
and other coming in from college.
Thanks in advance
(This can also be found at my blog at )
http://olympusmons.blogsome.com/2007/03/08/flops-and-scripts/
--------------------------------------------------------------------------------------
Here are some rules that I think make a good script be it in simple
shell or perl or other fancy languages.
So here goes....
ˇ Be Verbose Internally
Usually being loud mouthed and blowing your trumpet is something that
is cherished by most nerds but what to do, unfortunately its not
considered very professional, so you either wait for some else to
realise how ingeniously you have solved a problem or sad for one day
at the fact that that's one more piece of sheer brilliance not
recognized anf get on with you life. BUT coding lets you do exactly
the opposite....Even though it's the most commonly used
"yada...yada...yada"
about writing any script or program me thinks it's still not
emphasized enough......USE COMMENTS! On the other hand you might be
a
brilliant coder and don't care what other think, and of course you
might not want other to use your code >
....but think of this, youmight need to use/modify after N days....and trust me its work that
extra 30% effort in writing comments will help save a 1000% effort
that might be needed to understand the script again
ˇ ...Externally...
Lets face it, command line scripting is not exactly a eye candy for
the user but still it is used since it serves purpose but say the
script starts executing. It has to execute 10 steps(think as separate
tool invocation) each of varying time. Once invoked the script and
the
shell go into a world their own with out printing out anything while
the invoker is biting his nails trying to figure out what the hell is
heppening? Did it crash? Has it gone to an infinite loop? ...once
done
the script may cleanly exit but by that time the invoker could have
had a heart attract, that is if he is able to resist the temptation
of
CTRL-C that is... But if the script would report or just sprout out
"Level n complete...." with the odd echo command after each step,
with
maybe a small statistics/summary of the last step run, we can save
some time from the reruns or maybe even some money for the medial
insurance company
ˇ /dev/null redirection
Just like too much of a good dish is poison; similarly it's a good
practice to use the /dev/null redirection wisely. There is no use
sprouting out 100 lines per second to the screen if the user is not
going to be able to read even one line is it? Say the script invokes
multiple tools in its flow and you know that the tool anyway saves
what ever it prints to a log file which the user can access once the
run is finishes then we can safely redirect the tool output to /dev/
null to avoid the user a headache. if the log file is not
automatically created, it would be useful r to redirect it to a log
file (and not the screen) unless you have specific reasons to keep
the
log file from being read
And if you are one of the perfectionist coders then you can go ahead
and grep some of the final results of the log file to the screen
while
the next process is being done.
ˇ Usage Check /function
Generally scripts are written to automate tasks, and most scripts do
take some arguments to provide some flexibility or extendibility to
their usage. 9 times out of 10 the script will be reused by someone
else. So if you were to leave the usage information (invocation
format ) hidden deep inside the code, the scripts usability is
greatly
reduced (unless of course you do 24 hour customer service for it) so
its advisable to always do some usage checks like for the correct
number of arguments, proper switches etc and also a sample usage
example to dump out when the usage is wrong. This can be a separate
function to not interfere with you "actual code"
ˇ Error Warning
Of course while running the scripts some errors are bound to happen
or
you might want to give some info to the user that must be easily
filtered out from the rest of the output. Its always better to use a
separate function to print the errors and warnings with a
Error: Error details Or Info: Info details so that it can easily be
searched for in the log file or grep`ed to a separate file. Also
using
a common function to report errors can help keep a count of the
errors
and related fail safe mechanisms
ˇ Exit function
If the script is long and good you might be exiting from different
locations under different conditions, so it would be good to have a
single exit function which is "aware" of global variable like error
count etc and exits using a standard mechanism, generating a small
concise report regarding the run
ˇ Log file
You might for a highly verbose script but it will be useless if the
run is too fast or the user is distracted during the run. There needs
to be a mechanism to be able to generate a log file of the output
during the run. The user can always "tee" the output to a log file
but
if you can generate a default log file that would be good
{
#code here
} | tee script.log
ˇ Modularize
If you write a lot of scripts or even not, its always to modularize
the code so that it can be
1) Easy to maintain
2) Easy to reuse
That's about what I can think of right now...
Statutory warning
I have written them with a electronic engineer's....hmm no....a EDA
tool
engineer's perspective. I think that this would be mostly translate
to
same in other uses of script.These are not exactly hard and fast
rules
and the relevant would depend on various parameters like
functionality, length etc of the script being written. I am greatly
indebted by the information that was passed to be by other
experienced
engineers in my team and hope that this is a good read for any novice
writing scripts for the EDA industry. If I have missed out anything
please do not hesitate to leave a comment