The security world is all abuzz with the news (as reported on C/NET) that Chinese researchers have found flaws in the standard security algorithms used in a number of Internet protocols. The concern expressed in the story is the sheer scale of the problem, given the size of the Internet today and the difficulty in convincing the majority of people to upgrade their software on a regular basis.

As much of a problem as it is for that crowd, it is a much more serious concern for many embedded systems. Any device that depends on IPSEC or SSH could suddenly find itself vulnerable unless a new executable can be distributed to devices already in the field. The necessary conditions for this are a device that is designed with this type of upgradeability and the awareness that upgrades are necessary. I suspect that the first condition is more common today than the second one, given that most embedded developers are users of security protocols rather than security specialists.

The typical pattern of upgrades like these is that not much is done about them until a headline-quality event takes place and raises public awareness. The trick is to be among those reading the headline rather than being the subject of them.

Larry Mittag

One of the real weaknesses of some embedded processors is handling of floating-point calculations. This is particularly problematic in any application that requires trigonometric calculations, which can bog down embedded CPUs like XScale and PowerPC significantly. One choice has been to move to CPUs like Intel’s x86, which include much better floating-point support, but perhaps there is another way to go. A recent article in EE Times described a mathematical approach to trigonometric calculations that avoids many of the trig functions themselves.

Notice that the need for non-integer calculations is not completely removed. The calculations described use ratios of whole numbers which still require fractional calculations. The win is that these ratios should be much more amenable to fixed-point arithmetic rather than full floating point. This could significantly improve the throughput on a number of applications that calculate phase angles, potentially even allowing these calculations to be implemented in hardware rather than software.

These are the kinds of advances that can make significant differences to many embedded systems, even though they are often largely ignored by desktop programmers. I look forward to learning more about it.

Larry Mittag

I never thought much of System-on-Chip (SoC) when it was first being discussed a few years ago. It seemed to me to be just another level of integration for hardware, just another way to make systems hard to debug by hiding the signals deeper in silicon. That opinion is changing, though, as I read articles like a recent one from EE Times on design abstraction for SoC systems.

At one level, this reminds me of the old joke about the MIT grad student who was assigned an application program to write by his professor. After a few weeks the prof asked how it was going. "Great!", came the reply. "I am almost done designing the language to write it in!".

It is certainly true that a lot of time can be spent reinventing the wheel with design options like this, but it also gives us a way to experiment with new ideas for design. As I have mentioned before, I think we need to break out of the current design box and find new ways to design systems rather than hardware or software.

Larry Mittag

If men are from Mars and women are from Venus, then there should also be some arrangement of planetary origins to describe the difference between hardware and software engineers. There are fundamental differences between the way these two groups look at the same system, and that difference can get in the way of creating a system.

I have long imagined a system where a software engineer could examine a representation of a proposed system that was meaningful to him. This representation would be on a tool with a button that could be pressed to represent the same system in a hardware-centric view. Personally I think this is more feasible than a common language between these two groups, but others think differently. That is the crux of an article out of EE Times by someone with yet another "universal" design tool.

The problem with this concept is that the result will always be a compromise. As (mostly) a software guy I want something that shows what I need to see in a manner that is as unambiguous as possible. Resistor values and gate counts are noise as far as I'm concerned.

Larry Mittag

When everyone accepts something to be true it's usually time to take another look at it. This is certainly true when it comes to CPU architecture. Ron Wilson's latest column reexamines the great CISC vs. RISC architecture debate, especially regarding the CPU’s relationship to memory.

We have been in a stagnant period regarding advances in computer architecture for a decade or more now. A lot has gotten done in that period due in part to the relative stability of that architecture, but the cracks are getting too big to ignore. Reexamining the CPU architecture is a good start, but the advent of SoC and FPGA-based macroarchitectures are an excellent opportunity to experiment a bit with more radical departures. The PC is capable of doing a lot of good things, but it is boring. Is there a better way?

Larry Mittag

There have been a number of announcements recently concerning tools to ease FPGA development. Two in particular from Embedded.com caught my eye today.

The first describes a toolset that recompiles C code into an FPGA design. Many companies are struggling to define FPGA code already in terms of whether it is hardware or software, and tools like this are sure to blur that line even further.

The second is a bit more obscure, but no less indicative of the trend. This story describes a set of tools to support a Linix-integrated FPGA-based development system for mobile computing.

The key takeaway from these and similar stories is that FPGAs are not a niche specialty anymore. There have been predictions that hardware designs will someday consist of a very small number of massively-produced FPGA boards that are then programmed to function. I considered those predictions quite fanciful at the time, but now I am not so sure.

Larry Mittag

UML has been accepted by the mainstream software and systems design community as a de facto standard, but it is still meeting a lot of resistance from the embedded community. This is coming to a head as more complex systems are being rolled out with tighter design cycles and more stringent requirements. Case in point, the Toyota Prius has much more complex control software than usual in it’s famed power train, but apparently that software still has a bug or two in it. This is evidenced by the stalling problems that first surfaced on Edmunds.com and was subsequently reported on nationally by CNN at Prius hybrids dogged by software.

The question becomes when problems like this become serious enough to drive embedded developers to formal systems design methodologies. Granted, real-time software has it’s own set of problems that are often not well-addressed by standard design tools, but real-time extensions are available from a number of vendors that address this problem. There have been any number of tool companies that have attempted to survive selling design tools that assist embedded developers, and there is a graveyard of bodies for their efforts. When will this cycle finally end?

A recent Forbes article exposed squabbling among open-source *NIX versions that would look right at home on Jerry Springer. This is not altogether surprising, given the ego gratification and altruistic ideals involved in open-source development, but it does expose a problem with the genre. The loosely-coupled nature of the developers can make it difficult to create products with a strong, consistent design vision and implementation.

This is hardly surprising. It is always hard to coordinate creative people. There are always more than a few ways to implement an idea, with few objective ways to judge the quality of the result. There will be disagreements whenever people are working together, whether it is within the walls of a company or not. I have seen code that simply didn't work come out of both environments.

There are two ways to avoid this situation. The first is to use design tools like UML that can communicate a consistent vision of the system being designed. This type of rigor can be hard to enforce in an open-source environment, but it really does raise the level of communication.

The second solution is the empowerment of the individual. The best software I have seen is generally written by a single programmer. This is not always because the individual is an uber-programmer, but the simple fact is that it is easier to communicate with yourself than with others.

Larry Mittag