editor's blog
Subscribe Now

Moving Back to Software

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.

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.

Leave a Reply

featured blogs
Mar 20, 2019
Over the past few years, 3D modeling capabilites on Samtec.com have progressed immensely. We’ve gone from a small library of static files to a massive library of dynamically generated models, that can be downloaded as virtually any file type, in just a few seconds. Thou...
Mar 20, 2019
One big highlight of the RSA conference is always The Cryptographers' Panel. This year the panel was: Ronald Rivest, the R of RSA. Whitfield Diffie, legendary cryptographer. Paul Kocher, who... [[ Click on the title to access the full blog on the Cadence Community site....
Mar 19, 2019
Deeper Dive into Non-Trivial Bug Escapes and Safety Critical Designs This blog is a continuation of a series of blogs related to the 2018 Wilson Research Group Functional Verification Study (click here).  In my previous blog (click here), I presented verification results fin...
Jan 25, 2019
Let'€™s face it: We'€™re addicted to SRAM. It'€™s big, it'€™s power-hungry, but it'€™s fast. And no matter how much we complain about it, we still use it. Because we don'€™t have anything better in the mainstream yet. We'€™ve looked at attempts to improve conven...