The software is the product - Embedded.com

The software is the product

When considered objectively, it becomes clear that we each hold ourown subjective opinion of what software is, does and is used for. Theconsolidation of hardware platforms at the enterprise level meanssoftware engineers ” or developers with a background in computerscience, to differentiate them from embedded software engineers ” havethe 'luxury' of developing application software with few restrictionsimposed by the underlying hardware. In this domain, the software is theproduct; the application is entirely defined by bits and bytes,configured to execute in a homogenous environment within a vastframework of support within a complex value-chain.

These software engineers will have studied formal methodologies fordeveloping software and will apply that knowledge using tools developedwith them in mind. From this viewpoint, often described as a higherlevel of abstraction, the concept of hardware registers, I/O ports andstack management would rarely feature in discussions betweendevelopers. What is more likely to be a topic of conversation is howquickly a particular version of the product ” the software ” can bereleased to the market. There is little concern over whether thehardware will be available, because the hardware isn't the product; thesoftware is.

For many years the same had not been true in the embedded domain;embedded software had always been hardware specific. The endapplication would dictate a minimum level of functionality, deliveredthrough a hardware platform, meaning the choice of platform was basedlargely on the microprocessor's features. The software developed totake advantage of those features would be secondary, particularly wherehardware acceleration is used in compute-intensive tasks.

With so much differentiation at the hardware layer, embeddedsoftware was developed to provide a control function, rather than theapplication. However with the advent of more powerful yet lessdifferentiated processors, the role of embedded software has changed,and continues to. It is now possible to integrate all the flexibilityand configurability necessary for an end application, in a singleintegrated device. The System-on-Chip now, to some extent and inspecific vertical sectors, represents the same level of homogenousplatform as seen in servers at the enterprise level.

As a result the use of embedded software today is more akin tosoftware at the enterprise level, in terms of how it now defines theoverall system; in a very real way the software is becoming theproduct.

System level software
Along with the SoC, this shift towards more highly integrated hardwarehas recently manifested itself in another way; the multicore processor.This also represents an increased level of abstraction at the hardwarelayer and together they have introduced a new challenge for embeddeddesigners; making best use of the hardware features through software.The problem with multicore ” or parallel ” processing is that softwarein general has no concept of parallelism, it is inherently sequential.

Hardware description languages, such as VHDL and Verilog however,assume concurrent execution; they have little concept of sequentialexecution. Once a hardware element has been described in HDL, it'sconsidered to be in operation.

The use of graphical languages for develop-ment isn't new but itsuse is still largely restricted to hardware description and, insoftware development, to modelling (such as UML). But this may bechanging. Code generation is becoming more accepted at all levels ofcomplexity and with the specific challenges now facing embeddeddevelopers in terms of parallel programming, it may be time to adopt ahigher level of abstraction here, too.

In this respect, the latest version of National Instruments'flagship development environment, LabVIEW, could prove to be ahead ofthe pack in terms of addressing the challenges with programmingparallel architectures. LabVIEW 8.6 (Figure1, below ) was unveiled recently at the company's yearlyconference, NIWeek, where one of the themes was 'parallel programming'.

Figure 1

NI moved in to the 'real-time' domain with version 8.0 of LabVIEW,when it made it possible to put virtual instruments in to embeddeddevices. This concept has the potential to expand massively with theadvent of virtualisation and multicore processors. While C programmersmay be asking 'how do I create multiple threads to run in parallel?'LabVIEW 8.6 now does it for you, with the help of Intel's threadbuilding blocks and low-level compilers.

What does this mean to the embedded engineer? NI has made it clearit feels the potential of graphical programming encompasses more thandata acquisition and now includes the embedded domain in its overallstrategy. With its inherent parallel execution, LabVIEW ” or an as yetunannounced graphical programming language which is equally well placedto take advantage of parallel architectures ” could provide the higherlevel of abstraction the embedded sector needs to fully exploit thepower of parallel architectures.

With the introduction of multicore technology, parallel executionhas never been more relevant in the software domain. With the inherentparallel execution of hardware description languages, it seemsreasonable to expect their use to extend beyond the hardware domain, toassume control over the entire system, proving the software is theproduct and perhaps even that the system is the software.

Philip Ling is an editor with ESEMagazine

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.