Going On A Quest

Over the extended Thanksgiving weekend, I went with my family to a hotel with built-in entertainment. The hotel had so many amenities as to make sure that you would never want to leave it: a water park, an arcade, multiple restaurants, miniature golf, and the list goes on.

The water park was the main attraction and ensured multiple hours of fun for the entire family each day. A wave pool, indoor surf facility, multiple slides and play structures guaranteed that everyone found something that they like.

It was, however, another attraction that entertained my children for many, many hours. You could buy a ‘magical’ wand and go on one of multiple quests. By waving your wand in front of a portal, you would get an explanation of the next steps in the quest. Typically, this meant that the children had to find particular objects that are located throughout the hotel. By waving their wand at the objects, the internal chip got updated and when they got back to the portal, they could move on to the next part of their quest.

This was truly a great way to keep the kids busy. They were constantly busy, moving around and they could safely roam around on their own, which was fantastic for the parents.

My children trying to defeat the dragon

It was also great to see children helping one another, even if they didn’t know each other. I was participating with my children for one section of the quest and somebody asked if we knew where to find the ‘eagle’s feather’. My son pointed him in the right direction. At another time my children had trouble ‘activating’ a star. Another child came up to explain that the star didn’t work anymore and that you could go someplace to get help to circumvent that part of the mission.

In my own world of prototyping, I do see our users go on a quest to prototype their IP, subsystem or SoC and bring up software or validate their system as early and extensively as possible.

Each ‘quest’ consists of multiple missions: partition the design, synthesize pieces onto the FPGAs, run basic tests, find and resolve any issues… And while today’s state-of-the-art prototyping software automates of lot of these steps, there is no substitute for experience and a proper methodology. This is where the experience of our specialists comes into play. AEs (short for application engineers) work closely with end users to help them go through the different steps or ‘missions.’

In this blog I want to deliver an ode to those AEs. They help novice users to become experts. They make sure that customers meet deadlines and fill in whenever some expertise is lacking. And on top of that, they help make the end product better. Whenever they run into a particular issue or have to work around something, they feed back that information to engineering so that the tool can be improved. And in the end that value may be worth even more than the instant help they provide. Whenever the tool improves, it helps all end users and produces a kind of scale which is hard to match with pure man power.

So the fact that prototype bring up can now be done in days/weeks rather than months is the result of the continuous feedback about how to improve the initial prototyping software from years ago. The fact that issues can now be found and resolved more easily and that most validation tasks can be done pre-silicon can be contributed to early adopters and their willingness to be a champion for the technology, work with application engineers and step by step plow through any issues they encountered.

So in a way each small quest of prototyping a particular design contributed to the big quest of getting prototyping to the state where it is now: a fundamental tool to accelerate software development, hardware and software validation to create and deliver complex products faster.