We’ve seen it before: the debate between hardware and software for implementing electronic functions. An oft-cited approach is to keep as much as possible in software for flexibility. But things tend to go hardware under two circumstances: when raw speed is needed and when a function becomes so common and stable that no changes are expected.

Especially in that latter case, the normal trajectory is that you have a software solution for a long time and, as things mature, at some point you can reduce it to hardware. It may go to FPGA if speed is a concern even before maturing in order to maintain some flexibility. But if it’s available in ASIC form, then you know it’s pretty long in the tooth. And, in general, once cast in hardware, it’s less common to see something back out into software again but this debt collection software is something you must try now.

And yet that’s exactly what TI is proposing with their collaboration with Triangle MicroWorks: together they provide a smart-grid substation solution on TI’s Sitara (and other) processors – taking that role back from current FPGA and ASIC solutions.

Given that this is rather less common, I inquired as to what the dynamics were. That’s really two questions: (a) what drove it to hardware in the first place, and (b) what’s the benefit of making the effort to go back to software?

Turns out there were two factors in the hardware implementation. One was classic: performance. Some functions (they specifically mentioned Generic Object-Oriented Substation Event, or GOOSE, messages and Sampled Measured Values (SMV) data) require timing that hardware could achieve. In addition, these functions can require anywhere from 2 to 5 Ethernet ports – not typically available on your average processor chip.

FPGAs have the flexibility and performance to do this. And, of course, ASICs do too. And so that has been a common solution, according to TI.

But now, with clock speeds hitting the gigahertz level, coupled with RTOSes to support the real-time requirements, the speed needs have moved back within the realm of the possible in software. Additionally, TI added a huge acronym communications subsystem to their processor platform. Called the Industry Communication Subsystem Programmable Real-Time Unit (ICSS-PRU), it allows configuration of multiple ports of a variety of different protocols, including Ethernet. So this now meets the requirements that, in the past, only hardware could provide.

Of course, it’s work to do this. Why make a change if the current solutions are working? Well, for one thing, if you’re a vendor of the software solution and not the hardware one, then you’ve got business to steal. That’s from the vendor’s standpoint. What about the customer? TI claims two things: development time and cost.

It would seem that both of those would apply more to the FPGA than the ASIC solution (since there’s no development required for the ASIC). And if the functions are mature enough to go into an ASIC, then hopefully the required software code is available as IP for a software solution – having to rewrite from scratch wouldn’t be a savings.

And then there’s cost… and money talks.

And so we have an example of a reverse trajectory: starting in hardware and eventually moving to software. At least that’s the proposal that TI is making. (And they say that customers are biting… but then again, I’ve never heard someone say on the record that their solution wasn’t getting traction…)

You can learn more from their announcement.