The usual factors in the decision to build vs. buy still apply, but we have to consider an additional set of variables when looking at the various software layers and tools needed for SCA systems. These are some of the trade-offs to look at when you're either building or buying a hardware component for such a system.
Buy Advantages:
- The product probably is or soon will be available off the shelf.
- COTS vendors are competitive so there's always pressure on them to keep their prices low.
- You have the option to buy similar products from an alternate source should there be a problem with the prime vendor.
- Very often a vendor's product line will include multiple versions of a product introduced over a number of years with the latest technology in each version.
- The latest software technology should be available with the minimum effort if the APIs, the BSPs, and the drivers were written with a long-term goal in mind.
Buy Disadvantages:
- The hardware most likely is not an exact match for the system specifications, or in some cases, there may be no real perfect fit with a COTS product. In this case, you may have to reduce or change the system spec to match the hardware available.
- Software could need some work, especially if there's an existing software application that needs to be ported to support the new hardware. This is where quality and complete BSPs and drivers from the vendor can minimize supporting efforts.
Build Advantages:
- The biggest advantage is producing an exact hardware match for the requirements of your system.
- Similarly, if you know the software requirements at the time of hardware design, the hardware has a better chance of matching the software requirements and meeting an existing software spec or API.
Build Disadvantages:
- If you're not a hardware design and manufacturing business with the appropriate engineering resources in place, you can be affected by delays in availability of the hardware.
- You will run into development costs that may or may not be covered throughout the product life.
- The technology may expire, and component obsolescence always is a problem.
- The product can continue to require ongoing engineering for many years.
COTS Hardware for SCA
What requirements does a COTS vendor need to meet in an SCA-compliant software radio board design so that the product is flexible enough to satisfy custom, in-house development requirements?
A/Ds and D/As: Devices
The need here is flexibility of software-configurable clocking, gating, triggering modes, and any other mode of the A/D or D/A. The data paths must be configurable and high bandwidth data paths included to satisfy typical frequency requirements of software radio systems.
Other ASICs: Devices
Digital downconverters and upconverters also would be considered SCA devices. They, too, need to be fully programmable with the capability to be bypassed should the situation arise. As an example, consider a downconverter chip on a board that has a programmable decimation range consistent with most applications.
However, there are a few applications where the decimation isn't low enough. In this case, the downconversion, with the proper decimation, may be performed in an adjacent FPGA using a downconverter IP core.
And while something like the ASIC downconverter can be an extremely useful asset to the overall processing, it's not consistent with the spirit of the SCA spec, which wants flexibility so it can address all applications. Again, having that chip as a bypassable resource is a way to use it when you need it or have it out of the way if it's not needed for the job.
FPGA Resources: LoadableDevices
The next consideration is FPGA resources, which are classified as LoadableDevices. The processing power and flexibility of an FPGA are good fits for software radio systems. However, a key component to fully integrate the FPGAs into an SCA system still is missing. SCA is working to catch up to the technology and best incorporate the features of FPGAs into the specification. The FPGA connection to the rest of the system must be flexible and configurable.
Non-CORBA DSP and GPP Resources
Non-CORBA DSP and GPP resources also are considered LoadableDevices. GPPs can be considered Executable Devices in some applications, but here we are addressing items such as the embedded PowerPCs in a Virtex FPGA. In the case of processors, the executable code must be software downloadable—which should seem obvious.
Any peripherals needed to support the processor must be present. Again in the case of Virtex FPGAs, we'd expect to see the built-in processor core supported by external memory, a boot ROM, interrupt connections for some of the critical hardware, and programming paths that can be accessed so the PowerPC can be loaded, among other things.
About the Author
Rodger H. Hosking is currently responsible for new product definition, marketing and sales activities, and strategic alliances with third party hardware and software vendors. He has published and presented numerous papers for technical conferences and industry publications.
Rodger H. Hosking served as engineering manager and project engineer at Wavetek and Rockland Systems. He was responsible of the design and management of test and measurement instrumentation including direct digital frequency synthesizers, FFT spectrum analyzers and laboratory filters. Mr. Hosking holds a BS degree in Physics from Allegheny College and BSEE and MSEE degrees from Columbia University. He can be reached at [email protected].
