How are you dealing with increasing chip design complexity? For ARM’s Hobson Bullman, it’s all about the tools. Bullman, general manager of the company’s Development Solutions Group, presented a talk, “Dealing with a Complex World,” at Cadence’s San Jose headquarters earlier this month. To start things off, Bullman shared an image of an old Tanzanian chopping tool made of stone, noting, “I like it because it’s evidence that two million years ago, engineers were creating tools, and we’re still doing that today. I’ve been doing it for 20 years, not 2 million, but it’s nice to see this built-in need for all of us to create tools.” Hobson Bulllman, general manager of the Development Solutions Group at ARM, talks to a Cadence audience July 9, 2015, about using tools to address increasing chip design complexity. Over time, systems, along with the software running on them, have continued to grow more complex. Take, as an example, a high-end mobile phone, circa 2000. This device typically contained one application processor, one modem DSP, and one simple OS. One person, Bullman noted, could understand the complete software stack. Flash forward to now and consider today’s high-end mobile phone. A Samsung Galaxy S6 has eight application processors; eight graphics processors; many embedded processors integrated in modem, WiFi, Bluetooth, GPS, and infrared; along with cameras, sensors, and sensor processors. Said Bullman, “The mobile phone today is a very complex computer…and nobody understands the complete software stack now.” Why FPGAs Are No Longer Ideal for Early Software Development In his role at ARM, Bullman, who is based in Cambridge, U.K., is involved in early software development, working with ARM’s partners to help them get their systems working and deployed. In the past, early software development utilized an FPGA and an ARM® multicore subsystem. You could then synthesize, say, your new modem IP on the FPGA and validate your software stack in real environments. But with today’s designs, using an FPGA has limitations, says Bullman. How can you synthesize a system with more than 20 large processors on an FPGA? Emulation is big business, but it’s difficult to get enough time or throughput on the emulator because it’s in high demand. And, he noted, if you wait for an ARM test chip to become available, someone else might get to market first. What’s the solution? One of the trends in early software development over the past few years is to start the process on models. Bullman noted that today, the majority of early software development of complex SoCs is on models. For ARM, that means ARM Fast Models, a fast-growing product line and an area of collaboration with Cadence . He pointed out that systems are getting to market quarters earlier through the use of models. “And the best of both worlds is taking the modeling trend and combining it with the accuracy of Palladium emulation,” said Bullman. Addressing Bring-Up with the Right Tools System bring-up is another area impacted by growing complexities, he said. In 2000, designers would use JTAG, the primary debug system at the time, for bring-up. Now, he noted, we’re still using JTAG, and only incremental innovation is happening. Because systems are more complicated, however, SoC designers often face problems with ARM CoreSight™ debug and trace technology , from incorrectly programmed CoreSight ROM to incorrect routing of cross triggers and insufficient bandwidth on trace routing. Tools are clearly needed to help designers get the IP right. Bullman discussed ARM tools for IP configuration and software debug that can help ensure the debug logic put into place is likely to be implemented correctly. ARM is also working with Cadence to expand the capabilities of the Cadence Interconnect Workbench to help shorten the performance tuning cycle. Linux: “A Massive Game-Changer” Bullman next discussed high-end software. Back in 2000, high-end software was fragmented. Not so much today. “The clear winner is Linux,” said Bullman. “There’s still a wide variety of software platforms out there that people are using to control the complexity of the software, but so many of them are built on Linux. This easy portability across a number of Linux-based products has been a massive game-changer and a really great way to control complexity.” Embedded systems haven’t been immune to the complexity trend, and surveys show that software is the key challenge engineers face. As Bullman pointed out, there’s no traction here in high-level programming languages, C and C++ remain dominant, and debug is still a top concern. “This means the value in microcontroller tools is shifting as complexity changes. Fundamentally, it’s all about engineering productivity and that’s definitely true with these microcontrollers. The next 10 years, the value is all about providing an integrated solution,” he said. Since the worlds of microcontrollers and physical memory lack their version of Linux, ARM also pushes for standardization. One manifestation of this is its Cortex® Microcontroller Software Interface Standard (CMSIS), a vendor-independent hardware abstraction layer for Cortex-M processors that specifies debugger interfaces. CMSIS represents an industry-wide attempt to reduce the effort of supporting new microcontrollers and to encourage portability of code between different ARM-based devices from different microcontroller vendors. Now that there are 20 vendors on board with CMSIS, there’s also an effort to use the standard to try and reduce the cost of software reuse through standard packaging. Looking into the Crystal Ball What’s next? Bullman highlighted some great Cadence and ARM collaborations coming up in areas such as hybrid roadmap alignment, fixed virtual platforms, and debug. Looking ahead, he sees these top trends for the industry, in order of importance: security, the emergence of more high-level languages, and standardization in Internet of Things platforms. Christine Young![]()
![]()
↧