DAtum

EDA, Software and Business of technology
Greek, 'loxos: slanting. To displace or remove from its proper place
da·tums A point, line, or surface used as a reference


                        ... disruption results in new equilibria


[business] Kleiner Perkins and the lost art of the start

4/25/2005
This week, two different stories came into focus - seemingly unrelated, but for me having a slightly deeper implication.
Paul Kedrosky writes about a NVCA report which discusses the investment profiles for venture funds in Q1-2005. The interesting part was that first-time venture funds are at an all-time low in raising funds. First-timers comprise just 12% of all venture funds in the industry.
This sort of worries me - because this figure has gone down from approximately 40 %. Paul has justified that this is because focus is on quality and demonstrable returns. I am worried that this is a general indication of trepidation in the venture capital industry. New funds like Octopus Management's "Eclipse" won the Investor All Star awards in Dec. 2004, but clearly performances like these have not swayed investor attitudes.
Attitudes like this percolates down to the fund itself, in its search for ventures. As Clayton Christensen puts it - "resource dependence", the majority of a company's resources go to satisfy its biggest customers/investors. Does that mean that I cannot do anything, unless I know a John Doerr??
On the other hand, John Doerr himself is hiring "gurus" in their management. Randy Komisar is, among other things, a professor at Stanford. What this means, he is in close contact with brilliant people, none of whom know how to write a truly good business plan, but will have a great Google inside them. Will there be another Bill Campbell to coach them?
Read more!

|

[timinganalysis] Why virtual clocks?

This is something that I learned from my great manager today. Why is there even a need for virtual clocks in timing analysis?


First the funda - virtual clocks are used to set timing-exceptions between two clocks on a particular timing path. There, that's all there is to it.
Consider, two flops arriving at a output port (say out1), through some combo logic. Therefore, there exists, two timing paths terminating at the same output port. Assume that both flops are clocked by two different clocks (C1 and C3). Therefore, it is mandatory that the designer set two output-delays at the output port - one each w.r.t each clock.
Now, while the tool is doing STA, it is likely that it would consider the flop (of clock C1), going through the combo-logic and terminating at out1. However, it will consider two scenarios - timing w.r.t the output-delay set with C1 and w.r.t the output-delay set with C2. Nothing wrong with this scenario, except that it assumes that a signal originating at C1 is going to go through out1 and end up, on the other side, on a flop clocked by C2.
Suppose, this does not happen - as is often the case. So how do we handle this? A simple answer would be to use false-paths. So we put a false-path from C1 -> C2 and from C2 -> C1. Cool. Except, what if somewhere else in the design , C1 and C2 were actually communicating with each other. This false-path would cause those other timing-paths to be ignored by the tool.
Not good.
Enter virtual clocks.
Let us create two clocks C3 and C4. C3 has the timing characteristics of C1 and C4 has the timing-characteristics of C2. Now, on port out1, instead of setting output-delays w.r.t C1 and C2, set them with C3 and C4. There would be no difference in the STA. However, this time, when we set the false-paths, do them with C3 and C4. This would cause the exact same thing as we wanted above, except that we cheated... and we did not cause other places where C1 and C2 are communicating to be treated as false-paths also.

Considering most designs these days are pad-limited (i.e. where chip area cannot be reduced because of the area taken up by pads), efforts are made by designers to reduce umbers of ports. This causes a junction of sorts, where different clock timing-paths intersect. This is a very good place to try out virtual-clocks.

Nice huh... thanks to my manager, now you know.
del.icio.us Tags:

Read more!

|

[Software] Source code management - golden rules?

4/19/2005
Frequently in any startup, there comes a time when the processes start mattering...or rather should matter more than the company. As Clayton Christensen says in his famous book
..at highly successful firms such as McKinsey and Company, the processes and values have become so powerful that it almost does'nt matter which people get assigned to which project teams.


I am at that career stage that I'm still not contaminated by manager-ese, which is to stay, vomit out improbable schedules. So here's my take on what should be followed during development.


  • Have a good spec
  • The God of software development - Joel Spolsky - has a very good series on writing specs. I feel the most important features of a spec is Non Goals - which tell the reader what your stuff wont do. In other words, you do know what your are not going to do.
    Always write plain english, or as near it as can be humanely possible.
  • Have a good test-plan
  • Testing is the most important part of software development. That's what we never learn in college. Have a good regression framework and a good test-plan.
    I have no idea how to do either one. Anybody have any ideas?
  • Have good coding guidelines
  • One of the cardinal rules of software development is writing code is easier than reading it. Having a good coding guideline makes life easier for the other guy. May I suggest GNU coding guidelines.
  • Use branching wisely
  • My preferred method of development is somewhat similar to Eric Sink's model. The trunk or main-branch is essentially unstable, however should be always buildable. Just before release dates, main branch should be changed very carefully. Very near to release date, create a release branch. No New Functionality on the Release Branch. Main branch can continue development as before. In case there is another customer who wants experimental functionality (just before release) can have a different branch, which should be merged into trunk after release branch is created.
  • Start breathing your code-freeze deadline atleast a week before date
  • Designate bugs and/or features that are blocking a release. If these features dont have tracking numbers, make them now. All commits during these period should be associated with a bug-tracking number. This is a good time to create that release branch mentioned above.
  • On release branch all check-ins must be reviewed


  • Release early and often
  • I have listened to two great writers about the same issue - Ed Sim and Luca. I still feel that for a small company, it is critical to release early and often, if a conscious effort is made to continually improve software quality. Let them laugh once, let them laugh twice, but you got them on the third try. I believe most customers are willing to give you more than one try if you give them the software free to play with it. I can tell my potential clients - hey this software is still buggy, but tell me what to do and I'll give you a nice discount.


del.icio.us Tags:

Read more!

|

[Business] Chinese noodles and Indian chutney

4/11/2005
It certainly is news when two of the world's fastest growing economies sit down together and sign agreements.
But what interests me most is the possibility of free trade agreements, especially those pertaining to cross-holding in the two countries. Such agreements would directly impact venture funding in Sino-Indian startups, because while several foreign investors want to invest in India or China, it is the slower growth in India or the unpredictability of governmental control in China, that dissuades them.
According to the Chinese Venture Capital Institute, venture funding in China is primarily by the government itself (48 % in 2003).
This may be good and bad. Governmental venture funding allows access to state-run projects and businesses, which may not be much of a deal in EU/US, but forms a large bulk of the market in China. It is bad, because bureaucracy as part of a startup is not that great an idea.
India, on the other hand does not have as large an appetite as China. While, this may reduce its attractiveness compared to our red-feathered neighbor, India is showing signs of a more stable growth.
Consider, the Incremental Capital-Output Ratio (ICOR). It denotes the percentage increase in investment (as a fraction of GDP) to produce a single point increase in growth. This means, having a lower ICOR is good for the economy. India's economy has shown signs of decreasing ICOR, from 4 to 3.6 (for the 10'th Five Year Plan). On the other hand, China's ICOR has gone up to 5.1 from 4.3 (between 1990-2003).
Both India and China have made huge investments in education, especially university level technical education. This provides for a large pool of sufficiently talented people to pick from.
Right now, we are running neck to neck in a race for technological supremacy (military and political are not my cup of noodles). But it would be far better if it were easier to run together. China has greater speed in governmental decisions. Its Special Economic Zones are great places to open new ventures.
I would say India has better technocrats - we can build and manage equally well (I like to think I'm one of them...only time and my boss will tell..very soon!!).
Beijing and Shanghai - two of the places I would definitely like to work. A few years back, I had a mild opportunity to work in Europe. It could have been great, but I could not afford to miss out on the Asian explosion thats about to happen.
Anyone interested?
del.icio.us Tags:

Read more!

|

[Personal] Carthage

4/07/2005

CIMG0195
Originally uploaded by sandys.

-> Hannibal was here <-


Read more!

|

[Personal] Sun and sand...


CIMG0220
Originally uploaded by sandys.

Tunisia at its quieter best...


Read more!

|

[Business] VOIP and the Five 9s problem

4/04/2005
Ronald Gruia (and others for that matter) have written quite a bit about the VOIP showdown, which looks imminent. Off late Jeff has a focussed on the need for quality in VOIP service, something that is known in Dependable Computing as the Five 9s problem.
The question Ronald asked was a very relevant one - How reliable should VOIP be? Considering that mobile phones (in UK atleast) have an availability of 97-98%. In response Om Malik posted a with-all-due-respect post, with a figure: 100 %. There are just two problems with this - I think it might be unnecessary and secondly, it might prove to be impossible.
Let me analyse why it might be unnecessary. At this point of time atleast, VOIP is partly an early adopter product. But more importantly, it is a PIGS method. PIGS for all the non-desi's stands for Poor Indian Graduate Student, however it can just as easily be generalised to anyone else..iff they are limited in their communication expenditure but not in their need. It is enough for a person like that to be able to say "hi ma". In such cases, if I am the VOIP company, it becomes important to me to get to market as fast as possible and achieve sufficient penetration. Of course, granted that for most corporate use this might be somewhat of a problem. But then I dont see corporate users switching to VOIP en masse just yet. Consider this brilliant post by Tom Evslin about the problem of too much quality. About AT&T and mobile phones, he says
The six nines song deafened the company to the fact that consumers would trade quality for mobility
. Now, I would like to rephrase Evslin's law
The six nines problem may lead a company to alter its expectation of consumer expectation
. As Om Malik says "I have argued about the ease of use and reliablity before. VoIP continues to fail the mom test.". However, reliability and human-interface problems are orthogonal to each other. Consider what might happen if Apple decides to make iSpeak and jump into the VOIP arena - that would solve the "mom test". But would it need to solve the 5 nines problem?
Is doing this impossible? Bob Cringeley certainly seems to think so. Existing backbone providers might start traffic shaping to allow their own packets higher priority than, say a company like Vonage. But I'm happy if backbone providers give me 6 9s service. But as Bob, puts it in his later post, increasing demands on media content will result in the backbone networks being clogged. He suggests that media companies adopt a higher-latency download-and-play mechanism for media to free up bandwidth for low-latency VOIP, but let me pose a question - can Vonage wait that long? or can a student in California wait that long, to be able to afford calling Delhi?
del.icio.us Tags:

Read more!

|