Posted by sleal on December 18, 2012
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.
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.