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.
Guest blog by Achim Nohl
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:
This month Nithya asked me to contribute a post on hybrid prototyping and add some color to how design teams have been benefitting from integration between virtual and FPGA-based prototypes. It’s been about six months since Synopsys announced the availability of a data exchange which links a Virtualizer Development Kit (VDK) to the HAPS FPGA-based prototyping system based on AMBA transactors and the HAPS UMRBus interface kit. Since that time we have further validated popular use scenarios for a hybrid prototype. So, what are the cases where there’s a benefit to connecting a SystemC TLM based model to an FPGA-based prototype?
On a recent trip to Germany, I was a passenger in a car with my colleague Tom De Schutter on the German Autobahn. We had just landed in Frankfurt and were driving to Aachen, Germany. The anticipation of the potential speed at which we would drive created both excitement and anxiety in me. What I learned about driving on the autobahn was eye opening with how Germany allows for speed, but also enforces rules of the road to insure safer driving. You need to have a decent car, a driver who has nerves of steel and is trained with the rules of the road. It does help that the roads are in good shape and you are driving with others who have been trained from childhood to drive on the autobahn. I don’t claim to be an expert and won’t go into the details of the rules but will point you to this article on how stuff works on the Autobahn. http://auto.howstuffworks.com/autobahn2.htm It did get me thinking about the parallels of driving on the Autobahn and how we are driving faster and faster in the tech world with getting products to market. The whole product life cycle is shrinking while the complexity is increasing. Lifecycles of 12 months or less are quite common in mobile, consumer and even automotive and industrial cycles are shrinking. So how do you go fast and still remain sane? You clearly cannot do the same thing you did before and just attempt to do it faster. You need to systematically consider all aspects of the process to adjust for this speed. Going fast without training, rules of the road, better vehicles and roads can be disastrous. Changes are needed. Using yet another comparison, innovation in product without innovation in process and methodology, team dynamics and organization is like driving a Maserati without any training in driving a fast car. So why would you sign up for developing your new product in a much shorter time with the same process as before? Everything from social dynamics – how teams work together, the HW and SW development process, the testing process, the training process and rollout to the field and customers are all fair game for examination. When I wrote this article for Tech Design Forum, I had this in mind. De-risking a project and working with speed and yet quality is about changing the way we develop. – Not just using PowerPoint, spreadsheets and discussions to make design decisions but actually simulating the products and doing what-if analysis. – Not waiting till the end of the project to do 50% of the solution development i.e. Software. But instead, starting early, incrementally developing and testing against targets available in each phase. For e.g. starting with models and moving to FPGA boards and sample boards and reserving only the final tests for the final boards. Why risk doing all your development on the final boards? Why not limit use of real hardware for the final test phase? – Even HW development can be agile, when you have multiple feedback iterations from running actual SW on the models even before RTL is created or committed to. Why depend on SW to work around any HW quirks? Why not change HW design early so both can be optimal? – Even when all SW teams are not available to work on the project, start with the sub-groups that are available. Enable them with portion of the prototype that they need to get their work done. – Why not do what if analysis with models so you can fine tune performance and power utilization? Why wait till you get complaints from customers to make the adjustments? The more we wait, the more expensive changes become. – Multicore designs are one way to get more horsepower into designs. But if you have horsepower without knowing how to use it can be a huge waste. Developing software for multicore designs is still an art and having more runways to do and test it with full visibility into the behavior of different cores is critical to its success. More than anything, as I get older and smarter I realize that I don’t want to stress my mind and work whenever I don’t need to. Gone are the days when I crammed for an exam the night before and stayed up all night. I plan and spread out my work over the days I have to minimize the risk, stress and wear and tear. It has resulted in better quality work and a happier life. I am also happy to say that I survived the autobahn and have a healthy respect for speed and that it can be done safely with some planning. Wish all of you speed, safety, happiness and a stress-free holiday season.
What does the Sagrada Familia and Embedded Linux have in common?
Posted in Embedded Software |