Murphy's Law

Well many times few things have gone bad. But they never really came close to being tagged as Murphy's law experience. But here is the one that happened on  16 June 2011 really came out as classic example.

15 June 2011 was one of the longest lunar eclipse night. I was awake till 4 AM. Catched some 4 Hrs sleep and got up at 8 AM on this D-day of 16 June. As it was late decided to take my car to office instead of office transport.

Reached office at about 10:30 AM. Had pretty much regular day and started back from office at about
8:30 PM. I was really tired due to night out and wanted to get back home quick. Started back with one of another colleague who was heading in the same direction in his car. Just after about 15 minutes travel one of the front tire went flat. You quite expected it right ? No..No...this is not it just read ahead and see what unfolds.

I had never dealt with flat tire before so I thought, I could quickly call and stop my friend in another car just ahead of me for help. That's when I realized my mobile had completely drained off and had switched off. It was lying there unaware of fact that my first help has gone off and I cant even inform back home.

It was for last couple of days, I was thinking of taking out the cash from ATM but had not done it yet. Checked my valet there were just thirty rupees in all. Fine, I said to myself turned on car's emergency lights. Parked by the road side. Started taking a walk around. Quickly spotted a small Maurti Service centre. I was really happy initially but to my disappointment the guard said all the staff has left. He pointed me towards road where I can find more garages. I quickly checked time it was 9 PM already so rushed to that street. Another disappointment all those small garages had already closed.

But fortunately I found a ATM and took out some cash. There on decided to catch a Auto driver to help me fix it. I found couple of guys and they agreed. They came to place where I had parked the car and started the work on the replacing the flat tire. To my surprise I found that tools were not returned to me during the last car service.

Fine, I said to myself and stopped taxiwala who was passing by and asked if he could spare the tools. Although that guy was good he said well TATA Indica tools wont work on Maurti. There on like Vikram of Vikram-Betal, I started looking around the houses to see who has Maurti car parked. Found the nearest one and requested security of that house to get me the tools after explaining the situation. My watch was already clocked 9:30 PM. Land lord lady was kind and she gave the tool set to security who accompanied me. The autowala's managed to replace my flat tire.

Do you think its end yet. Not there is still small part left. I had to reward my star team. I could pay some twenty rupees to security and asked him to thank land lord lady on my behalf. But I just realized ATM had given all 500s new notes. They smiled at me. I asked autowala's they had no change. Checked with the nearest grocery store and medical shops who were about to close for change. You guessed it right they politely refused. There was Bar near by. Figured these are rich people and checked with them. Bang ! got the change. Quickly settled the account of Autowala's.

Just smiled at myself on what had unfolded in last 1 hour 30 mins. Headed back to home to reach at 11 PM completely exhausted.

I had experienced the Murphy's law first hand.

"If there is a possibility of several things going wrong, the one that will cause the most damage will be the one to go wrong." - Murphy

Debugging in the System Verilog/VMM Constrained Random Verification[CRV] test benches

70 % of asic design goes in verification and 70 % of verification goes in debugging.

Planning for the debugging goes a long way. Feature by feature the way we architect the test bench pay some attention as to how will it be debugged. This strategy will pay back heavily.

One old principle is don't forget the basics. Understand the ground rules well.

In verification ground rule is generate the stimulus and check the response. That's it.

In the directed case it would be evident just by reading the test source code.

The same is not true when one looks at the the CRV test benches. Although the ground rule is still the same.

Well debugging the CRV test benches is little different ball game. Now one needs to figure out the stimulus  generated from the test logs. There is no source code to refer on the lines of directed case.

I am not going to talk about technicals of the vmm_logs. May be I will put a word or two as to what customization can be done to make it more effective.

0. Usage for the Logs is they are 90 % of time grepped and not read line by line. So design the regular
expression friendly logging messages.

1. Just because they are grepped does not give you a license to go wild and print the universe. Follow
some good logging etiquette. Well formatted information is worth the time spent in putting up the format.
Address map, details of transactions, configurations needs be formatted to ease the read.

2. Implement intent driven logging macros. Intent driven macros could distinguish between the messages
that give out information about specification, implementation, test bench specific etc. This can help in debugging across teams. Lets look at a case where the unit test bench gets ported to system.System team might just be interested in the messages that give out the spec information and they may not be interested in the test bench specific messages. So it would be good to have this control.

3. With the vmm logging macros tend to print out multi line messages. Do customization to make them
single line. Also group the related multiple lines that need to go together in a string data type and print it out with the single call to messaging macro. While built in vmm component logging is useful it can be big distraction and can increase your log file sizes beyond wave dumps. So have knobs to turn off this internal logging and enable only your own TB logging or together.

4. It should be very straight forward to find out the stimulus generated and the response given out by the DUT. VMM test benches heavily utilize the concept of the transaction and transactor. Transaction go via
the channels. The built in logging of the channels puts out messages about transaction being added/removed.
This can be very informative for the stimulus and response extraction.

5. Debug messages cannot be put just for the sake of it. There needs to two views that needs balanced.
One is being able to have as complete information as possible being available in the logs when the highest
verbosity is enabled but the second one is ease of localizing the issue using a question/answer/elimination.

Few simple quick information to help ruling out the basic issues. There on eliminations. First one is : Is it
really a RTL or test bench issue. If its test bench issue then it should answer is it originating in generator, transactor, BFM, score board, driver, checker etc

6. For TB issues after its localized to a component put enough information to be able to figure out what is the state of different threads in the component. If its waiting for some event it will go a long way to put that debug message as to what it is waiting for.

7. End of test itself can be multi phased. Put enough information to indicate as to which phase of end of test is being waited on.

8. Even when its closed as RTL issue messages need to be clear enough to convince the designer. It should be easy enough to give the picture of scenario as designer would imagine.

9. Build the set of frequently used regular expressions and use the egrep to find out the complete sequence of event that took place. This bigger picture is very vital.

10. Have a easy mechanism to identify the requests and corresponding response. For the buses that allow
multiple outstanding requests and allows out of order completion it goes a long way to build this
identification mechanism. Even though the bus may have some id mechanism of the transactions as they get reused it might be tough to debug. Go ahead and add TB id for the transaction as well that is unique throughout the sims and map the completions on to this ID and it greatly ease the debug.

11. Don't plan to debug everything using logs and thus put everything in logs. Plan on using the single
stepping/watch capabilities of simulators. Synopsys DVE works great for the test bench debugs. This step means extra time but trying to solve all debugging needs using logs would reduce the logging efficiency.

12. Put enough note verbosity message to be able to figure out the timestamp from where the dumps needs to be started and if you can decide if the dumps are needed that would be great.


Test Bench issue Preventions:

0. Go defensive and be paranoid in terms of coding. Next time you are 100 % sure to find the element you are going to look for in the queue where you are tracking transaction completion still add an fatal error statement if its not found. These checks go a long way in catching the issue at root. Otherwise these can morph in to very tricky failures.

1. Having lots of failure with the similar error message but for a different causes is an indication of more granular checks are needed. More granular checks make it easier to debug.

2. Pay attention while doing copy/paste to avoid those extra compile cycles and painful debug cycles.

3. One aspect that is different coding in SV compared to C/C++ is the time dimension. Be aware that
hardware interfaces are parallel while something is being processed at one interface there can be activity on the other interfaces as well. This thought process can save you from normal items that come in as a part of dependency but also take care of race conditions.

4. Multiple threads accessing the shared resources is one more issue. While one writes the code it might be tough to imagine the concurrency of threads. Build your own way to imagine this concurrency and put the
needed protection of the semaphores.

5. Zero time execution is another trap. Beware the vmm_channel put and get are blocking. What it means
is on every channel put/get the scheduling coin gets tossed again. All the contesting threads get a  chance to compete and execute. While in your head you may be thinking of only the two components connected by channel to be active but its not true other components can also get a chance.

ಅಳುವುದೊ ನಗುವುದೊ ನೀವೇ ಹೇಳಿ ?

೨೨ ಮೇ ೨೦೧೧ ರವಿವಾರ "ನಂಗೆ ಇಷ್ಟಾನೋ" ವಿಶ್ವೇಶ್ವರ ಭಟ್ಟರ ಅಂಕಣದಲ್ಲಿ "Brilliant ಉತ್ತರ ಬರೆದರೂ ಹೀಗಾ ?" ಎಂಬ ಶೀರ್ಷಿಕೆ ಅಡಿಯಲ್ಲಿ ಕೇಳಿದ ಕೆಲ ಪ್ರಶ್ನೆ ಹಾಗೂ ಉತ್ತರ ಹೀಗಿದೆ.

ಪ್ರಶ್ನೆ : ಟಿಪ್ಪು ಸುಲ್ತಾನ ಯಾವ ಕಾಳಗದಲ್ಲಿ ಮಡಿದ ?
ಉತ್ತರ: ಕೊನೆ ಕಾಳಗದಲ್ಲಿ

ಪ್ರಶ್ನೆ : ಸ್ವಾತಂತ್ರ್ಯ ಘೋಷಣೆಗೆ ಸಹಿ ಹಾಕಿದ್ದು ಎಲ್ಲಿ ?
ಉತ್ತರ:  ಕಾಗದ ಕೊನೆಯಲ್ಲಿ

ಇಲ್ಲಿ ಏನೋ ಭಟ್ಟರು ಎತ್ತಿ ತೋರಿಸಿ ಹಾಸ್ಯ ಮಾಡಿದ್ದಾರೆ. ಕೆಲ ಸಂಕೀರ್ಣ ಪ್ರಶ್ನೆಗಳಿಗೆ ಹೀಗೆ ಸರಿಯಾಗಿ ಕಾಣುವ ಆದರೆ ಅನ್ವಯವಾಗದ ಉತ್ತರಗಳನ್ನು ಬೇರ್ಪಡಿಸುವದು ಸರಳವಾಗಿರುವದಿಲ್ಲ. ಇದನ್ನೇ ಬಂಡವಾಳ ಮಾಡಿಕೊಂಡು ನಿಜ ಜೀವನದಲ್ಲಿ ಕೆಲವರು ಈ ತರಹ ಉತ್ತರ ಸರಿಯಾಗಿದ್ದರೂ ಸಂದರ್ಭಕ್ಕೆ, ಸನ್ನಿವೇಶಕ್ಕೆಅನ್ವಯವಾಗದ ಉತ್ತರಗಳನ್ನು ಕೊಟ್ಟು ಅನೇಕರಿಂದ ಸೈ ಅಥವಾ Brilliant ಅಂತ ಕೂಡ ಅನ್ನಿಸಿಕೊನ್ದುಬಿಡ್ತಾರೆ. ಈ ತರಹ ಉತ್ತರ ಕೊಡುವರನ್ನು ಮುಗ್ಧ ಎನ್ನಬೇಕೋ ಅಥವಾ ಜಾಣ ಕುರುಡು ಎನ್ನಬೇಕೋ ತಿಳಿಯುದಿಲ್ಲ. ತಮಗೂ ಈ ಅನುಭವ ಆಗೇ ಇರುತ್ತೆ ಅಂದುಕೊಂಡಿದ್ದೇನೆ.

ಈಗ ನೀವೇ ಹೇಳಿ : ಅಳುವುದೊ ನಗುವುದೊ ?

How to make Programming Language Trainings effective

Giving training in programming languages is not as easy as it seems. Getting happy audience out of these course needs good bit of thought.


To make it effective and interesting what one needs to understand is what audience are looking for. The complete spectrum of audience can be classified in 3 categories. I could not think of single course that can satisfy everyone.

1. Starters - Fresh starters and have very minimal exposure to any programming before. These are audience who are really looking to get good overview of the language features. To this audience language details have to be presented in a manner that is easy to absorb. Detailed explanations with simple examples are appreciated by this audience.

There is second category of starters. These are guys who have had some programming experience and picking up a new language. The new language presented correlating to language they are aware of on the common set of features and detailed approach on the unique aspects of new language is more effective.

Very advances features of language can be skipped here.

2. Application - These are audience who have been using it for a while but are more interested in enhancing the usage to make it more effective. This training should start off with the various typical usage pattern of the language.

This session could also cover various best known practices that should be followed. It should also cover the features of language that makes user power user. Also cover the gotchas.

3. Philosophy - This team is practicing seasoned engineers or leads who need to make decisions. Goal here is to present the bigger picture. Cover to an extent why things way they they are aspects. Tracking project which is using this language. If there are any methodology on specific way of usage of this language are of greater interest here.

ಸೋಲಿನ ಸೌಂದರ್ಯ

ಸೋಲೆಂಬ ಪದದಿಂದಲೇ ನೂರಾರು ಮೈಲಿ ದೂರ ಓಡಿ ಹೋಗಲು ತುದಿಗಲಾಲಲ್ಲಿ ನಿಂತವರು ನಾವು. ಅಂತಹದರಲ್ಲಿ ಅದರ ಸೌಂದರ್ಯವನ್ನು ಕಾಣಲು ಎಲ್ಲಿದೆ ನಮಗೆ ಸಮಯ ಹಾಗೂ ತಾಳ್ಮೆ.

ನಮಗೇನಿದ್ದರು ಗೆಲುವು ಬೇಕು. ಗೆಲುವನ್ನು ಅಪ್ಪಿಕೊಳ್ಳಲು ಸದಾ ಕಾತರರಾಗಿವರು ನಾವು. ಎಸ್ಟೋ ಸಾರಿ ಅಂತೂ ಅತ್ಯಂತ ಕುರೂಪಿಯದರೂ ಕೂಡ ನಮಗೆ ಗೆಲವೇ ಆತ್ಮೀಯವಾಗುತ್ತೆ. ಗೆಲುವಿನ ಸ್ನೇಹಕ್ಕಾಗಿ ಯಾವುದೇ ತ್ಯಾಗಕ್ಕೂ ಸದಾ ಸಿದ್ಧರು ನಾವು. ಕೆಲವು ಬಾರಿಯಂತು ಮನಃ ಸಾಕ್ಷಿಯನ್ನು ಬಲಿ ಕೊಟ್ಟಾದರೂ, ಸರಿ ಗೆಲುವಿನ ಸಾಮೀಪ್ಯ ಸಂಪಾದಿಸಲು ಹವಣಿಸುತ್ತೇವೆ.

ಗೆಲುವಿನ ಆಕರ್ಷಣೆ ಇಂದು ನಿನ್ನೆಯದಲ್ಲ ಬಿಡಿ. ರಾಜ ಮಹಾರಾಜರ ಕಾಲದಿಂದಲೂ ನಡೆದು ಬಂದಿದೆ.ಇಂದಿಗೂ ಕಾಲ, ಗಾಳಿ ಹಾಗೂ ಮಳೆಯ ಹೊಡೆತ ತಡೆದು ಕೊಂಡು ನಿಂತಿರುವ ಅನೇಕ ಸ್ಮಾರಕಗಳು ಗೆಲುವಿನ ನೆನಪಿಗಾಗಿ ಹೊರತು ಸೋಲಿನ ನೆನಪಿಗಾಗಿ ಅಲ್ಲ. ನಾನಿಲ್ಲಿ ಗೆಲುವು ಕೆಟ್ಟದ್ದು ಎಂದು ಹೇಳ ಹೊರಟಿಲ್ಲ. ಅತಿ ಹೆಚ್ಚಾದ ಗೆಲುವಿನ ವೈಭವಿಕರಣದಲ್ಲಿ ಸೋಲನ್ನು ಹೀನಾಯವಾಗಿ ಕಾಣುವುದು ಬೇಡ.

ನಾನಿಲ್ಲಿ ಬೇಕಂತಲೇ ಸೋಲಿ ಎಂದು ಹೇಳುತಿಲ್ಲ. ಸೋಲಿನ ಭಯದಿಂದ ಜೀವನದಲ್ಲಿ ಯಾವುದಕ್ಕೂ ಹಿಂಜರಿಯದಿರಿ. ಈ ಪ್ರಪಂಚದಲ್ಲಿ ಹುಟ್ಟಿ ಬಂದ ಪ್ರತಿಯೊಂದು ಜೀವವೂ ತನ್ನದೇ ಆದ ಒಂದು ಏಕೈಕ ಉದ್ದೇಶವನ್ನು ಹೊತ್ತು ಬರುತ್ತದೆ. ಆ ಉದ್ದೇಶದ ಸಾಧನೆಯೇ ನೈಜ ಗೆಲವು. ಆ ಉದ್ದೇಶ ಏನೆಂದು ಹೇಗೆ ತಿಳಿಯವುದು ? ಹೊಸ ಮಾರ್ಗಗಳನ್ನು ಪ್ರಯತ್ನಿಸಿದಾಗ ಹಾಗೂ ಸಹಜ ಕೌಶಲ್ಯವನ್ನು ಅರಳಲು ಬಿಟ್ಟಾಗ. ಇಂತಹ ದಾರಿಯಲ್ಲಿ ಸೋಲಿನ ಸಂಭವನೀಯತೆ ಕೂಡ ಹೆಚ್ಚು.

ಸೋಲಿನ ಭಯಕ್ಕೆ ಮನುಷ್ಯನ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೆಚ್ಚಿಸುವ ಒಂದು ವಿಚಿತ್ರ ಗುಣವಿದೆ. ಇದು ಮನುಷ್ಯನ ದೇಹದ ಹಾಗೂ ಮನಸ್ಸಿನ ಸಹಜವಾದ ಪ್ರತಿಕ್ರಿಯೆ. ಇದು ಯಶಸ್ಸನ್ನು ತಂದು ಕೊಟ್ಟರು ಇದು ತಾತ್ಕಾಲಿಕವಾದುದು. ಭಯದ ನೆರಳಿನಲ್ಲಿ ದೊರೆತ ಯಶಸ್ಸು ಬಹು ಬೇಗ ದಣಿವನ್ನು ಕೂಡ ತಂದು ಕೊಡುತ್ತದೆ. ಈ ದಣಿವು ದೇಹ ಹಾಗೂ ಮನಸ್ಸನ್ನು ಮಂಕಾಗಿಸುತ್ತದೆ. ಇಂತಹ ಯಶಸ್ಸು ಫ್ಯೂಸ್ ಆಗುವ ಮೊದಲು ಹೆಚ್ಚು ಬೆಳಕನ್ನು ಕೊಟ್ಟು ಉರಿದು ಹೋಗುವ ವಿದ್ಯುತ್ ಬಲ್ಬಿನಂತೆ.

ಸೋಲಿನ ಭಯ ಬೇಡ. ನೈಜ ಗೆಲುವು ಶ್ರೀ ಕೃಷ್ಣ ಗೀತೆಯಲ್ಲಿ ಹೇಳಿದಂತೆ ಕರ್ಮ ಮಾಡುವದರಲ್ಲಿ ಇದೆ ಹೊರತು ಅದರಿಂದಾಗುವ ಸೋಲು-ಗೆಲುವಿನ ಪರಿಣಾಮದಲ್ಲಲ್ಲ.  ಆಂತರಿಕ ಕರೆಗೆ ಓಗೊಟ್ಟು, ಎದೆಯೊಡ್ಡಿ, ಧೈರ್ಯದಿಂದ ಮುನ್ನುಗ್ಗಿ ಪ್ರಾಮಾಣಿಕವಾಗಿ ಮಾಡಿದ ಪ್ರಯತ್ನದ ನಂತರವೂ ಬಂದ ಸೋಲುಗಳನ್ನು ಒಬ್ಬ ಸೈನಿಕ ಯುದ್ಧದಲ್ಲಿ ದೊರೆತ ಪದಕಗಳಂತೆ ಹೆಮ್ಮೆಯಿಂದ ಸ್ವೀಕರಿಸಿ. 

ನಿಮ್ಮ ಸಾಮರ್ಥ್ಯದ ಅತ್ಯುನ್ನತ ನೈಜ ಗೆಲುವು ನಿಮ್ಮದಾಗಲಿ. ಅದಕ್ಕೆ ಬೇಕಾಗುವ ಪ್ರೇರಣೆ ಉಡುಪಿಯ ಶ್ರೀ ಕೃಷ್ಣ ನಮ್ಮೆಲ್ಲರಿಗೂ ಕೊಡಲಿ.

Mumbai - Addiction to hard work

Recently visited Mumbai couple of times on some personal work. Here is what I got addicted to in Mumbai.

Mumbai is really a inspiring place. Hard work is there everywhere but I kind of sensed it in a heightened state in Mumbai.  I was always scared of Mumbi due to the image of it created by Bollywood in common man. But in contrast I found it as a very different place. Mumbai's local trains define mumbai. The discipline of local trains can be seen in every true Mumbaikar. Mumbai is, what it is, due to intense hard work residents.

To my surprise Autowala's and Taxiwal's dont cheat as much as I have seen in other places. They want to work hard and earn what they deserve. I salute this spirit. A waiter at hotel would rather clean up the already clean tables and plates once again than standing idle. He would never allow your water glass run empty. He will try to understand and guess what you would need. Well there by he earns his well deserved tip. Every one doing the best in whatever one is doing honestly. This makes every ones life that much easier. I now think that's why our text books said man is social animal.

Although in Mumbai as well people are self absorbed as in any big city the one thing that differntiates is people are aware of pain individuals go through leading the life in Mumbai. They know life in Mumbai(for that matter in any big city) is not simple. This simple understanding has done one wonderful things. People are ready to help. Its not when you yourself are not trying to help yourself but when some one is doing his best and yet fails due things he/she cannot control. Rest assured there is one helping hand from some where.

Not that I have not worked hard myself before. But I have not quite felt the power of it. I have not appreciated it much. May be as a part of growing up I am starting to enjoy the hard work. I feel proud to be human and what humans have accomplished by their diligent hard work.

Every day I enjoy the hard work of many and it has slowly starting to inspire me as well to work hard. Work hard to enjoy the feeling of working hard. I am able to see the value that hard work brings in. I am able to see how world looks more beautiful by hard work. Now I perfectly understand the meaning of Kannada saying "ಕೈ ಕೆಸರಾದರೆ ಬಾಯಿ ಮೊಸರು".

Historical monuments like Hampi, Belur, Halebidu, Banavasi and many more have always inspired me. Now I can imagine what vision and hard work has made that possible. Taking the responsibility and taking things to closure is  truly a amazing.

Diligence makes hard work meaningful. Results of hard work are making me get addicted to it. I think every one should try to be active most of the time and diligently work hard. Humans have great future ahead. Lets go grab it !

Data Strctures are Pillars of Software Structure

With "ನಮ್ಮMETRO" and many Flyover work to make signal free ring road on-going at many places in Bengaluru, I see lots of pillars all around the city. Here is how they kind of inspired me.  

Many modern day structures strength relies on its pillars. Pillars also are designed keeping the scalability that might be desired in the future. Once the right pillars are in place rest of construction work comes up real fast. Mistake in choice of pillars can also prove fatal. Once committed its tough add or change these. Any such attempts also affect the beauty of building. Structure will not look coherent.

On the same lines data structures form the pillar and beam of the Software structure. Good data structure extend the life of the software. They also make it easy to weather the changes without collapsing.

Invest time to build good quality data structures and they will help tremendously at the later point. Have sound philosophy that relates well the problem at hand and/or uses some standard data structure concepts.

Poor data structures will be tougher to debug, difficult or impossible to extend.