a mARTIAN dIARY

NRE - Non Recurring Cost In the electronics industry (or any industry for that matter), is the one time cost involved in developing a product. for example NRE’s are obviously higher for ASIC’s than FPGA’s. 

MOQ - Minimum Order Quantity The minimum quantity of a product that must be sold so that the project breaks even. When NRE is high MOQ also becomes high.

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

False paths are that do not propagate signals events. It usually because the convergence of fan-out to surrounding logic such as the select line in the picture. Since there will be no signal propagation through a false path, it need not be considered while doing timing analysis or optimization.
Some example includes -:

• As in the example shown above, the longest path (6ns) is never excited and the critical path (4ns) of this combination logic gives is less than that.
• Another case maybe when, even if a signal propagation is possible, it might never be excited by the logic , say a logic excited by a don’t care state in a state machine.
• Paths between any two asynchronous clocks.

Multicycle paths are paths which take more than a single cycle. The Tools by default , takes all the paths to be single cycle operation . So they need to be ignored too.

The above are due to structural. Another case is when a path is contributed by a test mode. Since we might be running test modes at lower speeds and they are never excited in normal mode, they can be ignored during timing analysis

Reference
Logic Synthesis and Verification  by Soha Hassoun, Tsutomu Sasao

This is my humble attempt to document at a single place what has transpired at a single location in the industry that feeds me today. Why you would ask. Read on.

To understand a business it is first necessary to know and more importantly understand its history but more importantly for a typical Scorpio like me, passion is a large part of the juice that drives me and in my opinion, a true sense of history is exactly the fuel that’s required to pump up the juices.

Having arrived a little late into the industry has its own advantages and disadvantages. The sloth in me is happy for I have but to type a single stroke or click a single click to do things that would have taken my pioneers 10s and maybe hundreds of man-hours. The pessimist in me is disappointed that I have walked into a mature industry with no scope of innovation. “Slaves of Tools”. This reminds me of one of my college seniors, who was a MVP (Microsoft Valued Professional) , write with contempt of his Linux slanted counter parts “why should I spend 100 hrs trying to debug a error most people wont even notice and  with the end result being 1 line of code added to 1000000s of lines already present?”. On the surface this is quite true but where is the sense of history there? The one line you add is going to sit itself to history with a line that Linus Toward or Saint INGUcius himself had written. Now isn’t that worth some, if not, lot of you time?

Some people had scared me coming into the industry, that I would be stuck to a tool, to a company, to a flow stuck so much that my carrier graph may get linked to the P/E graph of the company. Having just got out of college ,this was very distressing at first to be stuck to some thing. Bloody hell, part of the  reason I did not choose a software profession was not to be “JAVAised” or “MSised”. In hindsight it seems like a right decision take for the completely wrong reasons. I love being an electronic tool engineer. It helps me leverage on both of decent knowledge of electronics and good way with tools. For, as I found out, Innovation is a funny thing. An industry being mature does not mean that there are no more challenges. It just means that most of the lesser challenges have been sorted out and it’s up to you to figure out the hidden challenges and then solve them. So in a way it’s more challenging, cuz its up to you to identify the challenge, which in itself is a challenge. The only thing now missing for me in this industry is a proper sense of history I use proper since the habit of googling everything and anything that I encountered has led my temp cache to be filled with junk from all types of sites, during the course leading me to some history related sites. Since I need to justify the money that MindTree is paying me this search is going to be an ongoing process and I plan to publish the history in parts as and when I understand/ know about them and then later edit them to a complete document with flow….

And he said…..let there be light

Back in 1986, Dr Tsugio Makimoto, then of Sony, made an observation about how the industry appeared like a pendulum swinging between standardization and customization. Each complete swing of the pendulum appeared to take about 20 years. This is now commonly known as Makimoto’s wave