Soc Design -> End-user needs drive product design

Rather than view the product from the inside out, it is better to develop an application model of the product and drive that forward into the design phase. Prototyping the application model and verifying the user's ability to interact with it has been the subject of usability studies for more than 30 years. While these techniques are used in the engineering world, the difficulties of hardware/software co-design have often pushed the end user's experience to a much lower priority in recent years. Just getting the product out on time is enough of a challenge for many design teams, let alone worrying about the finer details of the overall appliance.

The end user's experience with any electronic product begins with the user interface. If the interface is strange and violates the rule of "least surprise," the experience will always lead to one of two outcomes: Either the user will not purchase your product and opt for your competitor's ("Well, it was really weird so I bought the MacAcme 11003-XLS instead.") or he will purchase it, suffer with it, and never buy anything from your company again.

The end user does not care that by pushing a button, the electronics are being reconfigured deep in the machine. The only thought here is that the button does what it says it will do and that it does it without any surprises.

However, the hardware/software co-design team does care a great deal about what happens when the user presses that button, but they must never allow the internal operation of the machine to leak back through to the user in strange or unexpected ways.

Developing the a pplication model in software first allows the design team to refine the product's behavior. The caveat to this approach is that given the limited amount of time, just to get the design done means that this model eats into the overall design time.

Detailed models
What is needed is a method of getting from the application model directly to the detailed hardware/software model--that is, reusing the application model in the design process. In this way, developing the application model contributes to, rather than subtracts from, the completion of the project on time. The application model becomes the executable specification.

One of the insights that this approach provides is that the target hardware also needs to be as easily reconfigured as the application model if the time saved isn't going to be eaten up in a lengthy chip design and fabrication.

The ideal tools for this approach must provide a way of encapsulating the implementation in the executable specification. By spendi ng the time up front on proving the success of the application, the design team is more likely to get it right.

Once the application model is operating as expected, the next step is to develop the partitioning between the hardware and software portions of the implementation.

Implementing a complex algorithm in hardware for performance reasons also implies that parts of the design may move from a serial to parallel architecture. On the other hand, some types of software such as real-time operating systems (RTOSes) are far too complex to be implemented in hardware and require a general-purpose processor. In either case, the end user still doesn't want to know the details.

One of the insights that this approach provides is that the target hardware also needs to be as easily reconfigured as the application model. Fortunately, a class of powerful reconfigurable semiconductor devices already exists. These devices are field-programmable gate arrays (FPGAs), the capacity of which is pushing t oward tens of millions of system gates.

Combining easily reconfigurable FPGA devices with new techniques that allow them to be configured from software specifications solves partitioning and optimization problems (software is also reconfigurable). When the application model changes, the configuration of the chip can change, eliminating weeks or months of development time and the huge amounts of cash required to create a custom chip.