Drafting For First Place

By Tom De Schutter
I am a big fan of professional cycling events, and nothing can beat the Tour de France. Every year the best riders from around the world gather for what looks like an impossible task: This year they have to ride 3,404 kilometers (2,115 miles) in three weeks including five hill stages and six mountain stages. After completing that entire distance, all that separates the first rider, who earns the yellow jersey, and the second is a couple of minutes. Sometimes it is even measured in just a few seconds.

It is quite interesting how a sport that seems to be mostly about individual performance actually has a lot of team tactics that often determine winning or losing. One of those factors is the importance of drafting behind someone to reduce wind resistance. Each team will try to make sure that its best rider is shielded from the wind as much as possible. The wind factor is especially influential during the flat stages when trying to stay ahead of the peloton (the main group of riders). Teams with sprinters (people who are really good at accelerating over a relatively short distance and typically win when going to the finish line in a big group) can rotate at the front of the peloton and thus spend less energy pedaling against the wind than a smaller group of riders who each have to spend more time at the front of the group where the wind resistance is the highest.

So how does this relate to virtual prototyping for software development you wonder? More than you might think. I like to compare the transaction-level models, required to build and run software on a virtual prototype, with bicycles. While there is a minimum set of requirements for a bicycle and a model to be useful, there are specialized bicycles for specialized tasks, such as a time trial. Similarly, you need specific capabilities in your model depending on the software task you want to perform. If you want to test a network of VDKs (Virtualizer Development Kits), you need to have a model that enables this type of connection.

Besides models, off course you also need capabilities that ease the debugging and analysis of the software activity. Compare it to the team infrastructure that helps the riders, who in our analogy are the software developers, to perform their job. I am thinking about the mechanics that make sure that the bicycles are up to the task and who quickly fix mechanical problems during the race, much like model developers whose task it is to make sure models are available early and with the right characteristics. During the race, the riders receive all sorts of information about the distance to the finish line, the time difference between them and the rest of the peloton and so forth. This is very similar to the debugging and analysis features in a VDK. And one of the key differentiators of virtual prototypes, besides the most obvious one being early, ahead of hardware availability, is the fact that they enable better team work.

Whether it’s between the hardware team and the software team, between the semiconductor vendor and their customer, or the OS provider and the rest of the supply chain, virtual prototypes enable the right exchange of information. They offer a way to reproduce issues and an easier way to work together to optimize the overall system. What better way to win the yellow jersey and fight to hold on to it until the time it really counts (at the end of the three weeks during the last stage in Paris), when you have an entire team that will help you get to the finish line? Be it by keeping you out of the wind, catching up to a competitor or literally lending you a wheel, having a good team is essential to perform.

I want to leave you with a great example of teamwork and leveraging the wind. For those of you who don’t want to watch the entire video, go to 00:31 to see one team getting away by coordinating the team rotation perfectly or go to 00:59 to watch the stage summary.

—Tom De Schutter is senior product marketing manager for Virtualizer Solutions at Synopsys.