BLOGS & FORUMS
A View from the Top: A Virtual Prototyping Blog
|A View from the Top: A Virtual Prototyping Blog|
Posted by Tom De Schutter on December 18th, 2014
Growing up in Belgium, it never occurred to me that rain or for that matter water can be in short supply. Living in California for over 8 years now, I know better. While I still enjoy the fantastic weather in the Bay Area, I do realize the importance of having enough rain and water. Water is one of those resources that we easily take for granted. It is in fact the most important resource, but we are just used to the fact that it flows out of a tap, hose or shower with the turn of a valve. According to recent studies, the last three years of drought were the most severe that California experienced in at least 1,200 years.
In the meantime November and December have turned out to be quite wet. While it is great to fill up the basins again, too much rain in a short time brings its own set up problems, like mud slides and trees falling down. On the other hand, it is clear that Californians aren’t really used to rain and call just about anything the storm of the century, as depicted nicely in following picture:
This cycle of extreme drought, followed by heavy rain reminds me of the problem software developers are facing. Without a strategy to incrementally get access to targets for software developers, the software development cycle for a particular project looks first like a drought: nothing is available to start software bring-up and then all of a sudden hardware is becoming available all at once and the pressure is on to deal with the software requirements of all IP blocks and subsystems at the same time.
A more incremental software target development plan can mitigate this problem and alleviate the pressure on the software team, resulting in a better flow between hardware and software and a better product overall, which is available in the market faster.
It is hard to achieve this flow using purely hardware based targets for software development. Inherently virtual prototypes can be available much earlier since there is no dependence on hardware. Plus the nature of having a model-based approach allows you to stage the incremental target availability any which way you want. That means that the software team can drive the stages based on the logical order of software bring-up, debug and test.
So whenever you find yourself in need of an earlier software target to mitigate the trend of software development droughts and floods for your project, you might want to turn on the virtual prototyping hose to ease the software development flow.
Posted in Uncategorized | No Comments »
Posted by Tom De Schutter on November 21st, 2014
As announced on Nov. 5, Synopsys virtual prototyping book achieved a remarkable milestone of more than 3,000 copies in distribution to more than 1,000 companies. The success of the book highlights the interest in virtual prototyping as a key methodology to shift left software development.
Upon the book’s publication, we received a lot of interest from China and Japan for translated versions of the book. Receiving such high interest for the book in both languages motivated us to start translations, with the Mandarin version already available on the Web site. Soon to follow will be the Japanese translation, scheduled to become available around the end of the year.
In return for downloading a free copy of the eBook, we asked people to fill out an online survey. The answers to this survey confirm the most common software development challenges and virtual prototype benefits that are discussed in the book.
When asked, “What are your biggest software development challenges,” the No. 1 answer by 36% of the respondents was software complexity. That was closely followed by late availability of hardware (31%), changing requirements (27%), and limited debug visibility (24%). (Note that respondents could mark multiple answers for this question.)
It is clear from these answers that software developers are under constant pressure to meet tight deadlines while dealing with increasing software complexity and changing requirements. So it is not a surprise that they are looking for new methods to pull in the software development effort, manage increasing software complexity and late hardware availability. Many software developers have found that virtual prototyping helps to solve these challenges, as evident from more of our survey responses.
When asked, “What is the most important benefit you have seen from using virtual prototypes,” respondents who used virtual prototyping in the past answered as follows: Earlier software availability (45%); better software quality (19%); tighter coordination between hardware and software teams (18%); and software bring-up and debug productivity gain (16%). (Note that because we wanted to understand the most important benefit, we only allowed one answer per respondent.)
I will use the findings of the “Better Software. Faster!” book survey in subsequent blog posts. For now I want to leave you with following observation: If 3,000 persons at more than 1,000 companies around the world are interested in learning more about virtual prototyping, you might want to take a look yourself.
To download a free ebook go to: www.synopsys.com/vpbook or If you would like a printed copy, you can purchase Better Software. Faster! at Synopsys Press, Amazon.com, or you can order a copy through any bookstore (ISBN: 978-1-61730-013-4).
Posted in Uncategorized | No Comments »
Posted by Tom De Schutter on October 30th, 2014
When marketing products, should you emphasize what is included in the product or what is not? These days it seems that for so many foods it has become more important to highlight what is not in the food rather than what is. With sugar free drinks, alcohol free cocktails, gluten free bread and dairy free milk, one might wonder what you should continue to eat or drink. In fact, you now often see food packaging with multiple lines of advertisement to indicate what is not in the food.
Maybe we need to adopt the same strategy for virtual prototyping. Now available: hardware free software development … There is actually something to it. It actually helps customers easily identify how the product is different. If you need or want to avoid gluten you choices are limited and a big brightly colored message saying: “Gluten free bread” avoids the need to check the contents of every bread package.
If you don’t have hardware available yet, you want to find that one alternative that can help you to develop software in the absence of a target hardware platform. So with this: if you are working on a complex multi-core electronics design and can’t start software development until you have hardware available, don’t look any further: virtual prototyping is the product for you. It has a nice colorful message saying: “Hardware free software development”. Even better, you can continue to use your favorite debugger with a “hardware free” target to start software development earlier than you could ever imagine.
Let’s embrace the marketing of products that are “missing” something. Hopefully the user will appreciate what he/she can get versus what he/she can’t get. Hardware may not be available yet, but virtual prototypes offer a nice early replacement with lots of control and debug visibility. Enjoy!
Posted in Uncategorized | Comments Off
Posted by Tom De Schutter on September 29th, 2014
As highlighted in many of my blog posts, virtual prototyping has really established itself as the key methodology to shift left software development by decoupling the dependency of software development from hardware availability. The success of the “Better Software. Faster!” book illustrates the wide spread interest in the methodology.
The success of virtual prototypes has also led users to find more ways to leverage them across a wider range of use cases. For certain tasks, the combined strengths of virtual prototypes and other methodologies can help you achieve a 1 + 1 that is bigger than 2. Examples of these great synergies are virtual prototypes + automotive tools like Saber and Simulink, virtual prototypes + FPGA-based prototypes (called hybrid prototypes) and virtual prototypes + emulation (called hybrid emulation). In this blog we will focus on the use cases for hybrid emulation.
I see three main use cases where hybrid emulation can provide significant benefits to its users:
- Software-driven verification: speed up software execution for SoC verification by running the application subsystem as part of a virtual prototype connected to the rest of the SoC mapped onto an emulator.
- Early software development: by mapping blocks of the design not available or easily modeled in a virtual prototype, like GPUs, onto an emulator, software developers can connect these blocks to their virtual prototypes to develop software in context of the full system.
- Architecture validation: once architecture exploration and optimization is done using traffic generators in virtual prototypes, hybrid emulation enables the traffic generation functions to be replaced with emulated cycle-accurate processor sub-system RTL running the real software for architecture validation.
Users around the world have experienced significant value from the above three use cases. A major SoC company explained how they first used a VDK (virtual development kit) to bring-up, test and debug their application processor software, like the OS and then connected the VDK to their GPU mapped onto an emulator (Synopsys ZeBu) to enable GPU software bring-up. The accuracy of the emulator environment also enabled them to optimize the caches in the system and complete the software performance optimization. Eventually they were able to validate the hardware and software by mapping the entire SoC onto the emulator. This step-by-step effort enabled them to fully leverage the strengths of the different methodologies such as high simulation speed of a VDK to boot up the OS and cycle accuracy of the emulator to optimize and validate the hardware and software.
The value of this hybrid emulation methodology is further explained in an article from Tom Borgstrom: http://electronicdesign.com/eda/hybrid-emulation-accelerates-architecture-optimization-software-development-and-software-driven-.
I also invite you to attend our session at ARM TechCon on this topic: http://schedule.armtechcon.com/session/synopsys-turbocharge-your-verification-with-synopsys-hybrid-emulation
Gwyneth Sauceda, one of our ZeBu emulator experts and I will explain the value of hybrid emulation and dive deeper into the different applications and customer case studies.
See you at ARM TechCon on October 1 from 12pm-12:50pm in the Mission City Ballroom M1 at the Santa Clara convention center.
Or visit us at the Synopsys booth #600.
Posted in Uncategorized | Comments Off
Posted by Tom De Schutter on August 25th, 2014
While traveling back to California from the U.K., I had a layover in Chicago, which is probably all too familiar to most United Airlines frequent flyer members. Everything went according to schedule until everyone boarded and the plane still didn’t take off. The pilot explained to us that there was a problem with the hatch for the refueling of the aircraft. We were stuck in the plane for about 2 hours. Eventually the captain announced “We have just about enough fuel to get us to San Francisco.” While I don’t doubt that United wouldn’t allow an airplane to take off if it had “just about enough fuel,” it was an interesting set of words to hear from the captain. This made me wonder what does, “just about enough” mean in the context of software development and virtual prototyping.
An interesting measure of lines of code: students of the Code.org tutorials have written 1,969,497,657 lines of code. About 100 of these must have been from my son who went through a couple of their online coding tutorials. It is a great way to get your children introduced to programming.
And as beautifully illustrated on http://www.informationisbeautiful.net/visualizations/million-lines-of-code/ the lines of code in products have dramatically increased over time. So what is “just about enough code” in that context? Apparently it is very dependent on the product, e.g. software in cars is now reaching 100 million lines of code.
Any way you look at it, the software content is growing in just about every imaginable electronics product. And with over 18 million students trying out the tutorials of Code.org, the interest in “code” is growing as well.
With such a reliance on software to drive electronics, “just about enough” code isn’t cutting it. Neither is being “just about on-time” to have software available to release a new product. The new heartbeat of electronics products requires an equivalent heartbeat on the software development side. Like in real life, you wouldn’t want any sort of heart rhythm disorder (an abnormal variation from the normal heartbeat). While virtual prototyping might not save lives preventing heart rhythm disorders, it can help you achieve a healthy heartbeat to align software development alongside hardware development. And the great thing is that “just about enough” virtual prototyping will ensure that you can develop more than enough software to successfully launch your product with the right functionality and on time!
Posted in Uncategorized | Comments Off
Posted by Tom De Schutter on July 23rd, 2014
Last month we undertook a big family trip. My parents, my brother and his family came from Belgium to California and together we embarked on a trip across the North West US. Starting in Silicon Valley we drove via Lake Tahoe and Salt Lake City to Yellowstone. Afterwards we crossed over to Seattle and Portland to finish off the trip with visits to Crater Lake and Lassen Volcanic National Parks. In total we travelled about 3,400 miles or 5,500 km.
One of the unique sights in Yellowstone
For those of you who have been there, it is probably not a surprise that Yellowstone was the absolute highlight of the trip. It just has everything: lots of wild life, beautiful sights and unique wonders of nature, including a wide variety of thermal activity as you can see above. One of the coolest things happened when we were waiting in a traffic jam, most likely caused by some bison crossing the road further up. Right next to us was a river and at a certain moment we saw an osprey dive into the river and fly off with a fish in its claws. The speed and accuracy with which the bird caught the fish was quite amazing.
Given that our group of travelers was quite diverse in age, level of interest and willingness to hike (we decided afterwards to “train” our children by going on hikes more often), it was important to create a balanced schedule and plan all the hotels and main sightseeing events in advance. Starting a virtual prototyping project is a bit like embarking on a big trip. Given that there are different software developers with different needs, it is important to carefully plan the different deliverables. And it is not just a matter of what needs to be available, but also when. It doesn’t help if a specific virtual prototype is available, but can’t be deployed because the software developers are still working on something else.
Phased virtual prototype (VP) availability enables software teams to start early, focus on the main software pain points and get value quickly
And similar to exploring nature, where you’ll never know in advance what type of animals or incredible sights you will encounter; it is also hard to predict which part of a virtual prototype will provide the most value. Depending on the issue, the ability to control and overwrite register values, or the context trace or function trace information might enable the software developer to find the cause of an issue more quickly and reduce the overall software bring up time.
With the right preparation and planning virtual prototyping can be quite rewarding. Software development in incremental stages is an immense benefit of virtual prototypes, which is amplified by the wide gamut of unique capabilities that are bound to bring a smile to the software developer’s face when he or she finally resolves a nasty bug.
Posted in Embedded Software, Multi-core debug, Shift left software development, Uncategorized, Virtual Prototypes | Comments Off
Posted by Tom De Schutter on June 25th, 2014
Guest blog by Achim Nohl
With great interest, I am following any news around the progress of Linaro and the Linux kernel community with regard to addressing all the requirements for an ARMv8 64bit server software stack. Well established standards, such as the Unified Extensible Firmware Interface (UEFI) and Advanced Configuration and Power Interface (ACPI) are impacting the development direction of the community big time.
UEFI is a mandatory standard counting 2226 pages which ARM servers need to adhere to. UEFI for ARM SoCs continue to be work in progress since drivers for many IP titles are still to be developed. Also, the whole aspect of secure boot is a big construction area. But, a major chunk of work has been done and Linaro is providing UEFI firmware as part of its open embedded release snaphots.
Virtual prototypes have been a critical enabler for porting an open source version (EDK2/Tianocore) of the Intel/Microsoft rooted UEFI standard. UEFI has not been that intrusive with regard to its impact on prior ARM Linux kernel work as ACPI is. ACPI, a standard for runtime configuration of the hardware has a tremendous impact on the Linux kernel. One of ACPI’s great impacts is its complete overlap with the objectives of the recently established device trees. Device trees have been critical for ARM to find a way out of the board support mess in the Linux kernel. Before device trees, each board/SoC had its own directory underneath the ARM architecture and was polluted with many vendor specific drivers and hardcoded configurations. With device trees, the entire configuration (e.g. memory, interrupt, clocks, voltages) is defined and called a flattened device tree file (instead of hardcoded in C). This is an ASCII file, which is compiled into a binary blob, and then analyzed by the kernel during the boot stage in order to configure its device drivers. Device trees have been fully adapted for the ARM 64bit kernel port and as a result, there are no longer directories for SoCs or boards. The same binary kernel will run on any ARM hardware along with a separated configuration file, i.e. the flattened device tree file. This could be the happy end of a nice fairy tale if the big bad wolf wasn’t coming around the corner.
That big bad wolf’s name is ACPI and unlike the fairy tale, he does have good intentions, but it will require a lot of changes. ACPI is important for standardizing the run-time configuration of a server system as datacenter operators will not want to care about the artifacts of the underlying hardware and would like to operate the servers in a uniform way. The scope of ACPI is very large and comprises system run-time configuration, power and thermal management as well as Reliability Accessibility Serviceability (RAS), e.g. hardware error handling support. ACPI has been declared as the preferred runtime interface for ARMv8 servers. ACPI is likely to be included in the upcoming ARM SBSR (server base firmware requirements) document which goes together with the ARM server standard SBSA (server base system architecture). As a consequence, drivers will need to be adapted to be able to obtain their configuration via ACPI rather than the device tree interface.
However, this is not the end of the story. The biggest impact of ACPI may come through the changes needed for low level power management. Historically, ACPI has been defined to shift power management of the BIOS (predecessor of UEFI) into the operating system in order to perform operating system power management (OSPM). The OS is supposed to be able to execute wise decisions for run-time power management, since the OS has an understanding of the varying performance needs and through guidance from the upper application layers it can even take the usage context into account. With this, the OS can deliver the right Quality-of-Service (QoS) and trade off power and performance demands optimally and dynamically. Of course, this is not new for ARM Linux and run-time power management has been a sweet spot due to ARM’s deployment in the power sensitive mobile market. But, with ACPI fundamental changes coming into the picture, the low level clock and voltage control implies that the drivers for clock and voltage regulators will no longer be part of the kernel and will need to be done by the firmware through ACPI. This concerns all components, the CPU as well as the peripherals. For the kernel developers, this means giving up a lot of control and is highly debated. But, ACPI is a mandate and there is no way around. Especially, when dealing with clocks and voltages a lot of debugging challenges arise. Not only can you can break the hardware through violating voltage ranges, but debugging un-powered hardware or transitions such as suspend/resume is not any fun. Now this gets even more complex as the low level power management need to be debugged across multiple software layers such as the kernel and the firmware. Another key challenge for the software developers is the missing hardware with sufficient power infrastructure in order to develop, debug and test the ACPI implementation for ARM. The demand for a development target for ACPI power management software is well expressed in this short video snapshot from a Linaro connect session in Asia, March 2014.
Functionally accurate models of hardware, such as virtual prototypes will again play a key role here. A key misconception of non-virtual prototype users is that virtual prototypes are too abstract here. In fact, power management software bring up has been a key use case for Synopsys virtual prototype power users in the past. Virtual prototypes are able to capture the software relevant power architecture of a SoC and beyond. This includes components such as clock management units, power management ICs (PMICs) as well as the power domains defined by the complex clock and voltage trees. Virtual prototypes can accurately replicate fault scenarios such as exceptions or time-outs due to accessing unpowered hardware. Instead of burning a prototype, illegal voltage settings will just result in an informative assertion for the software developer. Next to the aspect of simulating power management software, virtual prototypes provide exceptional debug visibility, even when parts of the system are powered off. Synopsys virtual prototypes extend the scope of the ARM FastModels and foundation models and allow capturing the SoC specific power infrastructure as well as integrate any other custom hardware, enabling everyone to live happily ever after.
Posted in ARM, Embedded Software, Energy and Performance, Power Management, Uncategorized | Comments Off
Posted by Tom De Schutter on June 3rd, 2014
The recently announced Synopsys IP Accelerated initiative perfectly illustrates how the functionality of a device is equally influenced by the hardware and the software. To enable applications on a particular device to use the interface IP like USB or Ethernet, a software program called a device driver is required to map the generic requests to the underlying hardware functions. Writing a device driver requires an in-depth understanding of how the hardware and software work for a given platform function.
The DesignWare IP Prototyping Kits and DesignWare IP Virtual Development Kits that will be offered by Synopsys will provide software developers a fully working reference design with reference software to develop the device driver for a DesignWare IP in the context of a typical design setup. This ensures much earlier and faster IP-specific software development and enables earlier software availability to speed up hardware-software validation and optimization.
Watch the demo on how to accelerate software bring up and debug with DesignWare IP VDKs.
As this blog is focused on exploring the benefits of virtual prototypes, let’s zoom in a bit more on the DesignWare IP VDKs and explore what value these can provide to software developers. While the software content keeps growing, both in size and complexity, companies continue to want to bring new products to market more quickly. It is thus only logical that there is a need to start software development earlier.
Virtual prototyping is a great way to achieve this as you can detach the ability to start software development from hardware availability. As explained in previous blog posts, it however takes time to adopt the virtual prototyping methodology as companies need to establish a modeling team and align virtual prototyping modeling with the software developers’ timeline and requirements.
DesignWare IP VDKs solves this for a particular software development task: each DesignWare IP VDK consists of a reference virtual prototype running reference software. The VDKs also come with Eclipse-based tools that interface seamlessly with the most popular embedded software debuggers. This means that the VDKs can be instantly used to bring up, test and debug DesignWare IP-specific software. The reference design is based on the familiar ARM Versatile Express development board and consists of a multi-core Cortex-A57 Fast Model from ARM. Since the DesignWare IP transaction-level model in the VDK is configurable, software developers can match the IP configuration to the one used in their specific design.
While software complexity won’t go away, new tools and methodologies help mitigate the risk of late software availability. It is therefore important that IP vendors embrace this methodology and provide the right software development solutions for designs that use their IP. The DesignWare IP VDKs show how out-of-the-box reference designs running reference software can speed time-to-market by providing a ready to start software bring up, debug and test solution for the IP-dependent software. That is truly a great way to accelerate IP-based product designs.
Posted in ARM, DesignWare, Embedded Software, Models, Multi-core debug, Uncategorized, Virtual Prototypes | Comments Off
Posted by Tom De Schutter on May 22nd, 2014
I recently bought myself an activity tracker. The watch-like device keeps track of how many steps I take and how high I climb, such as the amount of vertical feet I “conquer” by taking the stairs. From that it calculates the distance I travel and the amount of calories that I burn in a day. The device can also measure my heart rate and the oxygen level in my blood, but given the high heart rate I supposedly have even without doing any exercise, I seriously doubt the accuracy of the device on those accounts. While the information displayed on the device screen itself is already interesting, the data gathering and analysis opportunity multiplies through connectivity of the activity tracker with my iPhone. Through a Bluetooth connection, I can transfer all the data to a dedicated app on my iPhone. On top of that I log other activities like strength training and biking activity on another app that synchronizes the data with my activity tracker app. Plus if you want to, you can log all the food you eat and thus your calorie intake with a third app that again syncs with the activity tracker app comparing actual calorie intake versus calorie consumption.
This is of course only one example of the possibilities with today’s multitude of “smart” and connected devices. More than ever the world is full of devices that capture data for dedicated applications and are connected with each other and with a central PC, server or mobile phone/tablet that enables data analysis and the option to tune the functionality of the devices for which the data was gathered. This also means that for these devices it is not enough to develop and test these devices stand-alone. Both the hardware and the software need to be tested and tuned in the context of a complete system set up. First of all, all of these devices need to have an interface IP that enables communication with the “outside world”. Typical interface IPs are USB, Ethernet, and PCIe, like DesignWare USB 3.0 from Synopsys. And each interface IP needs to have an optimized device driver that enables smooth operation while still being power conscious. The development of these low-level software functions needs to happen as early in the design cycle as possible given software’s critical role to test any functionality of the resulting device. Hardware and software have become completely interdependent and a technique like virtual prototyping is required to enable early development of the hardware-dependent software. But, as indicated above, just developing and testing the hardware and software in the context of the specific device or SoC is not enough, it is critical to create the system setup so that the multitude of connections can be established and tested. These tests are important to verify and optimize the driver functionality of the interface IP. Virtual prototypes are also good for this task as they can represent the connection of multiple virtual devices before any of them exists in hardware. This pulls in the time at which the entire driver testing can be done and provides the software developer with valuable debug control and visibility that are unique to virtual prototypes.
As everything around us gets connected, it is important that the software development methods adjust accordingly. Software and system testing requires the full system setup to test the interaction of each of these “smart” and connected devices. Virtual prototyping can help with a lot of this work by e.g. providing a solution to develop and test interface IP drivers both within the context of a SoC as well as within the system context of multiple connected devices. So while my activity tracker is urging me to take more steps, I am helping promote a method to make the connected world a bit more of a reality, step by step.
Posted in DesignWare, Embedded Software, IoT, Uncategorized, Virtual Prototypes | Comments Off
Posted by Tom De Schutter on April 25th, 2014
The question in the title has been one of the most asked questions by my son lately. Or as my wife says, his brain is 90% focused on Minecraft and 10% on everything else. For those not familiar with Minecraft, it is a lego-like computer game or as the Minecraft website reads: “Minecraft is a game about breaking and placing blocks.” It has literally captured the imagination of my son and to lesser extent, of my daughter as well. They can build houses, boats, clouds, towers, bushes shaped like pokemons and so on. And since building the same stuff over and over again would be boring, the question of “What should I build next?” comes up a lot. As with any building environment (virtual or real), what you can build is bound only by the available building blocks. So the Minecraft developers have provided users with all sorts of building blocks like wood and stone. Other blocks like water and lava are also available and can be used to achieve interesting effects. Different coloring options put the finishing touch to any construction.
When you think about building a virtual prototype for your next-generation SoC, the question “What should I build next?” is actually a fundamental one. While you could argue that creating a virtual prototype that reflects your entire SoC will fully enable the software team to bring up, debug and test all software stacks, doing so would make you miss out on one of the fundamental advantages of virtual prototypes, which is to align the virtual prototype availability with software bring up and testing tasks to enable the software team to start as far ahead as possible before hardware availability. Yes it is possible to create a virtual prototype that reflects an entire SoC, but it will take a lot longer to deliver. Instead it is much more advantageous to stage the virtual prototype development such that each drop enables another piece of the software stack. On top of that, the resulting virtual prototype deliverables are actually not only available earlier to the software developers, they are actually better as they will simulate faster and it is easier to debug a minimal system rather than something that reflects every single piece of the SoC.
Once you know what to build when, the next question is all about available building blocks. Without the right set of transaction-level models you can imagine any virtual prototype you want, but it will be hard to meet the modeling deadlines. Luckily there are now models available for just about every commercial processor, infrastructure and interface IP. And advanced modeling tools make it easier to create models representing custom IP, pulling in IP-XACT or other data sheet related information to construct the model structure to which functionality can be added. Now the only thing that is missing is some coloring options to make your imagination go wild …
So when your children talk about something they built in Minecraft, just tell them what fantastic virtual prototype you created or used. You can even brag about all the bugs you eliminated in your software. Let’s see if they were able to successfully battle an equal amount of those so called creepers attacking them in Minecraft. Your job will all of a sudden start to look a lot cooler!
Posted in Embedded Software, Models, Uncategorized, Virtual Prototypes | Comments Off
| © 2014 Synopsys, Inc. All Rights Reserved.