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 February 27th, 2015
From time to time I like to use this blog to provide you with an update about the Better Software. Faster! book that illustrates the best practices in virtual prototyping. This time, I am happy to announce that Mamoru Kani-san, senior manager, R&D department 22, software 2 R&D division, of the corporate software development division of Kyocera Document Solutions wrote a new case study for the book. Kyocera’s case study explains how its software team leveraged virtual prototypes to develop device drivers for the DesignWare IP in their multi-functional printer SoC.
The book explains the use of virtual prototypes to accelerate software development tasks. Kyocera’s virtual prototype usage is an exact example of this. In the case study, Kani-san explains the importance of having transaction level models available for the main pieces of IP in their multi-functional printer SoC. The availability of TLM-2.0 LT models for their ARM and DesignWare IP helped Kani-san’s team to create a virtual prototype quickly and enabled them to focus on specific software development tasks.
Kani-san goes on to explain how the virtual prototype allowed his software team to complete 86% of the USB tests that they normally do with real hardware. The remaining software was mostly related to the USB PHY and typically done with real hardware.
Figure 1: Kyocera Document Solutions VDK for software development
You can read this case study and others by downloading the Better Software. Faster! book for free at following website: www.synopsys.com/vpbook
Posted in Uncategorized | No Comments »
Posted by Tom De Schutter on January 30th, 2015
We are living in the age of pictures. Just about any event or non-event in our life is being captured in a picture. Even more so, a lot of those pictures are being shared with others. It offers us a way to share a moment with the ones who weren’t there. Living with my wife and children in Silicon Valley, far away from our family in Belgium, it provides us with a way to show what we are up to and in that moment shorten the distance with our relatives.
On the other hand, having a camera-enabled device at our fingertips at just about every moment seems to make us want to take pictures of everything around us. Interestingly enough, one of the most photographed subjects is our food. While I was thinking about this, I recalled an old smart phone parody commercial, which is still very applicable and funny.
Another interesting use of lightweight cameras is in combination with a drone. There are companies working on drones that fly above you and track you while you are in action, such as while you are rafting or skiing. Even better than recording your ski skills from your helmet, have a drone actually record you while you are giving the performance of a lifetime thundering down the slopes.
What about having a small drone with you while hiking to fly out in front of you and provide a bird’s eye view of the road ahead, or more easily orient yourself in the context of your surroundings.
This is exactly what the Synopsys VP Explorer tool offers to software developers — a bird’s eye view of the entire system, both hardware and software, to better maneuver through the many lines of code and identify a particular issue faster. While I have been mainly focusing on the early availability benefits of virtual prototyping in this blog, with the right tool, a virtual prototype also provides additional benefits in terms of debug control and visibility.
So be the adventurer. Log all your activities, events and non-events, and share them with your fellow software developers so that together you can create better software, faster.
Somebody should write a book about this.
Posted in Uncategorized | Comments Off
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 | Comments Off
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 | Comments Off
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
| © 2015 Synopsys, Inc. All Rights Reserved.