Posted by Tom De Schutter on December 19, 2013
To keep up with the continuous introduction of new gadgets and capabilities in our smartphones, cars, houses and stores, it is clear that we need more software programmers. That is why multiple companies are coming up with new and innovative ways to introduce people — especially children — to programming. To lure them, the makers of these programming products try to mask the programming aspect as much as possible under a layer of “fun;” whether it is having children design their own video game by mapping a maze and placing down obstacles, create a story through the drag and drop of graphic tiles in order to animate an object or build genuine robots with Legos and program them to interact with their environment.
The most frustrating part of programming, regardless of the form factor, continues to be finding and debugging an issue. First of all, figuring out if there is a potential issue is quite a task because it implies that you foresee all possible use cases and test if these function correctly. Even for the most well-known software companies this continues to be a stretch since we tend to use devices and software in a way that is unforeseen, or at least not properly tested by the software developers. Good testing is definitely an important skill to learn. I realized that this is less straightforward than you think when I reviewed a simple computer game that a seven year old had created, in which a droid has to maneuver through a maze guarded by another droid. When going through the different levels, I reached a level where there was no path from start to finish. Apparently there were a couple of extra walls that the seven year old didn’t notice before calling the game done.
Secondly, debugging an issue is easier said than done and the more items there are interacting, the harder it gets. So if you want your Lego Mindstorms to do something specific and it doesn’t work out the way you want, it might be hard to figure out what is going wrong. Are the sensors working properly? Is everything connected correctly? Did you write the software for the right environmental conditions? Or is there just a “plain” bug in the code? Having the right set of tools to review everything that is going on in the hardware and the software can be a big help to get to the bottom of the issue.
The concepts of determinism, visibility and control also significantly help to reduce the debug effort of complex software running on heterogeneous multicore designs. It might not have the same layer of fun compared to what our children are doing to get introduced to programming, but as was evident from an email this week from one of our customers, it is still quite satisfactory to see the Linux Penguin logo pop up after a successful boot sequence on a virtual prototype representing a device in development.
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.