Synthesizable IP: the risk pays off

Our experience with the hard macro, however, soon showed that there were more-subtle problems in applying it to our design. One of the first c hallenges we ran into was the limited availability of options. We got our core from Samsung, which meant that our design could only be fabricated at Samsung. They own the core, and if we wanted to move our design to another foundry we would have to use that foundry's version of the core. Unfortunately, not all foundries offer this core, and even when they do there are subtle differences among the versions, making second-sourcing difficult at best.

The next problem with the hard core arose while designing for test. The ARM7TDMI core came with a set of parallel test vectors, but our approach is to use scan-based testing. You cannot alter a hard core, so we had to design an additional test port to allow production testing of the core using the vectors while testing the rest of the device with scan. This not only complicated the design, it added to the time required for production testing. Every additional minute of chip testing adds 10 cents to its cost, an increase the consumer market won't tolerate.

Another obstacle showed up at first silicon. The behavioral model supplied with the core didn't match the silicon. This could have been a disaster for us, because the model is what we have to design the rest of our chip against. The problem is that once a core is implemented in silicon, the core and the model become disjoint. Unless great care is taken to keep the two in sync as changes and updates get made to the core, the kind of discrepancy we saw is inevitable. Fortunately, it didn't seriously impact the design, but it undermined our confidence in hard cores as a low-risk design approach.

When it came time to start developing the second-generation controller, we first looked at hard cores, with the idea of migrating the controller to an ARM9-series core with cache memory. We immediately ran into availability problems. Taiwan Semiconductor Manufacturing Co. had the core, but only two options for cache. One was too large and the other too small. Further, there was no way to get rid of option s we didn't want; they would simply add to the die size and cost. We looked at Samsung, which had other offerings, but still couldn't find a good fit. The foundries indicated they could qualify a variation of the core for us, but it would take six months. We couldn't tolerate the delay.

At this point we started looking at soft cores. Our greatest concern with the soft-core approach was the risk of using a design that had not been proven in silicon. Without that proof, we couldn't feel certain that the design would work for all corner cases of process variations and operating conditions. We also had concerns about the level of design support we would receive. Many soft-IP vendors are small companies that don't have the "bandwidth" to provide design assistance such as applications notes.

Experienced core
To minimize the design risks, we wanted a vendor with a core that had seen silicon in other customers' applications. We also wanted a vendor that was large enough to provide support during the design phase. We found that ARC International met our criteria, both for support and for having a silicon-proven design. The company's configurable and extensible processor core, the ARCtangent A4, would let us adjust its configuration and performance to match our design needs.

Our next step was to evaluate the ARC core to see how much effort was needed to customize the design. We then synthesized it to estimate the die size it would require. Following synthesis, we simulated the design to estimate its performance in our system. The ARC core performed well in all evaluations and we proceeded with the chip design.

One of the side benefits was that ARC's core had the support of an integrated software compiler and debugger tools. The tools adapted to the changes we made in the CPU design, ensuring that the software we created was well matched to the CPU's cap abilities. That helped keep down the size and cost of the code.

What we discovered in working with the soft core was the huge benefit of its flexibility. We were able to play with the cache size and run benchmarks to get a configuration that minimized the design's die area. Once we knew what we wanted, it was available immediately, not six months later. We were able to add scan-based testing to the entire design to keep test costs down. In addition, because ARC had the memory cores available, we were able to design in built-in self-test for the cache, further lowering test costs.

The problems we had with the hard core didn't exist with the soft one. Because it is synthesized from the same source as the behavioral model, there was no discrepancy between the core's design and the final silicon. Further, the IP of the CPU's design was ours, not the foundry's. That freed us from being enslaved to a single source that knew it had us locked in. We were able to get what we needed with no unnecessary circuitry, keeping the cost the lowest possible, and without waiting for someone else to develop it for us.

Going forward, the decision to use a synthesizable core will continue to provide benefits. We can readily migrate our designs as process technology changes and we can easily create derivative products to keep pace with the dynamic consumer market. The flexibility that the soft core provides has made it the right approach for our chip designs.