Optimizing embedded designs

System-on-modules speed time to market and aid reliability

BY VIJAY RAO
Advanced Knowledge Associates
Santa Clara, CA
http://www.a-k-a.net

Powerful FPGA fabrics with huge processing power and massive bandwidth capabilities are enabling a new type of flexible, scaleable and cost effective building block the System-on-Module (SoM). What are the real benefits, and is there a trade off against efficiency or performance for these modules? And, are there real cost benefits in relying on a third-party to supply a critical sub-system?

There is an ever-increasing tendency by companies to incorporate third-party solutions into their designs, and there are a number of benefits to this approach:

Reduced time to market. Building complex sub-systems and assemblies can be a relatively long and expensive process, and often the result will not justify the cost. The process of building sub-systems is often not the core competency for firms building system-level products, and resources are diverted away from the final application that needs to be built.

Use of pre-tested and pre-screened building blocks. Third party sub-systems will come fully debugged, tested and screened for reliability. This allows a company to incorporate the sub-system as a component without having to worry about component-level reliability and testing of the sub-system.

Ease of procurement. Incorporating third-party sub-systems can dramatically cut the number of components an OEM has to procure.

Commonality across designs : Modules can be used across many designs.

Scalable designs. Modules are designed to be scalable: as a design increases in performance, it can be upgraded to a more powerful module simply and quickly with no costly redesign.

A typical embedded application design and development flow is as follows:

1. Define requirements

2. Propose solution

3. Hardware/Software partitioning

4. Software development

5. Build hardware

6. Possible ASIC build for a particular algorithm or process

7. Build PCB

8. Port software onto hardware

9. Test, debug, test, debug, ship

Steps 1 to 3 are common whether a module is used or not. The really big benefits of using modules starts to become apparent during software development, which can take place on the same device that will be used in the final application, rather than on a reference design or with models and simulation. All the most common and standard interfaces used for control and basic-communication are already integrated in the module and available for use.

Example SoM configuration

One example of an SOM is the PRISM (Prepackaged Reconfigurable Integrated Systems-on-Modules) from Advanced Knowledge Associates. They come prepackaged with a complete, reliable software-stack that takes care of all common interfaces and protocols. 10/100/1000 Ethernet is available in many SOMs, integrated and ready-to-use from the outset. All the driver code, debug code, diagnostics, and sample applications are already available.

A prime reason to consider pr-tested and prescreened system-on-modules is to reduce time to market.

Development of the final application on final product hardware typically results in great time savings—there is no explicit porting involved and the software running on the module just has to be scaled to accommodate additional peripherals and components that may be part of the final solution.

When it is time to build hardware, FPGA-based modules retain flexibility, and also often come prepackaged with a default combination of soft-cores chosen to match the most popular requirements of that particular industry. Designing with a module also makes board development much simpler, as all the control-path logic (and more) is contained on the module. A lot of the complexity of the board level design can be taken care of by the module, and the functionality of the board can be significantly simplified.

Software porting

Porting software to a module is simple, as primary development is performed using the same module that is to be used for the final application. So, for instance, all the initialization, the boot-up, and most of the driver code will remain the same.

The test and debug process is also greatly simplified using modules because now it is just a case of debugging of the application-board, the logic embedded in the FPGA, and the software. The fully tested and pre-screened SoM will come with logic in the FPGA that has been tested using the module application board and all hardware and software design should already have been addressed by the time the final application/product board arrives.

A modular approach to system build enables real cost savings in many areas. PCB board design time can be cut since the it will be much simpler. Since many modules are shipped with fully integrated and tested industry-standard peripherals, any new soft IP can built on the existing building blocks — also minimizing FPGA design effort.

The PRISM SoMs come prepackaged with an entire software suite—diagnostic software, boot-loader support, operating system, sample application code, and device-drivers and support code for peripherals. The software development effort is significantly reduced because all relevant software elements come preconfigured.

In many complex embedded system development projects it makes more sense to go with a prepackaged third-party solution. The modular approach also works to mitigate the risk of cost overruns, delayed delivery, incompatible protocols and interfaces, limited yield, and limited scalability. ■

For more on embedded systems, visit http://electronicproducts-com-develop.go-vip.net/digital.asp.