Frank Schirrmeister Blog

System to Silicon Verification – CDNLive Gives a Reality Check on How Hardware and Software Meet

fschirrmeister — Fri, 08 Mar 2013 18:22:00 GMT

Ever since switching from being a hardware/software chip developer to being an enabler with tools in EDA and embedded software, I was part of a team working towards methodologies and tools to improve the interaction of hardware and software. In December last year -- 15 years in -- I summarized a great year 2012 in a blog "System Design 2012 - Real Users Achieving Real Results!". Well, next week (March 12-13, 2013) CDNLive in San Jose will kick off, and I am happy to report that we will have again a great lineup of users and partners presenting their approaches to dealing with verification from systems to silicon, in most cases involving significant amounts of software in the process. As a special perk, we will have Wednesday lunchtime discussions with our product management and R&D team on special focus topics centered around system to silicon verification -- so I hope to see you there!

As a leader of the product management team for the System Development Suite I am especially thrilled to see how the four pillar engines -- virtual prototyping, RTL simulation, acceleration/emulation and FPGA based prototyping -- are growing together. With our key partner ARM, we recently showed at Embedded World how we connected Palladium XP and a quad core A15 Virtual Prototype for early hardware/software development and verification. But there is more - and you can see most of it at CDNLive next week! The figure above gives an overview of the engines and their connections, and here is some of the key content to be presented next week:

Starting with pure Virtual Prototyping, ARM will show in session SYS204 "How ARM® Software Development Tools can Accelerate Your Time To Market". Focusing on software testing, Imperas will show in session SYS205 "Virtual Platform Based Software Testing for ARM-Based Systems" how to apply transaction-level based techniques.
Showing the value of connections of Virtual Platforms to RTL - both in simulation and hardware acceleration - our IP Team at Cadence will show their use of virtual platforms in session DVSY104 "Using Virtual Platforms for Firmware Verification". BlueSpec will illustrate in session SYS203 "Bridging Virtual Platforms and FPGA-based Prototypes for Early, High-Speed, Accurate Software Development" how to connect our Virtual System Platform (VSP) and FPGA based Rapid Prototyping Platform (RPP). Similarly to what we showed with ARM at Embedded World, we will show in session SYS303 "Improving Speed and Debug-ability of Emulation / Prototyping Phase of ARM SOC Development" how to connect VSP with the Palladium XP accelerator/emulator.
Acceleration and Emulation will be prominently discussed in several customer sessions. Freescale will show performance validation in session SYS102 "Case Study: Using Cadence Palladium for SoC Performance Validation and Analysis". Intel Corporation will show in session VER102 "UVM-e Based Validation IP re-use for Emulation" their use of UVM with emulation. AMD will provide an update on in-circuit acceleration in session SYS104 "Enabling a New Paradigm of System-level Debug Productivity While Maintaining Full In-circuit Emulation Performance".
We will hear an update on recent successes Samsung had with Accelerated Verification IP (AVIP) in session SYS207 "Solid State Drive Verification and Driver Integration Using PCI Express Accelerated VIP". A key topic for emulation in System to Silicon Verification is Low Power, which we will show in session LP204 "Dynamic Power Analysis with Palladium" and LP201 "CPF Low Power Verification Using Palladium Systems". UVM and assertions in acceleration will be shown in session SYS304 "FastTrack Your UVM Debug Productivity with Simulation and Acceleration" and SYS206 "Shortening verification cycles and increasing chip quality with accelerated coverage". As already mentioned above, connections to virtual prototyping will be shown in session SYS303 "Improving Speed and Debug-ability of Emulation / Prototyping Phase of ARM SOC Development."
Incisive Verification will focus on various aspects like UVM, low power, verification planning, debug and gate-level simulation in a set of focused sessions including VER103 "Are you Still Building Test Benches?" presented by Sonics, VER206 "UVM Multi-Language: Technology and Reference Application", VER202 "Best Practices In Verification Planning", VER203 "Improve Debug Productivity from Hours to Minutes Using the Incisive Debug Analyzer", VER205 "Low-Power Verification in a UPF to CPF Flow", VER201 "Addressing Renewed Gate Level Simulation Needs at 40nm and Below" and VER104 "Advances in Client-Server Technology for More Verification Automation"
Verification IP can't be missed with sessions on DDR4, non-volatile design, Super-Speed Interconnect and performance debug in sessions DVSY105 "DDR4 System Design Challenges" presented by Teledyne LeCroy, DVSY102 "Non-Volatile Design Verification Challenges", DVSY103 "Is SSIC (Super-Speed Interconnect) - Revolutionizing the Mobile Design?" and DVSY101 "Analyzing and Debugging Performance Issues with Complex ARM CoreLink System IP Components" presented jointly by ARM and Cadence.
Further updates from customers and partners will be given on FPGA based prototyping. Freescale will provide an update is session SYS202 "Implementation of a Multi-threaded 64-bit Power Architecture Core on the RPP FPGA-based Prototyping System", I already mentioned above BlueSpec's update in session SYS203 "Bridging Virtual Platforms and FPGA-based Prototypes for Early, High-Speed, Accurate Software Development" and we will also provide a general update in session SYS201 "FPGA-based Rapid Prototyping - Help or Distraction for Embedded System Development?"
Finally, rounding up the full picture of System to Silicon Verification, you can catch session SYS301 "High-level synthesis introduction to C-to-Silicon Compiler" to see how to further optimize verification using high-level synthesis. My own session SYS101 "System to Silicon Verification - How It All Fits Together" will put everything in perspective on Tuesday morning.

So bottom line, this will be an exciting CDNLive for System to Silicon Verification next week. I am looking forward to seeing you for the sessions above, for lunches with R&D and for demonstrations during the exhibition.

Frank Schirrmeister

Securing Invisible Things … or “Why Denial Works!”

fschirrmeister — Thu, 28 Feb 2013 04:00:00 GMT

The opening keynote of the Embedded World conference in Germany left me with chills. No, it was not a grand theatrical performance letting me crave for more. It simply scared the bejevies out of me with respect to the safety and security of embedded devices, some of which I use each day. Luckily -- as in so many other areas of life -- the cure simply lies in proper prevention before bad things happen. And guess what, tools like our System Development Suite may be central to the answer!

Stuart McClure, CEO and President of Cylance and former CTO of McAfee, opened his keynote with commentary that the safety and security industry may actually be worried about the wrong things. The way the security industry thinks about attacks is in several levels from 0-days (public and vendor don't know), 1/4 days (vendor knows, public doesn't, there is no fix), 1/2 days (vendor and public know but there is no fix) to 3/4 days (a patch is available but it is not installed yet). The real issue, he continued are infinite-days, i.e. when the vendor has decided that the vulnerability is a feature -- which means the vendor knows about it but has chosen not to fix it! With an estimated $10B connected embedded devices today (see the ARM Blog on Embedded World this week), there is lots of room for vulnerabilities!

I am a big fan of the TV series Homeland. In season 2, episode 10, called "Broken Hearts," vice president Walden dies when his pacemaker is hacked into. Well, that's exactly what McClure's team found to be true with insulin pumps and defibrillators- - they were open to vulnerabilities and could get hacked into. The demo video was quite chilling -- one sees the insulin pump and how it spills more than the maximum healthy dose.

We got to witness McClure hacking RSA keys extracted live from the RTOS of networking boxes; the flush of cash from ATMs, either done by USB stick or remotely; the hack into shared Knox boxes holding keys for buildings; pressure pumps overloading when hacked into and subsequently blowing up bottles; and also hacking into car networks demonstrated by the University of Washington and UC San Diego. He also scanned the rooms for Bluetooth devices with standard authentication to be hacked into before describing some of the root causes of some of the hacking techniques. Often existing legacy techniques -- like the existing infrared for the current Samsung SMART TVs like I have at home -- serve as a way in to hack the system.

It was not pretty.

McClure definitely had the audience smile when he showed a picture of Star Wars' R2D2 hacking into the Death Star to stop the trash compactor in which Han, Leia and Luke are trapped, calling R2D2 a "Ninja Hacker" and noting the lack of checking for human beings as a feature to be explained to the emperor as "Hey, we had the guys we are looking for but some robot hacked the Death Star to save them." He summarized security in Embedded Devices today as shown in the photo I took here. There is some weather proofing and resilience, and our devices need to be highly available and tamper proof. But nothing is really secure and of course "denial works pretty well." McClure got some laughs from the sufficiently concerned audience by showing a picture of a school house on fire, with the fire brigade all over the place because they are also watching a game of American football.

Was there good news? Yes. McClure pointed to the basic cycles of attack described in his book "Hacking Exposed" and showed how they can be essentially prevented by better planning. The classic loop of "Detect - Respond - Deter" needs to be enhanced with preventative measures, i.e. enhanced with the loop of "Design - Build - Assess." He called for better design leading to safer architectures, followed by better building using secure coding and QA and proper assessments.

What does this have to do with EDA and System Design? A lot!

One of the main objectives of the System Development Suite is to provide representations of the hardware prior to its availability, which allows software to be developed and tested early. Virtual Platforms can be stopped and debugged appropriately, and RTL registers can be evaluated together with the software accessing them in simulation, acceleration, emulation and FPGA based prototyping. What this allows us to do during the development phase is to specifically inject errors using the test benches for the hardware/software systems under development. In contrast to the real hardware, which is hard to bring into a specific desired state, the representations of the hardware software systems in the System Development Suite can be put in a targeted fashion into very specific states and can be stimulated with targeted verification sequences to test specific scenarios.

We are actually showing this at the Embedded Show with an Advanced Driver Assist System (ADAS) running on a virtual platform of the Xilinx Zynq-7000 (see below). We can inject very specific errors and trigger very specific scenarios.

Well, so we actually do help to make the world a safer place! See you at Embedded World or DVCon this week.

Frank Schirrmeister

Application Specific System-Design and Verification at Embedded World and DVCon

fschirrmeister — Mon, 25 Feb 2013 12:28:00 GMT

This week (February 25^th 2013) is a busy one for system development and the Cadence System Development Suite in particular. For mobility, the place to be is Barcelona -- the Mobile World Congress will show the latest in everything mobile and connected. For Embedded Systems development the place to be is Nuremberg, Germany, where Embedded World opens its doors as one of the biggest events in the world for embedded developments in both software and hardware. In San Jose, California, DVCon will be the place to be for everything related to verification, including hardware/software verification in the context of each other.

Personally I will be in Nuremberg. It seems like I drew the short straw considering that it is predicted to be 39 degrees F there on Tuesday, compared to 53 degrees F in Barcelana and 64 degrees F in San Jose. Still, I'll agree with Alan Tringham of ARM that Nuremberg was the right choice. In his Blog post he points out that the Internet of Things (IoT) as well as Embedded Software Development will be two key themes. And I had already previously pointed to same theme in an article on the IoT for Electronics Weekly.

What made this year fun was that the System Development Suite demo preparations for Embedded World and DVCon could leverage each other -- a clear sign that system-level design and verification are tightly interrelated. So what are we showing?

At Embedded World automotive is one of the key target application domains we are covering. From an electronics perspective, four key themes are in focus, as shown in the graph above:

Intra Vehicle Networking is a huge theme these days. Various connections vie for data they can carry across the car -- CAN, MOST, LIN, FlexRay and Ethernet. While we from a development tools perspective are pretty neutral on what connection carries what type of data, and who might win the MOST/Ethernet battle, networking overall is a key aspect for our system design tools as well as for the design and verification IP Cadence is licensing.
Consumerization within the car is the second key theme. The crossing line to mobility becomes very blurry here, given the multimedia and connectivity aspects of the technology in the dashboard. Also, everything called "infotainment" looks very similar to what we see in mobile phones and tablets. Convergence everywhere! From a development tools perspective the challenges look strikingly similar between these domains. Certainly hardware and software need to be considered together.
Body Electronics, i.e. everything under the hood, is the third key theme. Here the requirements are very automotive specific. Real time aspects need to be considered, checked with assertions and validated. But even here software and hardware work hand in hand and the solutions provided in our System Development Suite find their adoption, especially in connection with analog/mixed-signal effects representing the system environment that electronic contol units (ECUs) reside in.
The Internet of Things (IoT) is the fourth key theme, and here it is all about the car, as well as pieces of the car being connected to the system infrastructure. I had previously given some examples in "It's the Data, Stupid" and look forward to seeing some of them shown at the exhibition. Of course the IoT is not limited to just car related aspects, it easily extends to cows and sheep and of course to medical aspects.

Given that the distinction between application domains become more and more blurry, it was easy for our demo teams to leverage of each other. A summary of demos is shown in the graphic below.

The key themes from a tool perspective are links to implementation and links to the environment. The latter occurs with analog-mixed signal simulation and connections from Palladium XP emulation and RPP FPGA based prototyping via SpeedBridges, as well smarter combinations of the different engines, such as the combination of virtual platforms with accelerated or simulated RTL.

We look forward to seeing you in Nuremberg at Embedded World or San Jose at DVCon. If you are in Nuremberg, find me at the Cadence booth or the ECSI workshop "Embedded Software Development on Virtual Platforms - Are We Ready For Industrial Deployment?" at which I will present on Tuesday at 16:30 together with Methods2Business on development since DAC last year. See you there!

Frank Schirrmeister

A 10-year Look-Back from 2013 – Some Technology Predictions that are Coming True!

fschirrmeister — Wed, 23 Jan 2013 19:09:00 GMT

It is January 2013, the year has begun and it is time for my annual 10 year look-back to see how well technology predictions have been implemented or missed (you can find last year's look-back here). This year's trip into the garage to find my old January IEEE Spectrum issues brought back memories of where I was personally at that time.

Following the dot.com bust I had followed the Silicon Valley mantra that you cannot have lived there without having been involved with a couple of startups at least. I had been with AXYS Design Automation - a processor modeling and virtual prototyping startup - for a while and had returned to Cadence to lead the team working on the Cadence response to Synopsys's acquisition of CoDesign Automation and the SuperLog language, the predecessor of today's standardized SystemVerilog. From a general technology perspective, the cover of IEEE Spectrum January 2003 (see my scanned version below) got it right with their statement "From wireless communications to energy trading, never before have so many technology sectors been sick at the same time."

Flipping through the issue from January 2003, it turns out that from that slightly negative starting point, several predictions were right on. Harry Goldstein's "Hardware Hangover" described how system complexity was driving customers and vendors in the IT space "to seek solace and solutions in software." The HP Compaq merger had gone through the year before and changed the PC market landscape. In November of the year before the first Windows based tablet PC had been introduced - I am still using my first Toshiba tablet acquired in mid 2004 from time to time - and I vividly remember the discussion with a fellow colleague that the only thing wrong with it really was its thickness and weight.

The in-retrospect, most spot-on quote from that article comes from Mark E. Dean, IEEE Fellow at the time vice president of IBM's storage systems group. He is quoted saying that "Business won't drive the need for new technology. Entertainment and personal use will." At the time he predicted that a combination of enterprise software and corporate networks will supercharge mundane information gadgets, saying "I would be much more productive if, when I walked into my office, my PDA would automatically update the changes to my calendar or business events that happened while I was asleep. That's not the hardware; this is information management, the software."

In the next article in that 2003 IEEE Spectrum, "The Perfect Handheld, Dream On", Peter Savage talked about "new technology on the way to make your heart's desire a reality." He essentially describes what today's smart phones have to offer - combinations of web browsing, streaming video, MP3, games, connectivity with GPS etc. The discussion was still going on whether phone and PDA functionality should be kept separate - Palm rolled out the Tungsten T PDA - but in closing Peter essentially describes what was introduced four years later with Apple's iPhone when posing the question whether the dream device (or maybe dream twosome) is merely fantasy: "Not if the issues of power consumption, connectivity, and user friendliness are addressed using recent technological advances and research into consumers' needs."

Linda Geppert's article "A Sea Change for Semiconductors" reminds us how far we have come. We were just on the cusp of transitioning from 90nm to 65nm. Semiconductor revenues had set records in 2000, but they skidded sharply downhill in 2001 until the fourth quarter when the market began to recover with an upward trend continuing in 2002. In looking forward, Linda described the various trends in communications serving the need for companies and users to move far more data faster as well as the shift of leading edge processors to 64 bits. The other trend and issue that was predicted absolutely correctly was the issue of power consumption, and we are in the midst of further implementation refinements today: "Circuit designers [...] are enabling chips to turn off circuits when they are not in use and to turn down the operating voltage and frequency for applications that demand less than peak performance. In short, it will take all the tricks that process and design engineers can devise to keep power consumption within bounds."

10 years later I am quite impressed how most of the key predictions from 2003 have become true and the semiconductor industry has gone through more cycles since then. And as predicted I am dealing every day with the impact of software development, which has at his point become the biggest driver of change for design processes. And flipping through the 2013 prediction issue of IEEE Spectrum that outlines 22 tech breakthroughs to come - from Google Glass through Mini Cellular Base Stations to advances in display technology, supercomputing, Intel's getting a "grip on the mobile market", social media and Sony's PS4 - there is plenty of hardware/software innovation yet to come to keep life interesting!

Frank Schirrmeister

System Design 2012 – Real Users Achieving Real Results!

fschirrmeister — Fri, 21 Dec 2012 14:56:00 GMT

This morning the final success story my team has been working on for this year went live. Texas Instruments reports on how they achieved greater than 90% accurate correlation between an architectural power estimation and actual silicon! This deserves its own blog early next year, but meanwhile, it has triggered reflections on how the year 2012 went.

This year is special, actually, for me personally. It was this holiday season 15 years ago that I said goodbye to my parents and brother in Germany and moved to the U.S. to join Cadence, at the time as Technical Marketing Manager for the Felix Initiative, later resulting in the product VCC, short for "Virtual Component Co-Design." I remember the tearful goodbye 15 years ago and now all my bags are packed to go home to Germany to see my folks for the holidays. For sure I will have to report back whether the last 15 years were worth it.

In Germany the saying is that a man has to do three things in life to have lived: Plant a tree, write a book and father a child. I have planted many trees over the years in my garden. Check. I have at this point contributed at least 5 book chapters to various books -- two of them this year. Together with my articles and blog posts I am happy to argue the second point. Check. For the third point I have a wonderful almost 7 year old daughter joining me for the trip to Germany. Her Mom and I have now almost 8 years of successful parenting experience, but as all parents know, this is an ongoing project.

On the professional side my mission in the last 15 years has been like I remember Aart De Geus positioning it in a keynote at DATE in 2001 or 2002: "Now that the genome is deciphered, the design productivity gap is the next big problem to figure out. Let's get to it." And we have made huge progress! If anything, the year 2012 has been proof to me in many ways that real users are achieving real results using system-level design, and specifically with our System Development Suite.

Here are some of the highlights in my book:

We had entered the year with information on Panasonic's use of Palladium XP to verify hardware/software integration.
At DVCon we presented at NASCUG with Xilinx on the Zynq platform , its TLM enablement and effect on projects. We also were on a panel discussing Build or Buy with Xilinx and ARM on using hardware assisted verification.
Several customers presented on the System Development Suite tools during CDNLive! in March, including AMD on Palladium use for In-Circuit Acceleration, Texas Instruments on their Palladium Enterprise use, Freescale on using Palladium for test pattern generation, Xilinx on VSP virtual platform use for Zynq, Duolog in Virtual Platform Development, PMC Sierra on SpecMan and Palladium as well as ARM on virtual platform enablement.
Later in March Design West came along as well and we outlined how we partner with ARM.
At CDNLive! in Munich in May we announced In-circuit Acceleration and the System Development Suite 2012 and expanded support for Accelerated VIP with endorsements from NVidia, Freescale, Xilinx and AMD. At CDNLive! in Munich itself we had Texas Instruments (Co-Verification), Duolog (Virtual Platforms), ARM (VSP), Ericsson (Virtual Platforms) and Method2Business (Virtual Platforms) present on their system development projects.
We had 11 customers and partners talk about system development with the System Development Suite tools at DAC in San Francisco, at which also Gary Smith reported on ESL growth, including Method2Business (VSP), Rohde & Schwarz (Palladium), Xilinx (both on VSP and Palladium XP), ARM (VSP), LSI (RPP and Palladium), AMD (Palladium), NextOP (Palladium), Imperas (VSP), Le Croy (Palladium) and Dini (RPP).
Later in the year, at CDNLive! China, Nufront talked about their use of Palladium for tablet design, and NHIDC reported on their use of Palladium as well.
At CDNLive! India in October, ST Microelectronics reported on coverage on Palladium, Freescale described their FPGA Based Prototyping usage, Samsung described how Accelerated Verification IP is used to connect Palladium with Firmware development -- we later published more details on this particular use model and ARM described their use of Palladium.
CDNLive! Israel brought me for the first time to Israel myself, and I saw Freescale report on High-Level synthesis, SIGMA and CSR report on their Palladium experiences, as well as Samsung and Altair presenting as part of my overview on how they use RTL Simulation, Emulation and FPGA Based Prototyping in conjunction.
To round up the year we published success stories with Samsung on Accelerated Verification IP, Nufront using Palladium and getting 1000x speedup and now Texas Instruments (Low Power on Palladium).

What a year 2012 it was! I will truly be able to tell them that the last 15 years were well worth it! I witnessed system development to find adoption and this year especially a large number of real users were achieving real results.

Where will we go from here? I have been writing about my thoughts on that recently here in my Blog Frankly Speaking in my last post this year called "Looking back at 2012", as well as in my column Systems to Silicon in "Hybrid Execution And Software-Driven Verification Will Emerge In 2013".

Happy Holidays and let's have a great 2013!

Frank Schirrmeister

Securing the Internet of Things

fschirrmeister — Thu, 13 Dec 2012 00:26:00 GMT

While I had looked at the challenges of hardware/software integration in various application domains like automotive, industrial and wireless before, I had the most unsettling experience last week at the Amphion Forum in San Francisco in the application area of device security. I am officially scared. And I am somewhat hopeful that hardware/software co-development will help address the security issues I heard about.

When Kurt Stammberger, VP of Market Development at security firm Mocana, kicked off the event at 8:30am with the words that "we as an industry are behind and at risk of losing the fight on device security," I was brushing it off as good marketing after I had endured a long, rainy drive from Silicon Valley to San Francisco to attend. About ½ hour in I was on the edge of my seat because the examples given were real, and really scary.

Here are my favorite three scary stories:

Earlier this year in October a mysterious algorithm took 4% of trading activity, with a still unclear motive. It placed orders in 25-millisecond bursts involving about 500 stocks. It never executed a single trade and abruptly ended. It accounted for 10% of the bandwidth allowed for trading per day.
Just by analyzing the emissions of our phones combined with the characteristics of the phone's power profile, hackers could derive security keys in "10 seconds from 10 feet away." The RSA reference I point to here even talks about 30 ft.
The issue of the overheating burning printer, which can be caused by hacking into the CPU remotely and overheating it in overload. Good thing is that most printers, according to HP, include a thermal breaker to avoid thermal issues. And there will be a firmware upgrade.

OK, before I add to my Christmas wish list a safe place to put my retirement money, an emission suppressing case for my iPhone and an USB/Ethernet printer without wireless access, let's look how pervasive all this with be.

According to Mocana CEO Adrian Turner's presentation, the number of connected devices will grow from 9.8 billion connected devices to 28 billion in the next couple of years, with a business impact of $4.5 trillion. Some big numbers here.

Securely managing all those connected devices will be hard, given the complexity of various user segments combined with multiple platforms like iOS and Android, combined with a rapidly growing number of internal and external applications a corporation has to deal with, and then again combining this with a large number of different security policies.

In a panel called "2013 - When Devices Take Over," David Kleidermacher, CTO of Green Hills, emphasized software complexity and called for a government mandate on how to evaluate the quality of security. I asked the question whether this is mostly a software or a hardware problem or spans both areas, David was leaning towards software being the culprit while the other attendees were pointing to a balance of hardware and software.

Later in the Forum, Bev Crair, general manager for Intel's Intelligent Systems Framework, gave an interesting keynote, confirming that hardware and software are both part of the solution. That's where the combination of Intel's processors and specific hardware with McAfee's security technology makes intuitive sense to me.

Bev defined the Internet of Things (see the screenshot from her presentation associated with this blog post) as a "Global Revolution where billions of devices seamlessly connect, and are managed and securely interacting over a network for the purpose of intelligently acquiring data and turning data into actionable information that delivers value services." The resulting massive industry shift is driven by immersive experiences, cloud connectivity, data analytics, security and trust and workload consolidation. And security poses a real threat to this opportunity. I especially found a slide on the different stages of cyber attacks very insightful; early attacks were "ego" based, then they became "financial," evolved into real "espionage," to "weaponry" and eventually "purpose" -- Bev used the term "hacktivists" -- another form of ego again.

Security is a big issue. It spans all application domains like computers, wireless, industrial, automotive and is a combined hardware/software challenge. The EDA industry has a unique position here -- we know how to help users to develop chips without any bugs and verify appropriately. With software's growing importance and offerings like our System Development Suite for hardware/software co-development we can help play an essential role to secure the Internet of Things!

Frank Schirrmeister

Optimizing ARM Based Designs for Low Power using Emulation

fschirrmeister — Mon, 19 Nov 2012 14:00:00 GMT

The month November goes to the Brits, no question. Not only did the James Bond movie Skyfall open, but Santa Clara also experienced somewhat of a "British Invasion" for ARM TechCon in the Santa Clara convention center. To be there properly I even brought out my favorite new pin striped suit ;). With that being at the cleaners now that ARM TechCon is over, I am reflecting on what I heard. In my mind ARM TechCon's focus was all about low-power -- at all levels of abstraction.

Various presentations at ARM TechCon focused on low power, including one describing techniques at the system-level by my colleague Michele Petracca and Yosinori Watanabe on "Analysis of Software-Driven Power-Management Policies Using Functional Virtual Platforms." So what about the later stages once we have passed the TLM level? I recently had blogged about emulation and how many cycles it takes to verify a big.LITTLE sub-system.

Earlier this year at CDNLive China, Peng Wang of Nufront -- a provider of chipsets for mobile computing -- won the best paper award for a presentation called "NS115 System Emulation Based on Cadence Palladium XP". His presentation was quite fascinating. He described how Nufront used emulation to verify the third generation computer system chip NS115, which provides performance and low power execution for Android applications.

Speaking first of the challenges, Peng Wang described the NS115 as a very large and complex design of about 12M Gates, containing a dual core ARM Cortex-A9 processor, a Mali400 multi-core 2D/3D graphic processor, a dedicated 2D block for hardware acceleration and numerous interfaces and memory subsystems including LPDDR2 and a DDR3 memory interface up to 800 Mbps. Given that the design is running Android, external storage, multiple screen displays and the ability to accept data inputs from various sources need to be considered. This combination of features leads to a long start time for IC simulation.

For system-level verification, Nufront determined that software simulation and FPGA based prototyping were not suitable. RTL simulation was too slow, and the frequent design iterations and the need for full debug visibility made the design unsuitable for FPGA based prototyping in the stage of the project Nufront was at. This nicely validates the points I made earlier on the advantages of processor based emulation over FPGA based approaches -- both have their place in system development.

Nufront chose Palladium XP as their solution for emulating the ARM based NS115. They reported performance improvements of about 1,000 times over pure software simulation with up to 1.3Mhz real-time frequency for the NS115. They were able to synthesize and implement the whole chip of 12 million gates easily, and they could include external models for DDR and eMMc conveniently within the Palladium XP Verification Computing Platform. They also used real world Interfaces with SpeedBridges for VGA, UART, SD/MMC, JTAG and USB.

During software bring-up they compiled the Android kernel with default boot arguments, pre-loaded the kernel image into DDR using memory load functions, and modified the ROM boot code to directly jump to specific kernel positions.

Before booting full Android, Nufront used a BusyBox RAM file system that was small and simple, and supports basic Linux commands. Engineers loaded the kernel image without external storage.They ran test cases under the Linux console and eventually used the chroot command to switch to Android. On Palladium XP it took about 15 minutes to boot a RAM file system.

Later Nufront used a refined Android system to save boot time. After removing unnecessary applications, disabling the JNI functions and unnecessary JAVA classes, as well as removing some not useful items from init.rc, Nufront was able to boot an Android system in about 2 hours compared to a projected time of 83 days in an RTL simulator.

Once up and running, Nufront captured LCD frames using Video SpeedBridges as output, used as input events representing the key input, a monkey system generating touch input, and special commands to start applications, services and broadcast intent. To test an application they eventually ran benchmark applications pre-installed in the Android file system.

For power -- one of their key issues -- they used the Palladium XP Dynamic Power Analysis (DPA). This allowed NuFront to get data of power peak windows by collecting toggle and weighted toggle counts at low resolution. With that information they found power peaks and zoomed into the peak window and then re-generated the next iteration of data at higher resolution.

For the actual power analysis they generated TCF (Toggle Count Format) files for each peak and calculated the dynamic power consumption from TCF files, gate level netlist and other libraries. The figure associated with this post shows the results for a video decoding function for which Nufront was able to optimize the hardware/software interactions to optimize for low power.

In summing up Nufront's experience, Peng Wang cited four main results of their use of the Palladium XP Verification Computing Platform:

Nufront achieved 1,000x performance improvement over RTL simulation
Palladium enabled early system-level integration and software validation (Android/Linux) with the emulated NS115
Nufront correlated power consumption using realistic runtime environments and applications before silicon was available
Palldium's fast turn-around time greatly improved the efficiency of verification for Nufront

So how does one optimize ARM based designs for low power? At all levels from TLM through implementation! As this example from Nufront shows, emulation is becoming a crucial, necessary step for power optimization. Here is an example of a tablet device the NS115 enables - the IPS Tablet by Xusit.

If you want to read more about the power flows at TLM and Emulation, here is a recent article I wrote called "Optimizing for Low Power prior to Silicon Availability". And as I am writing this during a trip to New York in a hotel lobby between visiting my daughter's newly born cousin and watching "Spiderman - Turn off the Dark" tonight here at Broadway, I am reminded how necessary power optimization really is: Imagine five guys around a table at "Link @ Sheraton," all of us sharing two wall outlets to charge our various devices and power the laptop I am writing this on. Oh well. Way to go for power optimization.

Frank Schirrmeister

How Many Cycles are Needed to Verify ARM’s big.LITTLE on Palladium XP?

fschirrmeister — Tue, 30 Oct 2012 22:42:00 GMT

At the recent CDNLive! India user conference, Deepak Venkatesan and Murtaza Johar representing ARM India gave a fascinating presentation called "Verifying big.LITTLE using the Palladium XP". Registered

Cadence.com users can get the presentation here once the proceedings are published.

ARM's big.LITTLE platform contains the combination of Cortex A15 MPCores - for high performance required in compute intensive applications - with Cortex A7 MPCores, allowing low power execution of the majority of workloads. Key to big.LITTLE is the switching between the cores, which is enabled using a Cache Coherent Interconnect - the CCI-400 fabric.

Let's first look at the results of using Palladium XP. They are quite amazing:

ARM found more than 20 bugs, 8 of them of a very critical nature
They ran about a trillion cycles on Palladium XP per week during the maturity phase, 30% of them on big.LITTLE (the example design that was executed included more components)
ARM executed more than 14 billion transactions in the Cache Coherent Interconnect (CCI), 60% of them on big.LITTLE.
Average compile times for the design were about 30 minutes for design sizes in the 40MGate range on a single CPU!
ARM reported on three capacity/speed/domain combinations which were panning out as specified: 13 million gates in 4 domains, 28.5 million in 8 domains and 41.4 million gates running in 11 domains (each Palladium XP domain has 4 million gates), all of them running above 1MHz.

With the latter point ARM is using one of Palladium XPs unparalleled advantages - its fine granularity supporting up to 512 users who can access the Palladium verification computing platform in design steps of 4 million gate increments. The graphic below visualizes this. No, this is not a multidimensional version of "Battleship" ... each square represents a 4 million gate domain. So at the specific time this snapshot was taken, utilization was not 100%, but that is always a question of job management and ARM also made extensive use of Palladium XPs save and restore capabilities to fully utilize both emulation and simulation.

So how did ARM get to these results? According to Venkatesan, ARM's intent for system-level validation using Palladium was to perform "in-system" validation of ARM IPs by finding IP product bugs from real-world testing, which is not the same as the traditional SOC validation approach. To do this, ARM built a configurable system test bench supporting emulation and FPGA systems, and has developed payload generation tools for stress testing as well as many supporting automation flows and a support infrastructure. Test benches, test pay load and execution platforms work together hand-in-hand!

System-level validation is part of the overall functional verification phases. ARM separates five design and verification phases - "specification/planning", "implementation" leading to alpha release, "testing/debug" leading to beta release, "coverage closure" leading to limited availability customer release and then a "stress testing" phase leading to the actual product release. Nicely confirming one of my recent posts on verification complexity, the scope of verification is threefold - "unit", "top-level" and "system".

During the phase "specification/planning", both tests and the "unit" and "top" are planned, while requirements for the "system" tests are defined. In the phase "implementation" - during which RTL simulation at about 100Hz is the primary engine - test benches are developed and brought up for the levels "unit" and "top", while the system-level test planning commences in parallel. In the phase "testing/debug" (we are in alpha now) RTL simulation is complemented by emulation running at MHz speeds once RTL maturity allows it. Unit-level testing/debug and top-level directed testing/debug are complemented with system-level test bench integration and bring-up. This phase ends with a beta release.

From here ARM enters the coverage closure phase for the unit-level as well as the top-level. ARM revealed - using orders of magnitude - that 10's of billion cycles (10¹⁰) are performed per week to reach coverage closure at both levels, respectively. In parallel, system-level software testing and debug runs in emulation at about a trillion cycles (10¹²) per week. Now the design is mature enough get into the phase of limited availability for customers.

Before the actual full release, the phase of "stress testing" commences. Unit level soak testing requires 100's of billions of cycles (10¹¹) per week, as does the top-level random soak testing. At the system-level, emulation is continued at a trillion cycles (10¹²) per week. Once RTL is brought up in FPGA prototypes, they run at a quadrillion cycles per week (10¹⁵). Finally, silicon stress testing runs at about 1 GHz with 10's of quadrillion cycles per week (10¹⁶) once test silicon is available.

Still following? Yep, that's a lot of cycles! What this presentation nicely illustrates is the need for all engines to work in concert - RTL simulation, emulation, FPGA based prototyping and the actual silicon once it is available. All engines have their value and place, depending on the scope of verification and the maturity of the RTL.

ARM also described their main use model for Palladium XP. It is predominantly used as a stress testing platform, executing stress mostly from multiple IP configurations and payloads. It is also used to debug failures from other platforms (e.g. FPGA) because of its full vision mode allowing complete design visibility. This is nice customer validation of what I was outlining on the differences in debug in my posts on design productivity and processor based emulation. ARM also utilized other Palladium XP features for software analysis and qualification. And finally they built a LSF Scheduler scheduling multiple different jobs to utilize the various 4 million gate domains most effectively and to allow multiple users, designs and capacities to run simultaneously.

In addition, in this paper ARM also described how they've added coverage to their repertoire of verification techniques with Palladium XP. With coverage, they're getting a better handle on quantifying how well they are testing their big.LITTLE design and they plan on extending the usage of this simulation technique in the future.

Bottom line, verification is an unbound problem. A user never knows when he is fully done, has to work with confidence levels to decide when to tape out, and as this fascinating case study on how ARM verified big.LITTLE using Palladium XP shows, the number of cycles engineers had to run is simply mind boggling. The most effective use of the various execution engines and their efficient combination will only become more critical in the future.

Frank Schirrmeister

Changing the Game with Processor Based Emulation

fschirrmeister — Thu, 11 Oct 2012 22:08:00 GMT

I have always been fascinated by game changing moves. Some are more successful than others, but the general principle is always the same - coming with a gun to a knife fight. Two of my favorites are from sports. When I was a young rower, the moving outrigger was a game changer for a while and was a fascinating example of a game changing invention. The normally moving seat with fixed shoes and outrigger had been replaced by a fixed seat and moving outrigger and shoes. The advantages were proven scientifically and Peter Michael Kolbe became world champion in 1981 using the technology. The moving outrigger was banned from competition at the end of 1983.

The other cool example is that of Andy Granatelli who attended the 1967 Indianapolis 500 with an untraditional piece of equipment - a turbo engine which was much faster and had tremendous advantages over its reciprocating-engine rivals. Parnelli Jones drove the car in the lead for 171 laps before a simple bearing failure took it out of the competition. Granatelli had challenged the status quo by attacking the common notion of the underlying engineering architecture.

In our day to day lives in Silicon Valley high tech, this happens quite often. Clayton Christensen outlined this with the term "Disruptive Innovations" and you can pick your favorite here. In EDA I am lucky to be involved one of the most exciting markets right now - that of system development including hardware assisted verification. The latter enjoys some special recent attention ...

So what do rowing, the Indy 500 and Emulation have in common? Disruptive Innovation! FPGAs - which long had been at the core of emulation - are fundamentally not scaling well and the disruption is processor based emulation. Later in this post I will introduce three generations of emulation, and a couple of real life user reviews comparing how these measure up against user requirements can be found here and here.

So what is the disruption?

Earlier this year I was on a DVCon Panel called "Build or Buy: Which is the Best Practice for Hardware-assisted Verification?" What I remember most vividly to today is the commentary which John Goodenough from ARM, a fellow panelist, made repeatedly: "Well, everything is fine if your design fits into one FPGA. If it doesn't, then all bets are off!"

Let's take a step back and look at what hardware assisted verification is used for (I described more detail here in the context of system development). Before a chip is taped out it needs to be verified, and the tasks to do that can be categorized into four main use models - hardware verification, software testing, hardware/software integration and performance analysis/verification. The seven basic execution engines to run verification on - Software Development Kits (SDK), Virtual Prototypes, RTL Simulation, Acceleration, Emulation, FPGA Based Prototyping and the actual silicon in a Development Board - all have different strengths and weaknesses, like execution speed, bring-up time, HW debug, SW debug etc. Hardware assisted verification is really used in three forms during a project.

Here is what a typical flow looks like.

First, increased design complexity results in pure RTL Simulation becoming too slow even before RTL is maturing. Acceleration - the combination of RTL simulation and hardware acceleration - executes about 10x, 100x, sometimes 1,000x faster than pure RTL Simulation, but is generally limited to the KHz range. How applicable acceleration is to a project really depends on how fast a design can be brought up and how well hardware debug can be performed.

Second, emulation executes the full design in hardware, either with a synthesizable testbench or with connections to the system environment using rate adapters. Pure emulation gets the execution speed into the MHz range, fast enough to allow initial software testing. If RTL is still not fully mature yet, design teams have to trade off bring-up effort and bring-up time against the value of faster execution. Both hardware and software debug are important.

Third, for even faster execution, FPGA-based prototypes can get into the speed range of 10s of MHz, usable for verification regressions and software testing. Given the focus on speed, design teams are settling for fewer hardware debug features.

Going back to John Goodenough's panel comment, getting the design into multiple FPGAs is what the crux of disruptive innovation in emulation is about.

The more scientific way of looking at the problem is based on Rent's Rule. It predicts that a large FPGA will run out of pins long before all its available capacity is utilized (see graph below). Rent's Rule applies when a large design is pseudo-randomly partitioned into many smaller segments, and it statistically predicts the number of connections required based on the number of gates in the partition.

As a result, FPGA based prototypes need very special attention when it comes to partitioning and routing the design to be mapped into them, specifically because the FPGA capacity grows much more quickly than the available bandwidth between them. Time division multiplexing of wires seems to be the answer: several signals share the bandwidth of one wire and the less bandwidth that is required per signal, the more signals per wire can be used at the same execution speed. However, in reality small bandwidth per signal is hard to achieve in FPGAs because route delay unpredictability and timing constraints increase compilation time significantly. With unpredictable timing, capacity does not really scale and performance degrades quickly.

As a result users can find three generations of emulation:

First generation emulation relied (and relies today) on commercial FPGAs. Cadence actually used to have such a first generation emulation capability with the Axis Xtreme. It was focused on acceleration. But It turned out that the bring-up time - which is of crucial importance especially at the time when RTL is not mature yet, and multiple RTL revisions per day are made available - was too long to make it effective for acceleration.

Second generation emulation still did not make a disruptive change; it simply replaced commercial FPGAs with custom FPGAs. This allows incremental improvements for debug and routing difficulties, improving the time to bring-up somewhat. However, it did not make changes fundamental enough to overcome issues like Rent's Rule illustrated in the graph associated with this blog.

Third generation emulation - the disruptive change - happened about ten years ago when the Palladium team simply switched the fundamentals and replaced FPGAs with a multiprocessor engine, creating a processor based emulation system. The result is an engine with fixed bandwidth per signal, leading to scalability without performance degradation. On top of the FPGA related limitations in debugging the design mapped to them, the fundamental FPGA issues of long bring up time due to partitioning and routing difficulties have been addressed using static scheduling in a processor based verification computer - that's why we call it a Verification Computing Platform (VCP) today. Instead of long FPGA routing runs which can take 12 hours or more on multiple workstations, a compiler maps the design to Palladium at a performance of 50-70M gates per hour on a single workstation.

Besides other advantages like multi user access and high granularity, the results - as I noted in my recent Frankly Speaking Blog - are significantly faster bring-up times and better debug productivity, eventually resulting in the ability to do six or more design turns in a 24 hour day. This is important in those project phases in which RTL is not fully mature yet.

This all may sound bad for FPGA- based systems, but it really isn't. It is just important to emphasize when and for which use model they are applicable. They work at higher speeds that allow them to be connected to the design's environment, are ideal for software testing and hardware verification regressions. They are best used when the RTL is very mature and stable, and therefore hardware debug is no longer an important issue. And by the way, as part of the System Development Suite, we offer such a system as well -- it is called RPP, short for Rapid Prototyping Platform.

Bottom line, when choosing the right system for hardware acceleration, it is important for users to clearly understand their options between acceleration, emulation and FPGA based prototyping. Their choice needs to be driven by their use model and in which project phase they want to use it. Again, a couple of real life user reviews comparing how the three generations of emulation measure up against user requirements can be found here and here.

It is fun to be part of disruptive innovations in EDA!

Frank Schirrmeister

DAC2012: Xilinx Zynq-7000 - From RTL to Success with Emulation

fschirrmeister — Mon, 02 Jul 2012 13:00:00 GMT

It is nice to see when visions get closer to reality. When Cadence announced its vision for the System Development Suite back in 2011, offering a continuum of engines from virtual prototyping through RTL simulation, acceleration and emulation all the way to FPGA based prototyping seemed aggressive.

Or was it? Earlier this week I blogged about software enablement using virtual platforms as described by Dave Beal at DAC 2012, and today I am happy to report on Peter Ryser's presentation called "From RTL to Success with Emulation" given at the same venue. And there you have it. Not so far fetched, it is the System Development Suite in action! Xilinx used exactly the engines above for the development and software enablement of the Zynq platform.

Peter opened his presentation as a "story told by an engineering manager," providing an overview of how Xilinx used different prototyping/emulation approaches to develop and verify the Zynq-7000 silicon, how Cadence Palladium XP took an important role in the system verification process, what his experiences were to validate entire systems before tapeout, and how Palladium is used after silicon availability.

To make audience appreciate the verification complexity the Zynq development team was facing, Peter used the following graph:

The verification complexity is indeed quite daunting. The Zynq-7000 has a dual ARM Cortex-A9 subsystem, programmable logic, an operating system kernel and its high-level and low-level drivers, software libraries, and APIs that enable applications executing on it. All this has to be connected (and verified) to an ecosystem of software development tools, software and hardware IP, and hardware development tools with which the user adds custom logic, executing the "E" in Zynq EPP (Extensible Processing Platform).

Peter described a system verification approach combining prototyping and emulation. Peter presented the need for different development platforms using a graph outlining the relative cost of a bug. Normalized to the cost of a bug found and fixed in the architecture phase, it is 3 times as expensive in the design phase, 10 times as expensive during the block development phase, 30 times as expensive during system test and 100 times as expensive when a bug is found after the device is shipped to customers. So it is important to find bugs as early as possible!

Next Peter described the tradeoffs of the different development environments used by Xilinx during development - discussing the differences in visibility, speed and debug capability. His description started with emulation running at about a MHz with great visibility. Next the multi-FPGA prototype used during development (the picture showed six Xilinx FPGAs) runs at about 10MHz, is good at finding issues, but offers only OK visibility. FPGA prototyping extends the speed to about 50MHz, is excellent at finding issues but again only OK with respect to visibility. Validation on the actual silicon runs at the actual speed (800MHz), is best in finding issues but offers pretty low visibility. Still, all the development platforms have their place, together of course with the virtual platform described in earlier blog posts.

With respect to emulation and Xilinx's use of Palladium, Peter described two use cases:

1. The first use model is a classic verification use model. Starting with tests on the prototyping board and identifying bugs, the design is migrated to Palladium and the bug is reproduced and "root cause" analyzed there. Once the bug is found, the RTL is fixed and tested using simulation-based unit verification. Then a new verification cycle starts using the prototyping board.

2. The second use model could be called system verification or system validation. The fixes found using the use model described above are tested within the design's system environment, and sometimes alternative fixes are evaluated this way too.

With Palladium at the center of both use models, Peter summarized the value as providing high visibility into complex bugs, good trigger capabilities, and interaction with the external hardware through Speed Bridges. In addition, Palladium is valuable due to its simulation waveform generation, which is used by Xilinx hardware engineers to find root causes and fix issues and is even sent to 3rd party IP vendors for bug analysis. Furthermore, Palladium's quick compilation turnaround time allowed Xilinx to rerun bug scenarios to find the right subset of interesting signals, run experiments to find the best bug fixes, rerun complex system-level tests to verify bug fixes, and to look for shadow bugs and what Peter referred to as "rats nests."

In closing Peter talked about the successful bring up after silicon arrived and recognized Palladium's contribution to the post silicon success by allowing to re-run scenarios found in the real silicon with higher debug visibility offered by emulation. The DDR memory was working on the second day, Xilinx had SMP Linux booting on day 3, the first shipment to a customer happened on day 9, who had it running on day 11.

On day 18 Xilinx was able to connect a camera and see video, on day 20 the Ubuntu desktop was running, and after 35 days the evaluation board was ready and Linux ran with HD 1080p video at 60 fps. Peter attributed this success to the development approach of combining various prototyping techniques, and of course Palladium emulation was at the center of all that.

It is great seeing the vision of the System Development Suite coming alive. With Peter's and Dave's presentations Xilinx is living proof that its vision is finding customer adoption!

Frank Schirrmeister