Looking at Real Time for Linux, PowerPC, and Cell (developerWorks) [LWN.net]

Looking at Real Time for Linux, PowerPC, and Cell (developerWorks)

Posted Aug 23, 2005 17:15 UTC (Tue) by farnz (guest, #17727) [Link]

If you think cell phone bands are narrow, go working out what you'd need for a universal phone with all network types currently in use (both cellular and simple cordless), WiFi and Bluetooth, bearing in mind that W-CDMA channels can be 2MHz wide, and you can want to communicate on multiple channels. At a rough look, you need to be able to tune to several bands between 400MHz and 5.5GHz, channel hopping in some of the bands, and coping with channel widths from a mere 16kHz all the way up to 2MHz. The complexity of the hardware to do this is high, and the question is whether it's better value (taking into account the market size) to provide a handset with a wideband DAC and ADC, and some serious processing (maybe done on a traditional CPU, maybe with an FPGA), or several small radios, each set for one frequency band.

Now add to this that if (say) digital TV on the move becomes a wanted feature, your hardware approach means a redesign of the hardware, and trashing existing units. My software approach involves reflashing the physical hardware with a new image. Further, when 802.11n comes out, I've got a fighting chance of being able to run that in software too; hardware needs a redesign. Depending on the cost of making a unit, the cost of designing a unit, and the number shipped, the optimal point can be anywhere between a pure software solution (the wideband DAC and ADC with a beefy processor), a pure hardware solution (think crystal radios, for example), or some hybrid. At the moment, processor performance isn't high enough to make pure software viable in any niche; as this changes, we'll see a brief flood of pure software products, then a swing back to mixed devices.

This is analogous to your video acceleration thing; something like a VT100 is a text-mode video accelerator with a keyboard. We went from that to framebuffers (almost pure software), and now we've swung back to a mixed architecture (but note that we accelerate very different things now).

Looking at Real Time for Linux, PowerPC, and Cell (developerWorks)

Posted Aug 23, 2005 19:13 UTC (Tue) by mikec (guest, #30884) [Link]

I meant that each operating band is relatively narrow... given the cost (or lack of cost), the analog solution, you can easily cover that range and more and even do so "on-chip" so that it is part of the processor... That is you have N analog hard macros for handling whatever range you like.. all highly flexible and programmble - all they do is downconvert, so they don't need to very complex...

The argument that you can "future proof" hardware seems to sell a lot of people but if you look at real behavior and product life it is a "sales pitch" not a reality... When it comes down to it, most consumer electronics simply don't survive long enough to be moved from one generation of behavior to the next...

But, all that does not really matter, I am knowingly disagreeing with a good portion of the world in my statement that the balance of hardware vs software does not head in only one direction... It is somewhat sinusoidal as technologies, skills and applications move forward in time... We are WAY over to the software side now and I expect that product margins, support costs, development costs and ultimately power consumption are going to be the drivers of this balance back toward the middle...

Intel finally ending its seemingly endless pursuit of clock rate at the expense of everything else is a great indication (at least to me) of this trend. As is the proliferation of "applicances" (such as tivo, linksys etc..) which when you open them up are low clock-rate embeded processors coupled with hardware acceleration for the compute-intensive operations (mpX codec, IPsec, HDTV etc...)

These tasks were previously accomplished in sofware - once they stabilized, then the hardware showed up to do it faster, cheaper, cooler...

The same can be said for RF processing... Although it often seems to go through 3 phases:
1. RF too fast for baseband -> CPU + external
2. RF possible at baseband -> CPU only
3. RF standardized -> CPU + RF ASIC (which may be embedded in the CPU)

There is another interesting aspect of this which is that the more is accomplished in hardware, the less undue control software vendors have over your use of it... It is amazing the clarity a little plasitc or ceramic packaging can bring to the consumer/producer relationship...

Looking at Real Time for Linux, PowerPC, and Cell (developerWorks)

Posted Aug 25, 2005 3:39 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]

a software radio has the huge advantage that it can receive multiple signals at the same time.

with hardware you have to have a physicly seperate receiver for each signal you want to receive.

there are a lot of situations where you have a lot of radios in one place to try and monitor lots of signals (and a scanner doesn't do the job, it hops between channels with one receiver, it still only listens to one signal at a time)

in addition, software radios can handle new types of signal encoding with just software changes, including spread spectrum sideband, etc that would require hardware redesigns for traditional equipment.

and finally, there are some things that just can't be done reasonably in hardware that software makes possible. The advances in telecom speeds are mostly due to the audio-speed circuits being changed from being implemented in hardware to being software, the software has made it possible to adapt the signal to the lines (and detect the inteded signal from the lines) to a degree that was considered physicly impossible not too long ago, and these changes have made much of the broadband service that people use possible. we really don't know what will end up happening as this scales up to higher frequencies, but past experiance makes it clear that it will be things that we can't imagine today.

and before you say that hardware radios give you more flexibility, consider that you can't purchase a scanner in the US to receive some frequencies becouse the hardware to do so has been outlawed (cellular freqs for example). even excluding these limits, you are in just as much need to hack the hardware as you would be the software of a software controlled radio if the manufacturer decides to put limits in there.

besides the origional article just listed that as one of the things that could be done if performance was to improve that much, not that that was the only reason to improve performance to that level.