Embedded system engineering magazine 2005.11,12

WITH THE GROWING sophistication of FPGAs many consumer electronics companies are using these devices not just to prototype their ASIC

designs, but increasingly, are shipping early production units that contain an FPGA, while the ASIC is in the final stages of production. But with sophistication comes increased design complexity and to handle this complexity designers need sophisticated EDA tools.

The emergence of fast and complex FPGA devices has, like in the ASIC world, created the need for considering physical characteristics of a design during synthesis in order to avoid costly, time-consuming design iterations. Because an FPGA has a rigid fabric, the connectivity grid is fixed once the cell is placed. Therefore a physical synthesis tool must have intimate knowledge of the device fabric including the complex routing structures in order to most efficiently create placement and perform netlist optimizations based upon physical design information.

Two traditional approaches to physical design of FPGAs are Floorplanning and Back Annotation, tweaking P&R results. These have been joined by a new technique of routingaware placement during RTL synthesis, or Graph-Based Physical Synthesis.

Floorplanning

In floorplanning the designer interactively divides the entire circuit it into physical regions on the chip, synthesizes each block separately and stitches together the resulting netlists to form the complete circuit. It improves performance by guiding

placement, but it does not affect the design itself (the synthesis is still not physical) and requires a high level of user expertise. This worked well in ASIC designs, but does not always work for FPGA designs where the rigid connectivity structure of the devices does not always ensure proximity when a block is placed and routed.

As synthesis technology evolved, cooperation between synthesis and place and route (P&R) operations became bi-directional, although still sequential. In-Place-Optimization (IPO) techniques emerged. Logic synthesis produced a netlist that was placed and routed, then results from the P&R were back annotated to the synthesis tool, in an effort to fix timing violations. The tools use the gate level netlist produced by logic synthesis and the delays extracted from P&R. To optimizes the design’s critical path in order to achieve timing convergence they use various algorithms, like logic restructuring and replicating registers with high fanout. The modified netlist is iterated in P&R.

While the IPO approach is used in physical optimizations for FPGAs it can be very time consuming as place and route of a complex FPGA takes hours. Worse yet, convergence is typically an issue. Some vendors advocate manual replacement of critical paths after P&R. However, this becomes a “balloon-in-a-box” problem in that correcting one path almost always makes another associated path worse.

Much more sophisticated tools and detailed analysis are required in order to manually guide placement. This comes under the subject of Design Planning which is in any case best performed at the RTL rather than netlist level.

delays. Instead an FPGA device consists of programmable logic blocks, each connected to programmable connection matrices, which are in turn connected to programmable switching matrices. Generally there are a number of possible ways to instantiate a connection between two programmable logic cells. Placing two cells next to each other does not mean that their connections will have the shortest propagation delay: it depends on the connectivity grid, see Figure 1.

As an example, think of your commute to work. The shortest travel time is not necessarily obtained by taking the path with the shortest distance. By traveling a bit further to get on a motorway, you may actually be able to reduce the overall journey time.

Mapping

In order to optimize the design critical path and achieve timing closure, a physical synthesis tool must know and use the characteristics of the device connectivity matrix properly. Graph-Based Physical Synthesis uses a map (called a graph) of the FPGA fabric including the various routing resources and their delays. The tool follows the process shown in Figure 2. It accepts the RTL netlist of the design and performs simultaneous synthesis, placement and local routing. The result is a fully placed and legal netlist ready for final routing.

In DSM it is the wire delays which dominate performance, not the gate delays. Classical P&R tools first place gates and then connect them with wires. Graph-Based Physical Synthesis reverses the sequence: the tool first routes and then it places. Although this may seem counterintuitive at first, this approach is true interconnect-driven

coupled to the Flash memory by a massively parallel interface to facilitate fast data transfer. The three remaining steps can be invoked by a single command. The I/O states are locked, either at their current value or a fixed value. The SRAM is then updated from the Flash memory in around 1 millisecond and then the on-chip logic resumes operation and the I/O is released.

AFIRST GLANCE, it appears that the trend toward embedding processor cores in field programmable gate arrays (FPGAs) has little impact on

software development. But at the level of software architecture, the adoption of multicore FPGA-based systems has major implications, most notably on the selection of an operating system and a multiprocessing architecture.

Having an RTOS that is well suited for the FPGA environment and development tools that are integrated with the FPGA design flow can provide for painless hardware/software codesign and coverification. Because FPGAembedded processors top out at relatively low clock speeds, it is important to choose a fast kernel and efficient middleware. Even though it is often possible to embed several processor cores in the device, routing latency increases as the FPGA fabric fills up, and upsizing the chip is an expensive solution. Moreover, as we will discuss below, there are many reasons to devote each processor in a multicore design to a specific task, rather than adding processors to make up for inefficient software. Using a fast, efficient RTOS from the outset is a better solution.

Design tool integration

There are also several advantages to choosing an RTOS that is preintegrated with FPGA design tools. The tools shipped by the major FPGA vendors today include facilities for data-driven software configuration. When the floor plan changes, the operating system can be automatically reconfigured to account for factors such as the number and type of peripherals, memory layout, locations of memory mapped device registers, and configu-

ration of timers and interrupt controllers. An RTOS with auto configuration support can be built for the new floor plan with no porting effort. This automation can extend even to the software build environment, so that changes to the hardware are automatically reflected in the compiler options and linker command files.

For systems designers, software development tools that are integrated into the FPGA design flow yield even greater advantages. Software development environments can be integrated with FPGA design tools to form a complete hardware/software development environment. Hardware and software debuggers can be integrated to provide coverification capabilities. For example, you can set up the hardware debugger to halt the system when a particular hardware condition exists, then analyze the states of the hardware and software side by side. Hardware and software tools working together result in deeper system understanding and accelerated development cycles.

Architecture choice

The choice of a multiprocessing architecture is another important step in creating an FPGAbased design. Today’s FPGA development boards often include an external RISC processor and two or more soft core options that can be instantiated as many times as the chip capacity allows. Deciding how to allocate tasks amongst multiple cores and communicate between them is crucial to the overall system design.

Symmetric multiprocessing (SMP) might seem like an easy approach, where multiple identical cores share processing tasks in a manner that is transparent to the application. In practice, however, SMP imposes too much overhead for task allocation and load balancing to meet performance constraints in most FPGA-based systems. It also requires that all the processors in the system be of the same type, when one of the most compelling advantages of using an FPGA is that RISC cores, DSP cores, cryptographic cores and other special purpose cores can be mixed and matched to achieve an optimal design.

A design pattern that is increasingly being used in FPGAs and elsewhere is task-oriented partitioning of a system across processors that are individually suited to the work at hand. In this approach, an

Figure 1: Inter-processor communications.

interprocessor communications (IPC) mechanism is needed to convey control messages and data between cores. In most cases, the amount of data sent between processors is kept to a minimum.

A hardware bus could be instantiated in the FPGA, but a more flexible approach that conserves FPGA fabric is software IPC over shared memory. On-chip memory can be used for control and small data, while large data can reside in system memory. In either case, a zero copy implementation is preferable for both speed and efficient use of memory.

Communicating cores

A final consideration is the means of addressing the various cores that need to communicate. It is possible to dynamically discover and manage processor nodes, so that processors can become available or unavailable during execution. Of course, dynamic configuration adds overhead to the IPC system. The large majority of multicore FPGA-based devices, however, will contain a fixed number of processors operating in a static arrangement. Therefore, a statically configured IPC implementation produces superior results in regards to both speed and determinism.

These recommendations constitute a few particulars in an overall paradigm that is emerging as multicore FPGA-based systems become prominent. Advanced design and development tools, hardware/software codesign and coverification, task-oriented multiprocessing and efficient interprocessor communications all work together to result in shorter development cycles and flexible designs, ultimately culminating in superior devices that get to market faster. <Ends>

www.acceleratedtechnology.com

Design piracy

But is it really necessary to take care to protect IP? There is no doubt that piracy is on the increase, mainly because a design can take months to develop, but be stolen from a poorly protected platform within seconds. Pirates can exploit a number of techniques to do this. The first come under the umbrella term cloning: they produce a replica of the original design, and usually involve intercepting the bit stream used at power-up to boot a volatile FPGA. Alternatively, the pirate may be able to readback programming information from unprotected non-volatile devices, or to copy the boot PROM used to store the FPGA configuration information.

Whilst cloning is the simplest method of design theft, reverse engineering is just as dangerous. Often used by companies to understand their competitors’ products, it also allows the pirate to make changes to the design – perhaps to make improvements, or to reduce the evidence of theft. At its simplest, reverse engineering can be achieved by observing in detail (and

programmed at a trusted site, and locked using the built-in FlashLock feature. This disables both the device’s read and write functions, via a userdefined key between 55 and 263 bits in length. Such “strong” levels of security eliminate a pirate’s chances of reading back the state of a non-volatile FPGA by removing the system power. They also proffer virtual immunity to “brute force” cracking techniques: supplying the device with between 1016 and 1079 possible code combinations via a 20MHz JTAG port would require anything from 57 to 1064 years to guarantee success.

AES encryption provides an alternative approach to this problem, that also eliminates overbuilding. Devices can have a security key programmed within them – again at a trusted site. The subcontractor is then supplied with a similarly encrypted programming file, which can be used only to program the devices for which it was intended.

AES encryption can also be used to provide resistance to reverse engineering. If a system is partitioned so that external signals take the form of tokens or AES-coded bitstreams, it becomes

for use in FPGAs. This fact emphasises the significance of the recent announcement of a soft IP version of the ARM7 architecture for Actel’s ProASIC3 devices; the first soft ARM core for a programmable logic platform.

The Core MP7 ProASIC announcement signifies that FPGAs have attained the levels of security required by ARM, a company with acknowledged high standards in the field. The devices make use of the security benefits of Actel’s Flash-based architecture, which make them inherently resistant to tampering; proprietary FlashLock technology and an AES encryption engine add another layer of resistance.

The announcement of the first soft ARM core signals the “coming of age” of FPGAs in secure SoC applications. By choosing an inherently secure FPGA technology and enabling all of the security features at the design and programming stage as well as in-use, designers can now be certain that their valuable IP is protected against

Any one or a mixture of FIFO configurations can be implemented, each with the following features available:

●Asynchronous input and output ports (these can be clocked at completely different frequencies)

●‘Almost empty’ and ‘almost full’ output flags

●Level indicator flag vectors for both the input and output side of the FIFO

●Data flush inputs for both the input and output side of the FIFO

●For FIFOs utilising one RAM block, programmable aspect ratios of 256x18 or 512x9, independently configurable on the input and output ports

●For FIFOs utilising two RAM blocks, programmable aspect ratios of 256x36, 512x18 or 1024x9, independently configurable.