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 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 | No Comments »
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
Posted by Tom De Schutter on March 26th, 2014
As virtual prototyping has seen a wide adoption over the last couple of years, it felt like the right time to work with industry leaders across multiple applications and publish a book that captures the best practices in virtual prototyping. As editor of the book: Better Software. Faster!, I had the privilege to work with some incredibly knowledgeable people who have been deploying virtual prototypes for many years. The book captures the main benefits of virtual prototyping as the key methodology to shift left the design cycle: namely reduce the overall time-to-market by starting software development before hardware availability. Better Software. Faster! features case studies and best practices from companies across mobile, consumer, automotive and industrial applications including: Altera, ARM Bosch, Fujitsu, General Motors, Hitachi, Lauterbach, Linaro, Microsoft, Ricoh, Renesas, Siemens, Texas Instruments and VDC Research. As editor I can of course not do anything less than recommend you read the book, but really … do read the book ;-).
Maybe the most compelling reason of all to get the book is that it is available for free as an eBook at www.synopsys.com/vpbook. If you prefer a printed version, since there is still something nice about holding a book in your hands and going through the pages, you can order one on Amazon.com, Synopsys Press, or you can visit me at EE Live! 2014 at the Synopsys booth (#1924) in the San Jose McEnery Convention Center on Tuesday April 1st where we will hand out the first 100 copies of the book!
To give you a sense of what the book is about, below is a high level overview of the chapters and their content. I am convinced that this shift left methodology can help your company deliver better software, faster and as a result impact the entire product development cycle and increase product quality. Most of all, I hope you enjoy the read!
Chapter 1: We start by reviewing software development complexity resulting from the race towards “smarter” products, including the multicore challenge, the tight balance between power and performance requirements and the growing concern about security.
Chapter 2: We introduce virtual prototyping as the engine behind “shift left” and explain the main benefits of this methodology to help software developers cope with tight software schedules and complex software bring up, test and debug challenges. Case studies by TI, Siemens and Altera.
Chapter 3: We illustrate the advantages of using a combined solution, consisting of a virtual prototype and debug and analysis tools for software bring up tasks like boot sequence development, operating system porting and driver development. Case studies by Fujitsu, TI and Altera.
Chapter 4: We describe how the automotive industry is becoming more software centric and dealing with functional safety questions. Virtual prototypes are helping by providing key capabilities to enable extensive software testing. Case studies by Bosch, Hitachi and General Motors.
Chapter 5: We examine how virtual prototypes enable faster software development across the entire electronic supply chain. Case studies by Altera, ARM, Linaro and Renesas.
Chapter 6: For specific software bring up and validation use cases and for software driven verification it can be useful to combine virtual prototypes with hardware-based prototyping and verification solutions like FPGA-based prototypes and emulators. Case study by Ricoh.
Chapter 7: Semiconductor Engineering Editor in Chief Ed Sperling provides his view on the electronics industry and discusses the case for virtual prototyping with industry experts from Microsoft, Lauterbach and Synopsys.
Posted in ARM, Automotive, Embedded Software, Multi-core debug, Shift left software development, Uncategorized, Virtual Prototypes, Wireless | Comments Off
Posted by Tom De Schutter on February 25th, 2014
Last week I was traveling across North America visiting customers. Besides being amazed at how cold it is in the rest of North America (I live in Silicon Valley where the sun has barely left us during the entire winter), it was good to talk to a wide variety of companies and discuss their software development needs. We encountered three types of companies considering the use of virtual prototyping to pull in their software development schedule:
Type 1: Companies that have used virtual prototypes in the past or other groups inside the company have used virtual prototypes and are preparing for their next design to deploy a virtual prototype to start their software development effort before hardware availability. At these companies virtual prototypes have become the norm to meet the SoC delivery schedule.
Type 2: Companies looking for a point solution to pull in one specific aspect of their software development effort. The overall software stack might not be too complex to require a virtual prototype to start early and benefit from the extra control and visibility, but for certain tasks, typically device driver development, OS porting or boot code bring up, virtual prototypes provide an instant ROI. Especially with pre-constructed virtual prototype packages that contain a reference design using their target architecture e.g. ARMv7 or ARMv8, and interface IP e.g. DesignWare USB 3.0 or DesignWare Ethernet, the software team is up and running quickly and can develop the specific software much faster than with any alternative software development solution.
Type 3: Companies where things are starting to break. When I bring up my slide highlighting the value of shifting left, namely pulling in the software development task alongside the hardware development, there is an aha moment. These companies recognize themselves in the “before virtual prototyping” setup: full serial development where all focus first goes to the hardware bring-up and only once the hardware is ready, the software team comes into play for that specific design. While for many products this might be ok, but for a lot of other applications there comes a point at which this methodology causes issues: e.g. late time-to-market, poor alignment of hardware and software or poor software quality due to increased software complexity and tight development schedules. This is where companies can benefit significantly by adopting virtual prototypes. But like with many things, the saying “no pain – no gain”, is very true in this situation. As one of the key engineers stated during my recent visit, “even if we had a virtual prototype today, there wouldn’t be anyone available to use it as all software developers are still working on the previous design.” So how do you turn serial hardware/software development into parallel hardware/software development? In a lot of cases it requires a top down mandate. Only through tight coordination and planning and moving resources to fit the new methodology will virtual prototyping truly provide its full benefits. You can only achieve a game changer experience if you are willing to … change the game.
As I encountered a lot of snow during my trip across North America, it is also interesting to see the perception of snow as a problem or not. In Texas snow is so uncommon that there just isn’t material available to deal with it. While in Minnesota snow is just a fact of life during the winter. See the impressive picture below of a series of snow plows clearing the snow in Minnesota’s Twin Cities.
So where for some the software content is not big or complex enough to need a lot of attention, others require a targeted solution for a targeted problem (comparing a single snow plow to an out-of-the-box virtual prototype for device driver development). And for many others the software complexity has just become a part of their product delivery and scheduling and through tight coordination and the right tools, they learned how to deal with the complexity. If 6 snow plows can clear a highway, a well-orchestrated virtual prototyping methodology can remove any software roadblock.
Posted in ARM, DesignWare, Embedded Software, Uncategorized, Virtual Prototypes | Comments Off
Posted by Tom De Schutter on January 28th, 2014
Let me first start off with wishing everyone a great New Year! I wish everyone good health and a lot of friendship and love. And hopefully all those software driven devices around you will make your life better. At least that is the goal and the promise from the industry. I for one am a big believer in the benefits of a “connected” future. The Internet of Things really has the potential to improve our lives. That of course doesn’t mean that anything goes; we should be vigilant about privacy versus intrusion. On the other hand, the values are really too good to set aside.
While I am enjoying this abnormal winter, let’s just call it a summer, in California, I do realize the consequences of not getting any rain and hence the necessity of water for now and for the “real” summer. And while connected devices won’t be able to “fix” the weather, they might be able to help us use the limited water we have in the most optimal way. What if a sensor in the soil could “tell” us how much water is exactly necessary to e.g., grow a plant or maintain a piece of grass, rather than sprinkling an unknown amount of water at specific time intervals during the day? Some of this already exists, but is simply not used widespread.
Similarly, connected devices can help monitor the health of people and send a warning in case of an issue. It can allow elderly people to live longer independently with active monitoring capabilities offering peace of mind. I am, for example, always worried that some people who live far away from me might fall badly and become hurt to the point where they can’t reach the phone to call for help. With an active monitoring system, the device can start the call and/or warn someone to check out the person’s home and see if everything is alright.
As with a lot of new technology around us, it is the combination of hardware: sensors, modems, processors … and software that enables these new capabilities. A well designed solution can offer targeted capabilities at the right power consumption level. And with all these devices connected to the internet and software driving the “decision” algorithms and actions, it will be easier than ever to update the software based on new requirements or to fix known issues. Hardware-software co-design has never been more important to drive the future and make it a better place. Through virtual prototyping I am committed to contribute my piece of the solution. Sounds like a good New Year’s resolution to me …
Posted in IoT, Uncategorized | Comments Off
| © 2014 Synopsys, Inc. All Rights Reserved.