Upping PSoC from 8 to 32
February 01, 2010
Ata and Ian discuss how a 32-bit MCU architecture meets high-performance expectations for embedded applications.
ECD: Why are you moving from 8-bit offerings to 32-bit cores in the PSoC programmable system-on-chip family? How easy is it to move up from the 8-bit families?
KHAN: When the PSoC 1 family began commercial-scale shipping in 2002, 32-bit cores were rare and expensive. Since then, they have grown in popularity to meet the higher-performance expectations for embedded applications where 8-bit multicycle processors used to be fine. Address space requirements are also growing due to large complements of peripherals and their need for device drivers, protocol stacks, and Real-Time Operating System (RTOS) requirements; 32-bit cores offer a contiguous 4 GB of address space versus a path that usually has a major discontinuity at 64 KB or some small multiple thereof. Finally, for code written with 16- or 32-bit variables in mind (common in C), processing is more efficient in terms of code density with 32-bit processors.
FERGUSON: One trend ARM has seen driving the demand for increased microcontroller performance is the growing complexity of algorithms. For example, the push for more energy-efficient motors requires much more complex motor control algorithms. Additionally, embedded systems that were previously stand alone are now adding connectivity, which then requires the support of communication protocol stacks and potentially security and/or encryption algorithms. The corollary to this is the overspecification of CPU requirements for the initial platform, reserving CPU bandwidth for the deployment of future services.
KHAN: The PSoC Creator integrated development environment (Figure 1) provides a new paradigm for embedded control design with the ability to move very easily from the 8-bit PSoC 3 family to the 32-bit PSoC 5 family. To move a design to a 32-bit core, all a developer has to do is select a different core in PSoC Creator and change those parts of the software that are core specific, which is generally only the interrupt controller. Assuming there is no assembly language, that’s it. All the peripheral selection and connection, the configuration, the pinning – nothing changes, and away you go.
ECD: What does an ARM Cortex-M3 do for PSoC designers and users that other 32-bit architectures can’t?
FERGUSON: There are two elements to this.
1. Breadth of software support. The ARM architecture is now the highest-volume 32-bit MCU architecture (per a July 2009 Gartner report). This means there are already various low-level OSs and middleware software such as communication protocol stacks and audio/video codecs optimized for use with Cortex-M cores. This leadership position and continued momentum in terms of market share growth and new licensees mean that new software elements will become available first for the ARM architecture as software companies look to prioritize rollouts toward CPU architectures that maximize ROI.
2. ARM’s continued innovation in processor architectures. ARM digested feedback from customers using ARM7-based MCUs and implemented enhancements in the Cortex-M3 processor. An example of this is the standard interrupt controller, which increases the number and flexibility in handling interrupts to deliver deterministic and faster responses to real-time events.
KHAN: Cypress’ requirements for a 32-bit core were that it have strong industry acceptance (and thus broad customer familiarity), a large ecosystem providing third-party software and tools, an efficient instruction set, good power management, suitable compilers available, and be a proven, verified design. The Cortex-M3 meets all these requirements and, as Ian alluded to, offers a strong roadmap based on their innovations. The potential of code migration to higher-end ARM Thumb-2 architectures and the availability of coprocessors are both intriguing.
ECD: If a designer already has AMBA-connected IP, how can that move over to the PSoC fabric and architecture?
KHAN: In some cases a specific IP block might require a bus bridge to be built depending on addressing and clocking requirements, but the PSoC fabric and architecture are AMBA compliant, so it would be very straightforward.
ECD: What tools are available for designers familiar with ARM to move into the PSoC environment?
KHAN: PSoC uses the standard RealView and GCC compilers and will support other popular compilers in the future. Its debug interfaces, such as JTAG, SWD, ETM, and SWV, are standard ARM interfaces. These standard tools and interfaces are supported within the PSoC Creator environment.
Ata Khan is responsible for developing strategic marketing and architecture for new PSoC products at Cypress Semiconductor, based in San Jose, California. Prior to joining Cypress, he worked for NXP (formerly Philips Semiconductors). Ata has an MSEE from UC Berkeley, an MBA from the University of Santa Clara, and a BSEE from the NED University of Engineering and Technology.
Ian Ferguson is responsible for supporting ARM’s (also based in San Jose) silicon and software partners drive into applications including home/SMB networking equipment, storage, printers, automotive infotainment, and white goods. He has more than 22 years of experience in engineering, marketing, and sales roles in processor-based SoCs targeting embedded applications. Prior to joining ARM, Ian worked at Enigma Semiconductor, QuickLogic, IDT, and Motorola. He has a BSEE from Loughborough University.