Monday, August 22, 2005 

Why does India fail in product development?

We all have ended up in pessimistic discussion at one time or another about how India seems to be doing so great at execution of off-shoring work for US-based companies (even run by Indians), but whenever they try, they fail miserably in developing their own products. These discussion, depending upon the participants, ends on two notes. Either,

  • "Indians are dumb. India sucks. We can never develop anything on our own. Even the railways, one of our crowning achievement, was essentially setup in more or less its current form by the British. Or the IITs, which were successful only cause we copied the model from British and US-ian universities." or
  • "Mera Bharat Mahan, India is a great country which an amazing past, and we have not been able to develop products cause of the brain drain/poverty/short age as an independent nation/corruption/power failures/etc etc. When we solve these problems, we will develop our own products".

Here, I am not talking about truly amazing, trailblazing products like the iPod, or the AJAX set of technologies, or our own 64-bit CPU (like the chinese have recently done), or a hindi version of Microsoft Word. I am only talking about things which have already been done in other forms, just not in ways ideally suited for india: for example a computer truly suitable for indian weather/dust conditions and needs, good e-governance software, customer counter management solutions that actually work, electronic cash and payment systems for use by the poor and uneducated, etc.

There is of course the question of weather we even want to develop our own products. For many, out-sourcing is enough of a cash cow, and India as a country should not even be worrying about doing product development. This is a question for another time. For now, i will proceed with the assumption (and my desire) that we be able to develop our own products, even if just for the indian market, and hopefully for worldwide sale. I also am aware there there *are* a few success stories in the Non-IT fields, for example in the food packaging industry. I will restrict my discussion to only the IT-field, as thats what i know best. I also know that quite a few attempts have been made, but most have then have either missed their market window (our own chip fabs?) or have fallen far short of achieving market penetration due to their shortcomings ( why would anyone a Rs10,000 Simputer when a fully-featured PC with all imported components can be purchased for the same amount?)..

I will attempt to summarize my views on why we fail, and how we, as employees of companies which possibly want to develop products but dont dare to, can possibly make a difference.

I believe there are multiple causes of this phenomenon (surprise surprise!):

  1. No ambitious enough: Most indian businesses and IT workers are not ambitious enough to want to indulge in something as risky as product development. The risks associated with product developement can be ameliorated by risk management, but partnering with other companies, by following a roadmap where directions can be changed if things do not work out, and by having proper market intelligence and vision. The market intelligence, especially global market intelligence comes at a very high price in rupee terms, and most corporates (but not all) skimp on these. Also, as the return on product development is not guarenteed, very few companies even bother to enter the fray. One of the causes unfortunately, is the perception of "outsourcing" as a lucrative business.
  2. Not enough patience: This is in some sense, a contradiction of point 1 above, as Indian Companies and Developers tend to be very shortsighted in general, and cannot usually handle long-term, multi year projects (with almost guarenteed failures early on) due to their management structure, and performance measurement standards followed by CEOs, investors, and shareholders. Companies and People are too ambitious (in the short term), to attach value to any long term goals.
  3. Limited risk-taking ability: This is true for the smaller companies, as the indian stock market tends to only overvalue large, steady income companies. The smaller companies are the ones which drive innovation, and which have a much higher chance of achieving the right momentum for developing something new. Unfortunately, these are the very companies that in general are too concerned about their cash flow to be able to invest in risk product development ventures.
  4. Limited market experience: Indian IT companies generally do not have any experience dealing with the users of their products. This is essential to have a clear(er) market vision, and forms the part of a "constructive loop" which enables great product development.
  5. Failure of Indian Colleges and Schools in producing "problem solver" and "self help" attitude in students: Our educational systems, esp at the Bachelors levels remain archaic and based on rote memorization, and do not lay sufficient stress on continuous and fast revision of syllabi, upgrading of facilities and teacher skills, and challenging the students to work on something new. Even most masters thesis in India tend to be completely non-innovative and un-inspiring. Our educational system also tends to be "one-size-fits-all" and does not allow a student to customize the course to his/her liking. This selections and customization is a required small step in forcing students to think what they really want to do, instead of "what is the most popular decipline to go into this year?" kind of herd mentality.

To be updated.


CMMI processes for R & D Projects

As part of my job, I come up with new product/IP development ideas for my Company, and then also do the top level architecture and design so that the product/IP can then be implemented by the engineering team with limited continual direction from me.

These projects tend be different from the usual client-driven projects undertaken by the engineering division in multiple way.

Firstly, The R&D projects tend to be a lot more ambitious than the client driven ones for the simple reason that client projects usually only happen once we have a proven expertise in some field, and we have shown that we can execute projects of a similar nature to the one the client is proposing. R & D projects on the other hand, are designed to expand the companys' capability in new directions, "to boldly go where no one (within the company) has gone before", so to say. For this reason, usual methods of effort estimation and timeline planning are tough to apply on R&D projects.

Also related to this is the problem of project management in general: by its very nature the projects are less clearly defined than client projects. And while surely the level of definition can be improved over the current low ones, a full definition in advance is not possible as such projects tend to change directions (in acute angles) all along their evolution, as new problems are uncovered and resolved during implementation. This amount of change is an inbuilt feature of the R&D project and cannot be handled by the usual "change request" procedures followed for client procedures. The changes made need to be swiftly incorporated into the process documents, and while the R & D "architect" should need to clear the change, the change decision and its update in the document should happen at the implemters level, and on his/her initiation. The R & D person should recieve a change notification, with a short window available to him/her for accepting or rejecting a change or suggesting and alternative. In short, there should be a clean and swift procedure for frequent changes to the project design and consequently, to the process documents. Such a process should also capture all the reasons for the said change, and preferably capture any alternatives that were considered, other than the one that was accepted, along with a "pros-and-cons" analysis of each.

This problem is further compounded by the fact the project vision remains in the head of the R & D "architect" while the execution is squarely in the purview of the engineering PM/PL. This is completely different from a client driven project where the project vision is transferred from the client to the PM/PL at the initiation of the project or at worst, by the end of the feasibility. At that point, in a client project, the PM/PL can work independently, with very limited dependency on the client. In an R&D project, the vision transfer currently does not take place, and in addotion, there is never an intention of reducing the involvement of the R&D architect to as low levels.

A solution needs to be found which:

  • Ensures that the vision transfer from R&D to PM/PL takes place, if that is what is desired. This is tough to achieve as the vision could be very deep and wide, spaning multiple projects to create a whole, and if may just not be viable to transfer all of that information to a single PM/PL. There may be further complications related to the abilities of the PM/PL, time availability, Corporate secrecy issues, and motivational issues. On the practical side, the vision transfer needs to be documented and the amount of effort and time involved for this may be enormous. The primary issue here is that there needs to be a process for achieving this vision transfer/capture at the initiation of the project.
  • If vision transfer/capture is found to be impractical or ineffectual by itself, the the only other option is for a very well defined process to ensure that unknowns in the project are resolved as early as possible. This could take the form of a feasibility study, for example. As varied teams with varied problems maybe involved in a single project, and they may have interdependencies on each other, this could be much more complex than the usual feasibility done for client projects.
  • Another issue is that of physical resource availability: Client projects in general do not suffer from this problem, of unavailable hardware/tools etc due to multiple reasons (the client pays for all of these are predetermined times, thus ensuring their availability, or, the required tools are already available with us, or the tools are made available at appropriate times as necessiated by the project dependencies). This is not true for R&D projects where tools are almost always not available, budgets are small, and hard deadlines for making certain tools available are just not practical. While it can be argued that such problems can be resolved by making sure that tools are made available, a more realistic solution is to incorporate hardware/tool dependency are part of the project management process and create "what if" analyses of what effect the delay/unavailability of such resources may have on project time lines. Such "risk management" IS already part of the standard CMI process, but for most client projects such "plan B" s and (god forbid) "plan C"s never need to be put in practice. For R&D projects, such plan Bs and Cs and Zs need to be very real and planned more thoroughly than others.
Another issue with R&D project processes is the issue of project progress tracking: In general the R & D project has a top level goal which need to be adhered to, but the individual milestones are fluid, and they need to be: due to the continuous change of direction of such projects, these milestones tend to be ill defined, and may change around a lot. The process definition for R&D projects needs to help in tracking these milestones and guidelines need to be set so that milestones are defined in ways which ensure they dont change around much.

In short, a modified flow for R&D projects needs to be put in place. This post just covers some of the issues that such a process needs to address. R&D projects need proper process adherence even more than client projects do (the successful execution of client projects is very well monitored by the client), but the current process is not completely applicable to R&D projects. A proper process will reduce the high level of risk currently associated with R&D projectes to a more manageable level.

Please post views below.


FPGA Killer app?

As is probably evident by now, FPGAs are my current "crush". I was a helpless, penny less electonic hobbyist for a very very long time, never having enough money to actually build the circuits i could design, my notebook full of designs which never saw the light of light of LEDs. Now with FPGAs, building this circuits is as easy as writing and compiling software. With the availability of unbelievably low-cost prototyping boards like the spartan3 starter kit ($99) or the upcoming spartan3e starter kit($150) (yum, i want one NOW!!), the hard part is the concept, not the implementation. These amazing value bundles come not only with an amazing amount of hardware, they come with all the cables and software you need for your first designs!!

Anyways, to get back on track, while FPGAs are electonic circuit protoyping platfomrs are cool, that idea is not new, and this is how FPGAs are generally used: as protypes for ASICs.

The vision I have for FPGAs (and well, hopefully, many others do too), is to have FPGAs are the delivery platform too. With todays FPGA costs, this is almost viable, and with the cost reductions we have seen due to vendor competition (thanks Xilinx and Altera for being such good sports), the economics may become very lucrative soon, especially considering the NRE costs associated with ASICs, esp the 90nm node and better.

Now, one argument against using FPGAs for final delivery is that ASICs will always beat them in large quantities. This is unquestionably true. But the place where they fit are:

  1. When the reconfigurablity of the FPGA is what the doctor ordered: For example in logic probes, In-circuit Emulators, etc. These applications just have to be done using FPGAs, but the number of FPGAs that can be sold as part of these products is ver limited. In other words, this is not going to set the FPGA market ablaze.
  2. Where the circuit logic may need to be changed after product fabrication/sale: We are all used to applying "firmware" patches to various components of our PCs, like the motherboard BIOS, the videocard BIOS, even to our home network gateways, etc. These firware upgrades can fix software bugs after the device has been delivered to the final user. It may also add new functionality, for example adding photo-viewing functionality to the iPod. Most of the patches available today truly only upgrade the software residing on these hardware components. What if we could also upgrade the hardware if need be? Can we even imagine such a need arising? Are there any markets where such a capability may be even required, not just desirable? This is the application this post muses over (so now you know! whew!)
One such application is Software Defined Radio. This is a wireless transreciever where the modulation/demodulation scheme can itself be changed depending upon the standard being used at any point. While this capability is today mostly only used by Defence forces, a consumer example can be provided for a multi standard cell phone, which supports all the CDMA/TDMA/W-CDMA etc modulations/multiplexing schemes by just changing the "hardware" which demodulates the recieved signals before the base band processor sees them.

Of course, due to economic and regulatory reasons, most cell phone operators dont and cannot provide this capability (or do not want to!).

Any other "killer apps" for an FPGA? any application where runtime hardware reconfiguration is a basic feature?

Saturday, August 20, 2005 

on the origin of sexes

A close friend of mine put forth this question recently:

"In the begining there was one cell life (no concept of the gender) then multi cell life (no concept of gender still) and we are here (male and female). so at some point 2 sexes (male and female) evolved instead of one. why?"

Heres my attempt at an answer:

Evolution works using two complementary processes: introducing random changes in the genone, and then propogating any changes which may be found beneficial (in the "survival of the fittest" sense).

Now the primary way of introducing changes is by mutation. And the primary way of propogating these changes is from parent to child.

With asexual reproduction, once organism "A" has uncovered a beneficial mutation "z", that mutation will be passed on to all its offspring, but will never be seen by any other members of the same species. slowly and steadily, as mutations accumulate, the "family" of organism "A" will diverge from its own species sufficiently to qualify as a seperate species. But this is a very inefficient way of evolving. No doubt, other members of the species would have also developed useful mutations, and if by some way members of single species could "exchange notes" so to say, they could evolve much faster and much more efficiently, without each mutation fragmenting a species into two.

So now we agree that exchange of some genetic material is required. Even though we think of unicellulars as "asexual", there still are instances when two unicellular organisms exchange genetic material using what are called "vectors", small strands of DNA/RNA, which are physically passed from one cell to another. This allows for exchange of beneficial traits between members of a species. So technically, sexes are still not required.

But surprisingly, what is found is that even in this simple case, among the pair of organisms exchanging a "vector", one is found to have the tendency to always "recieve" the vector, and the other is found to have a tendncy to always have the tendency to always "transmit" a vector. So even here, we find a very low degree of differentiation in the roles.

Now I am firmly in the domain of pure speculation:

As species developed, and became more complex, it became clear that special "support structures" would be needed in the organisms' body to permit bringing-forth of offsprings, hence the development of ovaries and the like. As this function became quite complex, it became essential to further differentiate members of a species into two distinct groups:

1. One group, which has the necessary physiological support for nurturing a foetus in its early stages of development, when it needs to be protected from the external world. This support unfortunately led to a condition where, from conception till birth, the members of this group tended to be very vulnerable aginst predators and other dangers. Enter the second group:

2. The second group, which developed the physiological support to provide DNA for the "mixing" of genes which is, as discussed, curcial to effective evolution. This group also developed so as to be able to provide protection to group one during the vulnerable period.

So though it can be argued that instead of bifurcating into sexes, all memebers of a species should have had the capabilites of acting both as a "male" and a "female" at times. And i believe this behaviour is found in some rare species still. But due the highly specialized nature of organs required for the "female" and the high degree of vulnerability introduced during pregnancy, i believe over time, it was inevitable that two specialized groups would emerge within a species.

What do you think?

Thursday, August 18, 2005 

single chip voice-over-IP and video-voice-over-IP phone design

single chip solution for VoIP and VVoIP phone needs to be developed. The solution should start off with just being VoIP and then scale up to VVoIP thru a software update, and a jump to a higher-end but code-compatible CPU/DSP.

It should be completely stand alone and should try and be compatible with Vonage, Skype, etc. Should have SiP, etc built in. This means it should run one each of:

  1. Linux
  2. TCP/IP stack
  3. SiP stack
  4. DHCP
  5. Audio Decoder
  6. Audio Encoder
  7. (later) Video Decoder
  8. (later) Video Encoder
  9. Audio input port driver
  10. Audio output port driver
  11. Video input port driver
  12. Video output port driver
  13. Ethernet port and driver.
  14. USB port and driver (in case user doesnt want to provide an ethernet hub)
Considerations for architecture include:

  1. TI C64X DSPs: Good for audio/video, but expensive, and do not run linux well. Have very high end audio/video ports, so saves logic there.
  2. ARM/XSCALE: run linux very well, but not so great on audio/video codecs.
  3. Blackfin: Runs linux, seems to be great for Audio/Video. Multi core available, so scale up to video should be possible.
  4. Trimedia: not a very open archtecture. Tough to judge.
  5. ST Spear: more details needed. May be extremely suitable for this application. Has an ARM, so linux is available. The FPGA fabric can help a lot in accelerating audio/video.
  6. Pure FPGA: Running Linux would consume a lot of resources, but would really work well for audio/video. Expensive to develop.

Update 1: Wireless (802.11x) needs to be included in the feature set as an optiona upgrade.
Update 2: BORSCHT support is needed - Battery feed, Overvoltage support, integrated Ringing, line Supervision, Codec, Hybrid(2w/4w), Test


  1. Update with more thoughts,
  2. create a white paper with top-level designs for atleast some (if not all) of the above options.
  3. define feature set.



"AES encryption and decrpytion on an FPGA" is another core i am trying to get going. Again, this needs to be a high end core, and this would need some very significant updates to the way the algorithm is generally implemented in sequential processors.

Will be editing this post continuously, updating it with links to documents.



I have been trying to figure out an implmentation of the GZIP "deflate" algorithm inside an FPGA. I am not really an RTL expert, so this is even more challenging than normal for me. It needs to be high end and very efficient (and while i am making rediculous demans, i need a billion dollars, too :P )

deflate comprises of LZ77 (which is a string matching compression) followed by static/dynamic huffman (which is a form of entropy coding). Dynamic huffman is a problem in itself, but for now, i have decided to stick with static huffman. My main issue is with doing LZ77 searching inside an FPGA. I need to be able to take an input character atleast once every clock cycle (or two).

So post here any links, comments, issues etc related to this issue. I will be building this up as a link bank.

About periphany

  My digital pensieve.
  Read. Comment. Repeat.

About me

Amazon Search

Search Now:  
Amazon Logo


Powered by Blogger

All Posts © 2005 Linux Ghoul.
All Comments © poster.