When designing a product that is meant to be portable, power consumption and size may become of paramount importance. Similarly, designing a product for the medical spamedical device and the resulting list of design headaches can be quite daunting. However, with a few ce adds its own unique set of issues, such as certification, robustness, and product longevity. Combine the two together in a portable simple design strategies kept in mind, it is quite possible to balance these and create an efficient solution.
An efficient solution is not usually the fastest, highest performing, lowest cost, or most flexible solution. Nonetheless, an efficient solution does achieve the best balance among the key care-abouts. As first Indian Prime Minister Jawaharlal Nehru said, "the highest type of efficiency is that which can utilize existing material to the best advantage." So an efficient solution seeks to make the most within the constraints of the system; and portable medical systems have many constraints.
Know what you're building
The first design strategy is to know what you're building. As obvious as this is, it is a step that is often overlooked, yet it is the key to everything. The requirements of the end product must be clearly defined. All aspects must be considered and prioritized: functionality, performance, power, size, cost, availability, upgradeability, placement in the product portfolio, etc. All of this needs to be clearly understood and Pareto ranked before any decisions can be intelligently made about how to design the actual product. This might seem simple, and it could possibly be simple, but this step should be done and documented. When tradeoffs in the design need to be made between conflicting requirements (such as performance vs. power consumption), this document will be the ultimate judge on which should win out. This document may also be the most important tool in reconciling issues between the business owners demanding the product and the engineers building it.
Choosing the right processor
Clearly there are many system components that need to be chosen: sensors to collect the data, the type and size of the display, power management circuitry, the analog front end, etc. To illustrate some design practices, the focus here will be on the selection for the processor(s) of the system. The decision of the processor is often fundamental to the capabilities of the end product and affects many other aspects of the project like software development effort, system memory, and required interconnections. Many of the design strategies used for picking out a processor can be applied to other aspects of the system.
With the processor, just as with the product, it is important to Pareto rank several aspects that factor into the choice of a processor. Among items of interest for portable medical equipment include processing capability (performance), power consumption, total system cost, software development effort, hardware development effort, size, integration, reusability, flexibility, longevity, availability, and development tools. None of these can be considered in isolation, but there are design strategies that will help with each.
Similar to focusing on the processor to illustrate design practices for the rest of the product, the focus for the end equipment will be a portable medical imaging device, such as a handheld ultrasound unit. This requires a great deal of more processing than most portable medical systems, but many of the design strategies remain relevant.
Making sure a processing solution has enough performance is actually the easiest requirement to be met. There is an overwhelming number of possible solutions from CPU, GPU, FPGA, and DSP vendors all with parts capable of meeting a product's processing needs. The vendors tout GHz, GMACs, GFLOPs, and benchmarks. Beware of these numbers; they may give some general indication of the capability of the device, but the best way to get an understanding of the performance for an application is to talk with an engineer from the vendor about the specifics of the algorithms that need to be implemented. Especially when dealing with unfamiliar architectures, there is no substitute for interacting with an engineer familiar with the device. Define the algorithm as functional blocks with known data requirements into and out of each block. Discuss data into and out of the processor and computation complexity of the functional blocks. Understand what implementing the entire processing system will look like on each processor and compare, noting bottlenecks, overtaxed and underused resources. This will give a much better indication of which processor will work best.
In the case where engineers from the vendor are not directly accessible, look for online forums where experienced engineers share their knowledge. Texas Instruments has an E2E Community, which is an example of an online resource containing discussion forums where engineers ask other engineers questions. Sites such as these are very useful tools for learning about the capabilities of a processor.
Once the processor search has been narrowed down based on performance, all the other factors must be weighed and tradeoffs considered.
This is the big tradeoff relative to performance and goes back to the idea of efficiency. Many processing solutions can deliver performance but struggle to do so in a power-efficient manner or have difficulty scaling down the power when lower performance is needed. Performance per Watt is a key measurement here. When looking at a vendor's power numbers, make sure to understand the device temperature these are quoted at, whether they are case or junction temperature, and what the use case of the device is. Vendors quote power numbers differently and understanding the exact use case is important when making comparisons. Also understand the different power management options and how that plays with the usage model of the end product. Many vendors offer techniques like dynamic power switching, multiple power state hibernation modes, reset isolation capability, etc., and the extra power savings offered by these techniques may be valuable for an end product.
Cost, integration, and development effort
When looking at cost, don't just look at the price of the device, but evaluate the overall system cost.
Some vendors offer more than just a processing solution but more of a highly integrated System on Chip (SoC), which embeds one or more processing cores. SoCs can reduce the number of components required in the system, helping to reduce overall cost and hardware complexity. These devices often have large internal memories, integrated high-speed peripherals and dedicated accelerators to offload specific processing functions. Again, when looking at an SoC, keep your application in mind and map the system flow and algorithm onto the SoC to see where there are possible bottlenecks in the architecture. Pay attention to the input and output. In addition to finding out what is on the device, make sure to know what is multiplexed so that everything that needs to be used can be used.
Also consider the scope of the development effort. A good design practice is to spend time evaluating the software and hardware development tools. This includes understanding technical support, training, third-party support, and documentation. Since much development time is often spent in debug and verification, the debugging and/or emulations tools should get a lot of attention. High-quality debugger environments and compilers give designers more visibility into their design and can substantially speed development.
Consider multiple options
There is no "one-size-fits-all" in the processor space. Each has their own strengths and weaknesses that make them the right choice in various situations. Some processors, like DSPs, are best at doing mathematical operations very quickly and power efficiently. Other processors that contain ARM cores are better for task management and running high-level operating systems. FPGAs are great for large interconnectivity and for performing parallel processing. Sometimes a heterogeneous multicore SoC that combines several of these may be the correct solution. Examples include TI's KeyStone SoCs that combine TMS320C66x DSP cores with ARM Cortex-A15 cores, enabling applications that require divergent processing capabilities with a single chip. Solutions like this offer medical imaging system designers a combination of attributes: low power, predictable real-time signal and data processing, a high level of integration, the ability to run a high level operating system, and an integrated development and debug environment.
Still, even these advanced SoCs can never claim to be a one-size-fits-all solution. There will be times when multiple processors may be the most efficient solution. For example, there are portable ultrasound systems today that use an FPGA for interfacing to the AFE and for beamforming, a DSP for image cleanup and ultrasound processing, and a CPU for the operating system and user interface (Figure 1). This may sound sub-optimal, but each individual component does the specific tasks that it is best at, allowing the selection of the other processors to be better utilized and thus smaller versions than they would be if they had more of the processing load. The total power consumption and cost may be lower while at the same time spreading the heat dissipation across three processors instead of creating a single hot spot. Most importantly, if a multiple processor configuration "utilizes existing material to the best advantage," then it is the most efficient solution.