Some people may wonder about our Cypress PSoC C compiler plan. The original plan from a couple years ago was to release our PRO compiler, significantly increase the performance of the compiler. During the last couple years though, many unexpected factors came into play, but before we discuss the future, lets visit the past.
At the early 2000s, Cypress MicroSystems (CMS) was a small company with a big plan. Its idea of reconfigurable analog and digital blocks coupled with a MCU gave it a unique entry to the competitive microcontroller market place. Backing CMS was the Cypress fab, allowing CMS to mix flash, RAM, logic and the digital and analog blocks on the same chip. They headquartered in the scenic greater Seattle, allowing them to draw existing talents in the area.
And they have an impressive development team. They spec’ed their IDE to work with the innovations of the chips, giving the users a drag and drop experience of using the PSoC. The team knew that “everyone” would want a C compiler for the M8C CPU core, and they also smartly knew that growing their own compiler team was not in their best interests. ImageCraft was fortunate to be selected as their compiler development partner and the race is on to debut the PSoC to the world with world class software tools. If I recall correctly, the CMS software team and the ImageCraft compiler were ready in time for the hardware release. The hardware went through a few edit-modiy-tapeout cycle, but in the end, there was much rejoicing in the CMS campus when the product was released, around 2001/2002.
The M8C core is a fairly primitive 8 bits architecture. A single page summarizes all the instructions but it is by no mean a RISC processor. It’s accumulator based meaning that with few exceptions, all operations go through the 8 bit accumulator. There is also a single 8 bits index register, and there is no 16 bits operation. Unfortunately a proper C compiler (and it’s the “right thing to do” anyway) uses 16 bits int. So right off the bat, there were concern about performance, with assembler programmers coming out of the woodwork saying how this can be done better this way and that.
In time, many of the performance issues were fixed, but fundamentally the M8C is a poor match for a C compiler. It can be done, but it certainly is not ideal. We also improved the code size issues by introducing our whole program compression technology to the M8C. On our AVR target, we get 10-15% code size reduction using this technology, and as much as 30%+ in some cases. On the M8C, our own study showed that a 5-15% code size reduction is typical. Not too bad and certainly would be important.
Fast forward to around 2005/2006. CMS was no longer a separate company and was fully back in Cypress. Lots of management and business unit changes happened. Their CAPSENSE version of the PSoC took off in a spectacular way. Unfortunately, the CAPSENSE is not the high performance end of the market. Meanwhile, PSoC max’ed out at 32K flash, and an elaborate SRAM paging scheme brought tears to the programmers’ eyes. Sadly, those are not the tears of joy.
During that time, we found out that due to some issues which they did not inform us about (so that they can be dealt with), Cypress has been telling their customers to turn off the code compressor. Lets think about this: in a competitive microcontroller market where they go up against established players, they have been recommending their customers to throw away 10% of the code size! *headdesk*
Under that environment, we thought that if ImageCraft were to produce the PRO compiler, we could work with customers directly and together with the code compression technology, we should be able to get 10-20% better code, and we could offer them the upgrades at very attractive prices. So we began working on the project. Then we noticed a “funny thing:” the new Cypress management is decidedly less communicative and we no longer have contact with the technical team.
Nevertheless, looking over the business situation, we made one last proposal to them: basically, for the royalty they would have paid us in the next few years, they would have unlimited rights to the M8C compiler. This is especially important if PSoC is to be pushed “everywhere” within Cypress and outside. We went back and forth a few rounds, but judging from the lackluster responses, clearly something is up.
So it came as no surprise that they formed an alliance with another company with their LITE-mode compiler available free of charge. I have no insight with their financial arrangement, but I am betting that a small amount of NRE (emphasis on small seeing how tightfisted the current Cypress management is) is paid and the theory is that the compiler partner will make money on their $1500 PRO tools. Riiiiigggghhht. The PSoC market is small, and the number of users who would move to asm programming to get the performance is large. It leaves one to wonder about the revenue model.
And what is the current state of the PSoC tools? The LITE-mode compiler is certainly no better than our compiler was, but now the customers have to go through cycles of debugging their code again. On top of that, they just introduced PSoC Designer 5.0 which has its share of teething pains. Meanwhile, any customer who wants better performance is looking at a single $1500 option.
If we are convinced that there is a market, it would still make sense for us to introduce a PRO compiler at 1/3 of the price of the competitor’s. Yes, our performance level goal is lower, but in many cases, it would be sufficient. However, given the rapid decline of the business relation, and looking at the potential market of PSoC in general, at this moment in time, I am no longer certain that it would make a good business case for us.
It’s too bad too. The PSoC has some really good ideas. More bug free devices earlier on, higher performance devices with non-brain dead paging would have made them a better competitor in the marketplace. There are rumors of next-gen and next-next-gen devices, but they dated back in 2006 and none has shown up so far. The world matches on, and while the CAPSENSE business is still good, there is a limit to that growth as other vendors jump onto the market: once you spec out a PSoC device to do some fixed functions, then it loses its primary advantage of peripheral programmability and configurability. A CAPSENSE with a CPU core from another vendor may start to make as much sense.
As a final note, it appears that we are not the only one who is unsatisfy with the current PSoC situation. Check out Oliver Bailey’s blog http://oliverhbailey-psoc.blogspot.com/ for his “PSoC Chronicles.”