editor's blog
Subscribe Now

Keep it in Software

In the domain of deciding which embedded functionality should go in hardware and which in software, some architects have a philosophy of keeping as much in software as possible. That’s because software is inherently much more flexible than hardware. Even if you’re using an FPGA, there’s always the, “what if it doesn’t route?” fear. With software, as long as it fits in the allocated code store, you can do anything you want.

This is, of course, part of the motivation of software-define radio (SDR). Years ago, I would hear SDR articulated as a godsend to the military so that they could manage their complex communications more readily.

Now it’s starting to look viable for cell phones. Icera, acquired by Nvidia, is there, and CEVA has just made a couple of SDR-related announcements.

The first relates to GPS: rather than adding hardware to implement GPS, CEVA partner CellGuide proposes to implement a software version, which requires no new hardware. The GPS function would run as a lower-priority function in the background, ceding to calls and browsing and other higher-priority tasks.

Then CEVA announced library support for HSPA+ (“Evolved High Speed Packet Access”… these acronyms never seem to contemplate the fact that there will be more after them… “evolved” and “long-term” and the like will seem so quaint ten years from now…). The idea is to further enable a software implementation of a multimode HSPA/HSPA+/LTE/LTE-A platform. (See? How long-term was it before they had to append a “-A”?)

A big motivation for doing all of this in software is that, traditionally, each call mode can require its own hardware, so you end up with more chips and higher power and higher cost. If instead you just have a processing platform (which, clearly, CEVA would like to include their DSP engine, for which their libraries are obviously optimized), then you just pull up and execute the code for whichever protocol is being used at the moment.

More detail is available on their GPS release and their HSPA release

Leave a Reply

featured blogs
Jan 20, 2020
As you probably know, discrete wire component data is quite a bit different than just standard socket and terminal mating relationships. When we look at how Samtec approaches discrete wire products, there are several components involved. We not only sell the assemblies, but w...
Jan 20, 2020
My latest video blog is now available. This time I am looking at operating systems for embedded applications and how you go about selecting one. You can see the video here or here: Future video blogs will continue to look at topics of interest to embedded software developers....
Jan 17, 2020
I once met Steve Wozniak, or he once met me (it's hard to remember the nitty-gritty details)....
Jan 17, 2020
[From the last episode: We saw how virtual memory helps resolve the differences between where a compiler thinks things will go in memory and the real memories in a real system.] We'€™ve talked a lot about memory '€“ different kinds of memory, cache memory, heap memory, vi...

Featured Video

RedFit IDC SKEDD Connector

Sponsored by Wurth Electronics and Mouser Electronics

Why attach a header connector to your PCB when you really don’t need one? If you’re plugging a ribbon cable into your board, particularly for a limited-use function such as provisioning, diagnostics, or testing, it can be costly and clunky to add a header connector to your BOM, and introduce yet another component to pick and place. Wouldn’t it be great if you could plug directly into your board with no connector required on the PCB side? In this episode of Chalk Talk, Amelia Dalton chats with Ben Arden from Wurth Electronics about Redfit, a slick new connector solution that plugs directly into standard via holes on your PCB.

Click here for more information about Wurth Electronics REDFIT IDC SKEDD Connector