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.
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.
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.
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.
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.
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.
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.
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 ;-).
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:
Patrick Sheridan is responsible for Synopsys' system-level solution for virtual prototyping. In addition to his responsibilities at Synopsys, from 2005 through 2011 he served as the Executive Director of the Open SystemC Initiative (now part of the Accellera Systems Initiative). Mr. Sheridan has 30 years of experience in the marketing and business development of high technology hardware and software products for Silicon Valley companies.
Malte Doerper is responsible for driving the software oriented virtual prototyping business at Synopsys. Today he is based in Mountain View, California. Malte also spent over 7 years in Tokyo, Japan, where he led the customer facing program management practice for the Synopsys system-level products. Malte has over 12 years’ experiences in all aspects of system-level design ranging from research, engineering, product management and business development. Malte joined Synopsys through the CoWare acquisition, before CoWare he worked as researcher at the Institute for Integrated Signal Processing Systems at the Aachen University of Technology, Germany.
Tom De Schutter
Tom De Schutter is responsible for driving the physical prototyping business at Synopsys. He joined Synopsys through the acquisition of CoWare where he was the product marketing manager for transaction-level models. Tom has over 10 years of experience in system-level design through different marketing and engineering roles. Before joining the marketing team he led the transaction-level modeling team at CoWare.