Embedded system engineering magazine 2005.11,12

PROCESS TECHNOLOGY and geometry improvements continue to drive semiconductor integration. The vast of transistors and logic gates that

can be integrated on a single chip are forcing the industry to look towards design re-use. This has been true for some time in the ASIC market where engineers could choose from a manufacturer’s catalogue of functions when designing their system. Due to their inherent flexibility and with logic densities in the millions of gates, FPGA architectures are such that they are displacing the traditional ASIC market in all but the very highest volume applications.

FPGA devices from different vendors have very different architectural features and design engineers wishing to optimise their designs for specific applications can take advantage of these architectural differences during the design phase. With the added complexity of FPGA devices FPGA manufacturers are increasingly requested by customers to provide a total system solution. There is a demand not only for the devices, but also for the intellectual property that needs to be embedded within the device in order to make a functional design.

IP portfolio

Product offerings from FPGA vendors now also include a comprehensive portfolio of pre-verified IP cores, which can be downloaded from the relevant company websites and tested for their suitability before being purchased. These IP cores provide pre-tested, reusable functions that can be easily plugged in, freeing the designer to focus on their unique system architecture, eliminating the need to "re-invent the wheel," by pro-

viding many industry-standard functions, ranging from PCI to DDR to Ethernet and more.

Complementing the IP cores are frequently free reference designs that support a number of differing functions. These reference designs come with either source code or a net list and are industry-standard functions that have been optimised to work on a manufacturers architecture.

It is not possible for any company to develop every core that a customer may require. Specialised knowledge may be needed where specifications are complex or have not yet been finalised. A key element in satisfying the customer requirements in these specific areas is to form third party relationships with other companies that specialise in a particular market segments. Lattice, for example, has entered into partnership programs with a limited number of third party suppliers of IP and supports these companies with advanced copies of its latest software tools and early device samples. This allows them to bring to market in a timely fashion the more application-specific third party IP.

PCI Express

An example of this is a PCI Express solution recently introduced for the Lattice ECP and Lattice EC FPGA devices. PCI Express has become a standard feature in desktops and server computers today. This low cost solution incorporates a physical layer device driver from Genesys Logic - the GL711 PCI Express PHY, and the Northwest Logic PCI Express IP core. These cores, in conjunction with the FPGA, provide a fully compliant PCI Express solution that can be easily and quickly adapted by customers to their own unique needs. The solution will enable designers to upgrade their device connectivity to

speeds in a cost effective way. Combining the expertise of three companies to provide a total solution for a design engineer is a key enabler that allows a faster time to market with a proven system, rather than an engineer separately developing all the constituent parts.

A key element in any IP strategy is the development tools. ispLEVER is a complete CPLD and FPGA design software tool, helping engineers take their design from concept to finished product. ispLEVER includes a complete set of powerful tools for all design tasks, including project management, IP integration, device mapping, place and route, in-system logic analysis and more.

Integration

For the integration of IP functions within the design flow Lattice provides IPexpress, an interface to a catalogue of functional modules, reference designs, and intellectual property (IP). It helps accelerate the design process by allowing design engineers to smoothly configure and integrate these functions into a custom design. The IP cores include some of the most popular industry-standard functions such as PCI bus controllers, DDR memory controllers, Ethernet MACs, DSP functions and many more.

Mentor Graphics and Synplicity are two leading software tools companies that have OEM partnerships with Lattice Semiconductor. These partnerships enable Lattice to ‘bundle’ together advanced tools for synthesis and simulation, allowing the design engineer to utilise state of the art software during product definition - a key element in producing an efficient design on time and meeting overall specification. <Ends>

www.latticesemiconductor.com

development tools. These system connectivity tools allow the customisation and choice of processor and peripherals to be done in an intuitive, graphical environment that also updates the software design environment to reflect the automatically generated hardware.

Soft processors are often, by nature highly configurable to address multiple applications with a single intellectual property (IP) core. For example, the Nios II soft processor can be configured in 3 different processor architecture choices giving the developer the ability to optimise for performance (a fast variant that can achieve over 200DMIPs in high-performance FPGAs), for lowcost (an economy variant that can use less than 50 cents worth of logic in low-cost FPGAs) or to simply choose the option that offers a mixture of both (standard variant). Developers can also add peripherals from a library of cores using tools such as SOPC Builder until they have built a processor system that exactly meets their needs.

While modern FPGAs allow soft processors to achieve clock speeds well over 150MHz, maximum performance doesn’t stop with the speed of the processor itself. Problem areas of software algorithms can be analysed and off-loaded to

sumes. This is termed the “function cost” and can frequently be a small percentage of the device cost in modern, high-density FPGAs. The area consumed by the processor is part of the decision criteria and care needs to be taken in the design to minimize resources. For this reason it makes sense to specify a soft-processor that has been designed and optimised for FPGA architectures. Ignoring this fact can often lead to a high function cost and poor performance. This makes the solution unattractive despite the flexibility we previously described.

Soft processors in FPGAs give flexibility across all phases of the project life-cycle. Often when projects start, the processor choice is complicated by the simple fact that the software isn’t written at that stage. Whilst good estimates can be achieved they can often lead to situations of excess capacity, which can result in an expensive solution or under capacity which means the design cannot be implemented.

Under capacity is clearly a much more serious problem in the life-cycle of a product since it can force a re-selection of the processor and subsequent board layout or many weeks or months

effort spent trying to optimise code. Soft proces-

www.altera.com

sors built on FPGAs are designed to be flexible

MOORE’S LAW is struggling to keep pace with the insatiable need for mul timedia gadgets requiring higher formance and algorithm complexity

While traditional DSPs are still widely used, FPGAs have evolved to become reconfigurable signal processors that warrant serious consider ation for many of today’s signal processing design challenges.

Performance

DSP system designers frequently measure performance as sample rates, that is the number of digitised samples (e.g. from an A/D converter) that can be processed in a given amount of time.

Figure 1 shows the difference between FPGAs and DSPs using a 256-tap FIR filter. DSPs typically house 1-4 Multiply Accumulate engines (MACs) for processing data samples. A DSP using one MAC that is being clocked at 1GHz would “theoretically” process up to 4 mega samples per second: in practice it is much lower as other functions, such as data transfers from the memory, consume clock cycles.

One of the fundamental differences between FPGAs and DSPs is that FPGAs feature hundreds of MACs and multipliers that can be used to build parallel DSP structures with performance an order of magnitude higher than DSPs.

Design flexibility

Design flexibility is the ability to make changes during the design phase and during production to mitigate risk and cater for specification alterations. Traditional DSPs provide a fixed hardware architecture that can be programmed in multiple ways: vendors try to ensure that the mix of hardware features (e.g. I/Os, peripherals) meets the majority of customer needs, However

Figure 2: DSP / FPGA trade-off.

Design effort is both the ease with which the device capabilities are accessed and importantly, how fast it reaches the market. If the required performance is within the constraints of a DSP device then DSPs provide the fastest route and the availability of algorithms from vendors makes designing the system relatively painless. Since DSPs use C or similar high-level languages, there is also a plethora of qualified engineers.

Programming becomes considerably harder when systems require multiple DSPs. Sequential architectures are not ideal for performing tasks that need concurrency and here using FPGAs can be a more suitable solution, particularly as programming methodologies have evolved to include design entry from environments such as MATLAB and Simulink, more familiar to non-tra- ditional FPGA designers and replacing hardware description languages such as VHDL and Verilog.

Power consumption

Power consumption means different things to different designers. Cellular communication handset manufacturers are focused on delivering multimedia services such as internet access and SMS and are concerned with prolonging battery life. With static power alone as much as a watt, FPGAs are not suited and DSPs, with static power in µW and dynamic in mW, offer

AFPGA PRICES continue to fall, broad availability of IP such as low-cost processors, DSP cores, and peripherals will be instrumental in allowing

these devices to become system platforms for a widening range of applications. Implementing an entire embedded system within a programmable device is an attractive proposition for many reasons, but integrating the required hard and soft design elements remains a formidable challenge.

Technical barriers

The technical barriers to implementing IP in FPGAs are considerable. This is because ‘soft’ components are rarely delivered to designers in ‘ready-to-use’ condition for their specific application. The HDL-coded description of the core must be integrated with other elements of the design and verified as part of a complex system. Although up to 40% of hardware designers are

the complex licensing issues encountered when obtaining IP or delivering it to customers. Because IP has traditionally been delivered to the designer as source code, the security of that source is of paramount importance to its owner. This requires a complex legal framework to protect the IP and to provide licensing schemas for its distribution to end-customers. So significant is this barrier to implementing system-level designs, that it has spawned a lively open-source movement for hardware IP. However, the potential misfit between the objectives of ‘free’ IP cores advocates and the needs of developers of commercial applications for that IP creates its own set of issues.

FPGA vendors have recognized the importance of IP and have responded by providing their own sources and licensing. However, these cores are targeted only for the vendor’s own platforms and have a proprietary architec-

ready for fitting into an FPGA without further modification by the designer. By linking these pre-synthesized components to schematic symbols, the designer can work graphically in Altium Designer with blocks of IP code without having to be exposed to the complexities of the underlying HDL.

These pre-synthesized/pre-verified components are treated as black boxes during system synthesis, which provides the additional benefit of speeding the re-processing of the design each time it is downloaded into the FPGA. This gives the designer the freedom to iterate the design at will without the overhead of tedious synthesis and verification cycles that extend down below the component level.

Starting point

Of course, the key to the ultimate value of this approach will be the number of potential design applications this new methodology supports.

<Written by> Chris Hills </W>

MY VIEW was that ESS was bigger and busier than last year. Others confirm that the larger conference, PhD thesis conferences and workshops were well attended. So all is right with the world? No it is not!

There is a major problem with UK

Electronics that will affect all of us

lous that a good company cannot find engineers.

The problem, especially with multinational companies, is that the work moves to where the expertise is. It is one thing work being outsourced abroad because it is “cheaper” or run of the mill (see previous columns on that can of worms) but very different to outsource work abroad because they can’t find experienced embedded expertise in the UK.

Only IT programmers

Last week I had an email from a client who was looking for embedded engineers and could only find IT programmers, computer science graduates and Windows programmers. I mentioned this to a tools company and they commented that of late they had also been getting many requests from customers for any “half-decent” embedded engineers, contract or permanent, who could use the tools that they were selling.

At ESS I was approached by an IT recruitment “consultant’… he was looking to see who needed any “IT programmers”. After all it was an “IT/software” show he told me! He didn’t understand the difference between IT and embedded. (He does now!)

Part of the problem, as any contractor will tell you, is the Inland Revenue: just mention Section 660 and IR 35 to a contractor! Over the past five years those two Revenue clauses have caused a large number of contractors to retire or go abroad.

Train new engineers

So we don’t have enough embedded engineers. The solution is obvious. Train more! I was talking to a University and far from producing more engineers they were making electronics staff redundant. It appears that whilst computer games, mobile phone/pda java apps and some film and media areas are popular, embedded (unless it is WinCE or Linux on a 32 bit system) was not getting much interest.

The other problem is that a large minority of electronics graduates will not do anything connected to the military. On top of that, according to a poll of UK graduates in October 2005 35% would reject “non-green” employers.

So we have fewer experienced engineers and a shortage of new graduates. To really make matters worse the new levels of tuition fees for university are now about 3 times higher.

This year there has been a 20% decrease in the number of university applications from the UK. I understand technical and science subjects have suffered more than most. One university I know has about 90% foreign students on its electronics MSC courses. This is alarming as the IEE now requires an MSc for C.Eng. Now I am all for raising the standard but UK-Embedded-PLC has appeared to shoot itself in the foot, if not the head.

I used to think that as the shortage bit a contractor’s hourly rate would go up. It will but only to a point. This is a global market: if there is no talent in the UK then companies will move the R&D to where the workforce is situated.

As this is the end of year issue I should wish you all a Happy Holiday. Do visit the earlier column, Two Weeks In The Summer on why you should take a break from work and follow its advice. I hope next year holds a brighter future for us all.

The small print

These are my own personal views. The full version of this column resides under the Technical Papers button at www.phaedsys.org, where there are links to FREE Solaris and compilers and a pdf with C-C++ differences. Any comments,