Mixed-signal chip designs with embedded digital signal processing are becoming more and more commonplace these days. How can you bring low-power processors, such as the ARM Cortex-M0, into such designs quickly and efficiently? A lunch panel discussion at the recent Design Automation Conference (DAC 2012), sponsored by Cadence, provided some answers.
The panel discussion was moderated by John Murphy, alliance group director at Cadence. Participants were as follows, shown left to right in the photo below:
The entire event consisted of questions and answers, except for a very brief presentation by Cosaro. He noted that NXP has a long history of developing microcontrollers, and that all of its MCUs have transitioned to ARM cores. He said that microcontrollers typically lag 3-4 years behind logic design when it comes to advanced nodes, but observed that "microcontrollers are dialing down to deep submicron processes, and what we're doing now is taking advantage of all the things that were done by leading-edge guys and bringing them back into our process nodes. We're doing back biasing and things like that to reduce leakage current."
Questions and Answers
Q: The scaling process is a path we've been on in the digital world, but analog doesn't scale well due to advanced node effects. What methodology challenges need addressing in order to move to the next process node?
Cosaro: There are analog parts the customer sees, such as ADCs and op amps. There's also the systems stuff, the regulators and things like that. So the problem of integrating analog is not just about the customer parts, it's about the system parts too. It's a challenge to make all that work correctly because typically there are many power domains. You might have a battery domain where voltage ranges from 1.8V to 5V.
Q: Power is very critical in embedded devices, but at the same time we have to be connected to the outside world, which is causing a shift from 8 and 16 bits to 32 bits. Doesn't this run contrary to low power concerns?
Pajak: Microcontrollers typically have applications where you wake up, take a sensor reading, and go back to sleep. Processors in the Cortex-M range are able to do this in fewer cycles and effectively reduce the amount of the active duty cycle for the device. A communications stack typically has 32-bit addresses. Moving this around with an 8-bit microcontroller, an 8051 for example, is going to take more cycles, so the entire device is powered up longer.
Cosaro: We've done a lot of benchmarking on code size, and we'll see maybe a 50% reduction in code size running the same algorithm in M0 class processors compared to an 8051,
Q: Is the flash footprint also important for power?
Pajak: Flash power can dwarf the processor power, so reducing the amount of flash activity goes a long ways to reducing the device power. In the Cortex-M architecture, versus 8-bit architectures, we've seen code size cut in half, with fewer instruction fetches from the flash.
Q: A digital low-power methodology is well established. How is low power design and verification done in a mixed-signal context?
Nizic: On the digital side we have a well established methodology supported by CPF (Common Power Format). At Cadence, we have extended our CPF support across our analog tools as well. For example, in simulation we can establish the state of the signals between digital and analog, so when digital shuts down we properly set the signals for analog.
Q: Embedded controllers are very cost-sensitive, perhaps pennies per part. What are the key factors for controlling costs as functionality and connectivity increase?
Pajak: One consideration is the impact of flash on die size. The area of the processor is very, very important - in the Cortex-M0 we get this down to 12K gates in a minimal configuration. You also have to consider the rest of the logic on the chip.
Cosaro: Memory probably has the biggest impact on cost. In general, you start paying for memory once the footprint goes above 64K. If you can make the logic smaller that's good - if you can make the memory smaller, even better.
Q: MCUs typically interact with the outside world using analog interfaces and signals. This has to be part of system verification. But an analog solver significantly slows simulation. Can you abstract analog to higher levels?
Nizic: We put together a demo that models a system with a sensor and a regulator, controlled by two ADCs. Verilog-A and real number modeling don't slow the simulation, but they can model the behavior of the pressure sensor and regulator and engage the ARM core to adjust to the required pressure.
Q: Software is a big challenge. Do people need to consider analog as they're doing system-level modeling?
Pajak: From the Cortex-M0 user view, peripherals exist as a memory map. Programmers don't see the analog domain; they see a number from an address in memory that comes into an ADC. There's no need to use assembler. You can do it all in C.
Cosaro: In our environment we don't really know what the end application is going to be. We do multi-mode simulations, and we have models of ADCs. To make sure they're going to interact correctly with software, we write testbenches that correlate with what we think the customer is going to do.
Q: Now that more third-party IP is used in [mixed-signal] chips, what challenges in the ecosystem need to be overcome?
Cosaro: Taking the IP and making it into something that the user understands how to use. If I buy IP, it should come with documentation so it can be integrated. That's the biggest challenge for us.
Pajak: We license processors to companies like NXP and they have end users. We go to great efforts to make sure we have documentation not only for the purchaser of the core, but we also provide end-user documents that explain how the processor will work.
Cosaro: ARM is doing a good job of giving us documentation we can incorporate into our user manuals.
Q: What will make companies successful in managing more complex ecosystems?
Pajak: We have very deep collaboration, which involves Cadence from a flow point of view. Being open about your goals and having clear communications are key.
Nizic: At Cadence we like being customer-driven. Meeting customer needs in the methodologies and the tools is the best thing we can do.
Cosaro: I agree with that, and that's something we really appreciate with your company [Cadence] as well. We have on-site engineers who work with us very closely. If we have a problem you guys come and solve it. If something is wrong we tell you. It's really important to have a good dialog and open communications with your tool partner.
Some funny comments here...how can serious people compare CORTEX M0 code size with a 30 years old 8051 architecture !!! World has changed guys.Just look around and be a little more open to compare with nowadays 8 bits architectures