91³Ô¹ÏÍø

Lego, to me, is the easiest way to explain the prototyping design task. When you go through the Lego set up instructions, it is typically split up into instructions for smaller subsets of the end result: the right leg of a robot, or the garage of a fire station. Similarly, you typically prototype a subset of your SoC first: the USB 3.1 subsystem or the camera interface¡­ Then you start putting the pieces together to form a subsystem: the modem subsystem or the video subsystem¡­ And eventually bring everything together to prototype the SoC.

As a child I liked to build ramps for my toy cars or toy train and see how far I could make them jump. This again is very similar to how FPGA-based prototypes allow you to test a design¡¯s interaction with the real world. Does the power management software correctly make the design wake up when a USB device is inserted in the PHY daughter board? Does the embedded software algorithm correctly identify an object that is put in front of the camera?

As SoCs become bigger and more complex, the task of prototyping the subsystems and eventually putting everything together has gained in importance. It is important to validate a design in context of its real world interfaces pre-silicon. Otherwise the schedule impact of any issue with the hardware, the software and their interaction is simply too big to stay competitive. Consumers have very little tolerance for device flaws and quickly gravitate to whatever device is first to market and delivers on its promises of new or improved capabilities.

So let¡¯s embrace Lego and prototyping alike. We are never too old to imagine and build new things.