The Cypress PSoC C Compiler Saga

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 for his “PSoC Chronicles.”

Development Plan

One of the clear demands from the comments to our prior posts is that we should concentrate on delivering great compilers. I thought I’d lay out our primary development plan for the next 6 months, in increasing order of priority:

Expand Our Offerings – microcontroller dominance comes and goes. 8051, HC11, PIC16, AVR are some of the most popular 8 bits controllers in their times. To remain competitive, we need to monitor the next greatest hit. With 32 bits controllers coming down in prices and gaining in features, it’s natural that we move into that segment of the market, as we have done so by adding support to the ARM/Thumb architecture a couple years ago.

An even stronger alternative is now coming down the pipeline, in the form of the ARM Cortex-M3 core, implementing the Thumb2 instructions. The instruction set combines the speed of the 32 bits ARM instructions and the compactness of the 16 bits Thumb instructions, and the M3 core is designed with embedded systems in mind. And now Atmel has licensed the core, with NXP rumored to be doing so soon (and it would make sense for them to do), joining the rank of existing vendors STM and Luminary Micros, so working on a Cortex compiler is a no-brainer.

Make Our Tools Visually Appealing – our last two blog posts already touched on our thoughts on the “nextgen” IDE. If nothing else, a good looking IDE will sell more tools. More than that, leveraging a world class IDE will free up resources in the long run so we can continue to work on better compilers.

Go Deep – as many comments indicate, customers are always looking for more optimal code. Toward this goal, we have initiated the MIO (Machine Independent Optimizer) project a few years ago. This introduces many of the classical function level global optimizations to our compilers, coupled with our Code Compression ™ whole program compression technology, our compilers are already very competitive. However, we can always do better.

This project will take advantage of the code compressor framework, and applies many of the optimizations post code generation, thus gaining even further code size reduction and faster execution. Our code compressor framework has been rock solid for years and most of the optimizations are well known (albeit applying to a machine specific level), thus maximizing the robustness of the first release of the technology.

We will offer this technology initially with the AVR tools, and add it to the other products as situations warrant. Our goal is to further improve our code size and speed by 5-15%, making it as competitive as any compilers out there, bar none, in all cases.


We expect all three projects should produce results during the first quarter of 2009. We will also doing maintenance work on existing compilers, to support the latest devices etc. As you can see, further improving our compiler efficiency is our number one goal.

// richard

Posted in new product. Tags: , . No Comments »

Next-gen IDE followups

Lots of great comments on the last post here and on our mailing lists. Let me elaborate on the subject:

To address why working on the IDE at all when a simple one suffices: it is definitely the case that ImageCraft will continue to place the most emphasis on compilers. The thing to keep in mind is that the resources that can work on compiler backends are usually not the same as the ones that can work on GUI and IDE. Hence working on the next-gen IDE will not take away resources from the compiler development. (I will write another blog entry on our compiler development later.)

From a business perspective, there is no doubt that prettiness sells, and every week, we have customers or potential customers asking: why don’t you add this [xyz features] to the editor? So, the demand is there. While a good number of developers use their own editors instead of our IDEs, a good number also request code folding, code browsing etc. One even said that he will not buy or recommend ImageCraft if we do not move to Eclipse-verse pronto. While we cannot keep all customers or satisfy all requests, I know in certain markets (do remember that we are supporting a variety of micros), the prettiness of the IDE does come into play in being competitive. A next-gen IDE will also allow us to integrate a debugger, which is another oft-requested feature.

Having decided a next-gen IDE is necessary, it is easy to decide against writing our own: it will just waste too much resources. Something like notepad++ would be ideal as a starting point – it has almost all the editing features one would want, and adding project management, application builder etc. would be fairly light weight. Unfortunately, for a variety of reasons, we cannot afford to use GPL code.  GPL is another sinkhole I don’t want to get into right now.

A small number of people commented that Eclipse is not too bloated for the current and future generations of PCs. I do not make the statement arbitrarily; for a good number of our users and potential users, there is evidence that Eclipse is a bit bloated. Besides, we do already have an Eclipse plug in for the AVR compiler, so people are welcome to try that out now.

As for Visual Studio, while working with Microsoft always carries a risk (I have personal experience with working for 2 rather large companies that had partnership agreements with Microsoft), in the end, it seems to be the right decision. I have gotten clarification from Microsoft that we will in effect be able to ship a copy of the Visual Studio 2008 IDE (sans the Microsoft compiler) as part of our compiler package free of charge to us and to the customers. People that use their own IDEs (including Eclipse and command line users) will not be affected, and we will get a world class IDE with a lot less work and support cost than if we write our own.


Posted in new product. Tags: , . 2 Comments »

Next-Gen IDE

We released our first Windows IDE around 1996, V3 of our compilers. It was one of the earliest Windows GUI for an embedded compiler at the time. The look and feel of the IDE remained generally the same up through V5 of the tool release. Around 2000, we released the V6 compilers and rewrote the IDE to be fully 32-bit. The V7 IDE, released around 2005, has been largely the same as the V6 look-and-feel wise.

For various reasons, we believe it is time to rethink our IDE strategy. “More pretty” is always a Good Thing. “More code assistant features” is definitely a Good Thing. Debugger integration is, likewise, a Good Thing. (Of course our core competence and focus must still be the compiler: we MUST have excellent code quality. After all, our customers ultimately depend on it.)

The solution that seems to make the most sense would involve leveraging a 3rd party product. The non-free ($$-wise) products would add cost to our end users (a potential Bad Thing.) If we look at the free ($$) solutions, there are really only two choices: Eclipse and Visual Studio. Eclipse is still too slow and bloated, and it’s getting more complex by the day. So, that leaves Visual Studio.

In fact, Microsoft now has something called Visual Studio Express, which is free to download and use, and it appears that we can extend it to integrate our compilers with it. By leveraging VS Express, we get Intellisense, code folding, and all the modern editor, browsing and project managment features. Of course, it is still not a trivial task to base our next-gen IDE on it, but the cost will be significantly less than rolling our own solution from scratch.

All in all, sounds like a good solution to many of our needs – and our customer’s. :)

// EDIT: I just got words from Microsoft that the Express version is not extensible. We will need to consider this data. A possibility is to continue to support the current IDE as the light weight solution, and provide a Visual Studio Shell extension as the premium solution. The VSX shell will be available in the base product, but will require the users to purchase Visual Studio. A good number of users already use Visual Studio so it may still be a good way to go.

// richard & karisu

Posted in new product. Tags: , . 7 Comments »