Third Quarter 2004 Newsletter for Altera...

®NV-2004-Q3

Third Quarter 2004

Newsletter for Altera Customers

| 2

Executive Letter

Two years ago in this publication, we wrote that FPGAs were breaking into the mainstream of digital signal processing (DSP) applications. Even earlier, we at Altera clearly saw this trend and included embedded DSP blocks in our first-generation Stratix® FPGAs. Fast forward to 2004, and FPGAs dominate the DSP scene. Case in point: at this year’s GSPx event, more papers were submitted featuring FPGAs than DSP processors. Furthermore, according to the market analyst firm Forward Concepts, the market for FPGAs in DSP applications is growing by a compound annual growth rate of approximately 26 percent, and will reach more than $400 million next year. FPGAs have gone from the mainstream to the jet stream!

As a result of the world turning digital, there’s a rapid shift in the implementation of DSP appli-cations toward today’s advanced FPGAs. The need to react quickly to evolving standards, while competing on features and price has made FPGA co-processing the preferred approach for implementing DSP algorithms. Standalone DSP devices use software-based sequential processing to implement computationally intensive DSP algorithms. This approach has not kept pace with the per-formance demands of today’s advanced communications and imaging systems. Most alternatives to bridge this performance gap come with a price to pay. DSP farms (multiple DSP devices operating in parallel) take up valuable board real estate and burn excessive power, while ASICs and ASSPs take too much time and money to develop and lack the flexibility to adapt to changing standards and system requirements. Meanwhile, FPGA co-processors offer the parallel processing required to meet advanced system performance requirements, while retaining flexibility. Rather than an array of digital signal processors, for example, our customers are increasingly using a single digital signal processor with an FPGA co-processor to implement their most demanding signal-processing applications.

We’ve had first-hand accounts of this sea change in DSP design at our second Code:DSP seminar series, held in June. This year’s seminar focused on FPGA co-processing for video and image process-ing solutions. Since imaging design issues can no longer be effectively solved with traditional digital signal processors, many designers are moving to a Stratix- or CycloneTM FPGA-based solution to increase performance while reducing cost, power, and size. Continuing the momentum started by our first-generation Stratix devices, Altera’s customers now have an even greater performance advantage with Stratix II devices for high-end DSP co-processing applications. In addition, our new low-cost Cyclone II FPGA family, with embedded 18 × 18 multipliers, is ideal for price-sensitive, high-volume applications. Altera’s DSP Builder removes the barrier to entry for traditional DSP designers, giving them a design flow that quickly resolves integration issues and helps speed time-to-market.

Want to learn more? The Code:DSP seminar comes directly to your desktop via our Code:DSP net seminar series at www.altera.com/dspseminars. We also hope you’ll enjoy this issue and join the stream of designers taking full advantage of FPGAs for their inherently flexible glory. You’ll read contributed articles from our DSP customers and partners who, like us, believe that the future lies in programmable logic.

We hope you’ve enjoyed your summer.

Craig LytleVice President, Intellectual Property Business Unit

FPGAs for DSP: From Mainstream to theJet Stream

| 2

Executive Letter

��

��

��

��

��

��

��

��

��

��

��

��

��

��

Contents

4 | Altera Corporation News & Views Third Quarter 2004 Third Quarter 2004 News & Views Altera Corporation | 5

Features

SOPC World 2004

Altera, ACAP, ACCESS Program, ACEX, ACEX 1K, AMPP, APEX, APEX 20K, APEX 20KC, APEX 20KE, APEX II, Atlantic, Avalon, BitBlaster, ByteBlaster, ByteBlaster II, ByteBlasterMV, Classic, ClockBoost, ClockLock, ClockShift, CoreSyn, Cyclone, Cyclone II, DirectDrive, E+MAX, Excalibur, FastLUT, FastTrack, FineLine BGA, FLEX, FLEX 10K, FLEX10KE, FLEX 10KA, FLEX 8000, FLEX 6000, FLEX 6000A, Flexible-LVDS, HardCopy, HardCopy Stratix, IP MegaStore, Jam, LogicLock, MasterBlaster, MAX, MAX II, MAX 9000, MAX 9000A, MAX 7000, MAX 7000E, MAX 7000S, MAX 7000A, MAX 7000AE, MAX 7000B, MAX 3000, MAX 3000A, MAX+PLUS, MAX+PLUS II, MegaCore, MegaLAB, MegaWizard, Mercury, MultiCore, MultiTrack, MultiVolt, NativeLink, Nios, Nios II, nSTEP, OpenCore, OpenCore Plus, OptiFLEX, PowerFit, PowerGauge, Quartus, Quartus II, RapidLAB, SignalCore, SignalProbe, SignalTap, SignalTap Plus, SignalTap II, SoftMode, Stratix, Stratix II, Stratix GX, Terminator, The Programmable Solutions Company, TriMatrix, True-LVDS, USB Blaster, and specific device designations are trademarks and/or service marks of Altera Corporation in the United States and other countries. Altera acknowledges the trademarks of other organizations for their respective products or services mentioned in this document, specifically: ARM and Multi-ICE are registered trademarks and ARM922T and ETM9 are trademarks of ARM limited. HyperTransport is a trademark of HyperTransport Consortium. Mentor Graphics is a registered trademark and Exemplar, LeonardoSpectrum, and ModelSim are trademarks of Mentor Graphics Corporation. RapidIO is a trademark of RapidIO Trade Association. Rochester Electronics is a registered trademark of Rochester Electronics, Inc. All other third party marks and brands are the property of their respective holders. Altera products are protected under numerous U.S. and foreign patents and pending applications, maskwork rights, and copyrights. Altera warrants performance of its semiconductor products to current specifications in accordance with Altera’s standard warranty, but reserves the right to make changes to any products and services at any time without notice. Altera assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly agreed to in writing by Altera Corporation. Altera customers are advised to obtain the latest version of device specifications before relying on any published information and before placing orders for products or services. The actual availability of Altera’s products and features could differ from those projected in this publication and are provided solely as an estimate to the reader. Copyright© 2004 Altera Corporation. All rights reserved.

Tcl Scripting

Managing EditorGuy Spencer

Production Editor John Panattoni

Technical Editor Justin Bennett

Design & LayoutChandra Spence

101 Innovation Drive San Jose, CA 95134Tel: (408) [email protected]

DSP Builder 2.2

5

7

37

FPGAs for DSP: From Mainstream to the Jet Stream ............................................................ 2

SOPC World 2004: Take the Right Path .................................................................................. 5

Code:DSP Seminar on Video & Image Processing Draws More than 400 Attendees .......... 6

DSP Builder 2.2 Accelerates Stratix II & Cyclone II FPGA-Based DSP Designs .................. 7

Using Simulink & Altera’s DSP Builder in Model-Based Design for Video & Image Processing Systems................................................................................................................ 8

Leveraging FPGA Co-Processors to Optimize High-Performance Digital Video Surveillance Systems.................................................................................... 11

An FPGA-Based Algorithm Accelerator for Software Designers ......................................... 14

Enabling Real-Time JPEG2000 with FPGA Architectures ................................................... 18

Digital Signal Processors & FPGA Co-Processor Development (H.264 Encoder Example).................................................................................................. 23

Custom Algorithm to SOPC Builder System Component ................................................... 26

Cyclone Devices Enabling Effective Power Metering ........................................................... 28

Electronic System Level Design by Any Other Name... ........................................................ 30

Physical Synthesis Optimizes Complex FPGA Designs........................................................ 33

Stratix GX Devices: The Total Solution for PCI Express...................................................... 35

Quartus II Offers Unmatched Flexibility with Advanced Scripting Technology................ 37

Altera Introduces Find Answers: Putting Collective Knowledge to Work for Web Customer Service ....................................................................................... 39

Subscribe to Altera’s Free e-Newsletters & Enter to Win an iPod Mini .............................. 40

Upcoming Events .................................................................................................................... 41

Altera Product Matrices.......................................................................................................... 43

Altera Product Packaging Dimensions .................................................................................. 49

Contents

4 | Altera Corporation News & Views Third Quarter 2004 Third Quarter 2004 News & Views Altera Corporation | 5

Features

SOPC World 2004: Take the Right Path

System architects, hardware and software engineers, and board designers must choose among logic alternatives to meet challenging performance, cost, and time-to-market requirements. Altera created SOPC World to make it easy and convenient for customers to gain a deeper understanding of how Altera® programmable logic solutions address cur-rent and future system-level design issues. This deeper understanding of Altera solutions will help designers navigate the maze of design alternatives and take the right path to design success.

SOPC World 2004

SOPC World 2004 will present a series of detailed technical sessions that discuss:

n Key design challenges faced by engineers today

n Altera and partner solutions that can address these challenges

n Examples of real Altera-based systems meeting these challenges

For SOPC dates and locations, see Table 1. For the standard North American agenda, see Table 2.

Altera and its partners will also have live demonstra-tions of the topics covered in the sessions as well as demonstrations of a wide range of other applications and development systems.

Topics to be covered in the technical sessions include successfully implementing high-speed system design, benefits and solutions of multi-processor design, leveraging FPGAs for digital signal processing (DSP) applications, and increasing system performance and efficiency using direct memory access (DMA). Additionally, designers will be informed of major indus-try trends and Altera’s roadmap to design success.

Whether focused on performance, cost, or time-to-market, SOPC World 2004 can show attendees how to use Altera solutions to stay ahead of the competition and take the right path to market success.

To register for an SOPC World event, visit the Altera web site at www.altera.com/sopcworld.

Table 1. SOPC World 2004 Dates & Locations

North America APAC Europe Japan

Date Location Date Location Date Location Date Location

Oct. 27 2004 San Jose Oct. 14 2004 Hsinchu, Taiwan Nov. 4 2004 Milan, Italy Oct. 29 2004 Tokyo

Nov. 4 2004 Boston Oct. 18 2004 Shanghai, China Nov. 5 2004 Osaka

Oct. 21 2004 Shenzen, China

Oct. 25 2004 Beijing, China

Oct. 27 2004 Seoul, Korea

Nov. 3 2004 Bangalore, India

Table 2. SOPC World Standard North American Agenda

Overview Event

8:30 - 9:00 a.m. Registration/Breakfast/Exibits Open

9:00 - 9:10 a.m. Opening

9:10 - 9:30 a.m. Keynote

9:30 - 10:00 a.m. Product Overview

10:00 - 10:15 a.m. Break/Exibits Open

Technical Sessions Track A Track B

10:15 - 11:25 a.m. Ensuring Success in High-Speed System Designs n Accelerating System-Level Integrationn Multi-Processor Systems in FPGAs, Implementation, and Debug

11:25 a.m. - 12:10 p.m. Lunch/Exibits Open

12:10 - 1:20 p.m. MegaMACs to TeraMACs: Implementing Digital Signal Processing in FPGAs

Increase System Performance and Efficiency Using Distributed Direct Memory Access (DMA)

1:20 - 2:00 p.m. Altera Roadmap

6 | Altera Corporation News & Views Third Quarter 2004

Features

Third Quarter 2004 News & Views Altera Corporation | 7

Features

Code:DSP Seminar on Video & Image Processing Draws More than 400 Attendees

Altera held its second annual Code:DSP Seminar series this June, in Toronto, Boston, and San Jose. This year’s seminar focused on video and image pro-cessing and featured a keynote address by Craig Lytle, vice president of Altera’s IP Business Unit, as well as presentations and product demonstrations from Altera and its partners (see Figure 1).

Lytle’s keynote discussed the current challenges fac-ing digital signal processing (DSP) designers and the benefits FPGA co-processors bring to DSP applica-tions, including higher system performance, acceler-ated time to market, and lowered cost per embedded multiplier. It then highlighted Altera’s latest FPGA offerings—the Stratix® II and CycloneTM II device families. Finally, it detailed some of Altera’s recent customer successes in the video and image processing marketplace including a Panasonic professional video camera, the Navman fishfinder, an Intevac night vision security camera, a Hirschman auto digital TV receiver, and Texas Instruments’ DLP TV and DLP cinema products.

In addition to the keynote, the seminar featured two presentations by Altera, one by Altera and The MathWorks, and one each by Altera partners MangoDSP, Barco-Silex, Ateme, and SBS. The first Altera presentation expanded on the keynote theme of enhancing video and image processing performance using programmable logic. It focused on issues such as implementing video interfaces in FPGAs and system design. The second Altera pre-sentation demonstrated the advantages of using the Nios® II embedded soft processor and the SOPC Builder development tool to implement video and image processing systems.

The joint presentation by Altera and The MathWorks covered the benefits of using Simulink and DSP Builder for video and image processing system design. It discussed the advantages of using model-based design to analyze and optimize algorithm and system-level specifications and the use of simulation test benches to verify final system behavior in real-time. Finally, it demonstrated an image processing implemen-tation using an Altera FPGA development platform.

The MangoDSP presentation discussed designing a video system with a combination of FPGAs and digital signal processors, using a video surveil-lance example, while the Barco-Silex presentation focused on enabling real-time JPEG2000 algorithm implementation on an Altera® Stratix development platform. The Ateme presentation covered FPGA co-processor development using an H.264 encoder example implemented on an Ateme development platform, and the SBS presentation demonstrated how to use C code and SOPC Builder to imple-ment video and imaging co-processors. Each of these partner presentations will be covered in more detail in the following articles in this issue of News & Views.

The seminar also featured product demonstrations from additional Altera partners including Accelchip, Gidel, Nuvation, Orchid, Plexus, PTG, and RPA. The Accelchip demonstration highlighted the benefits of using the MATLAB M software to implement an FPGA co-processor. Gidel demonstrated a race car with a tag ID, while Nuvation demonstrated the Cyclonebot gladiator robot. The Orchid demonstra-tion focused on image processing for medical X-ray applications, and PTG demonstrated an image rota-tion and stabilization implementation. Finally, RPA’s demonstration highlighted an image fusion application.

Figure 1. Code:DSP Seminar


Features


Features

Altera has just introduced version 2.2 of its DSP Builder development tool, which interfaces between the Quartus® II and MATLAB/Simulink design tools (see Figure 1). DSP Builder 2.2 allows engineers to shorten the DSP design cycle by creating the hardware representation of a digital signal processing (DSP) design in an algorithm-friendly environment. This new version offers enhanced DSP intellectual prop-erty (IP) and development tool support that enables engineers to more quickly and easily take advantage of the performance of Altera’s new high-performance Stratix® II and low-cost Cyclone™ II device families in their DSP designs.

DSP Builder 2.2 fully supports Altera’s rich DSP MegaCore® IP portfolio. The new Nios® II embed-ded soft processor is also supported through the DSP Builder link with the SOPC Builder development tool. SOPC Builder is included in the Quartus II software, which delivers the industry’s lowest development costs for advanced system designs. DSP Builder 2.2 also supports MATLAB 7 and Simulink 6 software packages included in The MathWorks Release 14.

“Adoption of Simulink for FPGA designs targeting DSP applications continues to accelerate,” said Ken Karnofsky, marketing director for Signal Processing and Communications at The MathWorks, Inc. “By extending their powerful DSP IP portfolio to DSP Builder, Altera has delivered a strong set of optimized FPGA libraries for filtering, transforms, and forward error correction. DSP Builder 2.2, with their feature-rich Stratix II DSP Development Kit, provides an ideal platform for accelerating digital signal processors with FPGA co-processors.”

This latest version of Altera’s DSP Builder develop-ment tool delivers new features and IP support that will help designers enhance the performance of their DSP designs. For example, designers can achieve 1.3 microsecond fast Fourier transform (FFT) performance—the industry’s fastest—and over 300-MHz finite impulse response (FIR) filter-ing performance when implementing designs in Stratix II devices.

Video and image processing design using Simulink is made easier by the inclusion of a color space con-verter core and an edge detection design featuring a two-dimensional filter. In addition, the forward error correction requirements for the 802.16d broadband wireless standard can be implemented in the small-est Cyclone II device using the Viterbi and Reed-Solomon MegaCore functions available with DSP Builder 2.2, enabling low-cost wireless design for cost-sensitive markets. Finally, DSP Builder 2.2 can link with Altera’s SOPC Builder tool to design custom FPGA co-processors, which can automatically link to system processors, reducing development time.

DSP Builder, version 2.2 is available now to custom-ers with a current DSP Builder subscription. A DSP Builder subscription is priced at $1,995 and includes 12 months of software upgrades. A one-year license is included in Altera’s new DSP Development Kit, Stratix® II Edition. A download of the DSP Builder tool is available from Altera’s DSP solutions center at www.altera.com/dsp. Simulink and MATLAB are available today from The MathWorks at www.mathworks.com.

DSP Builder 2.2 Accelerates Stratix II & Cyclone II FPGA-Based DSP Designs

Figure 1. DSP Builder 2.2


Features

Using Simulink & Altera’s DSP Builder in Model-Based Design for Video & Image Processing Systems

by Amnon Gai and Houman ZarrinkoubThe MathWorks

Using a video processing application example, this article discusses an environment that provides tools for hierarchical modeling, data management, and sub-system customization, with which you can create concise, accurate representations of complex systems. Using model-based design, you can take advantage of the increasing performance of today’s digital signal processors and FPGAs, while reducing design verifi-cation and time-to-market.

Simulink

Simulink is a platform for multi-domain simulation and model-based design of dynamic systems. It pro-vides an interactive graphical environment and a cus-tomizable set of block libraries that let you accurately design, simulate, implement, and test signal processing, communications, and other time-varying systems.

Simulink is integrated with MATLAB, providing immediate access to an extensive range of tools for algorithm development, data visualization, data analysis and access, and numerical computation.

Model-Based Design for Video & Image Processing Systems

Simulink and the Video and Image Processing Blockset enable you to design and model the behav-ior of a video and imaging system and then simulate the entire system model to accurately predict and optimize performance. The system model becomes a specification from which you can generate real-time software for testing, prototyping, and embedded implementation, while minimizing manual effort and reducing the potential for errors.

For applications such as image segmentation or object detection, you can extract specific objects or patterns from the video sequence and process these regions separately. In surveillance and tracking, for instance, you may want to lock into a specified target to per-form intensive processing on it. In video compression, you may want to apply a coding scheme to the rapidly changing foreground that is different than the scheme applied to the slowly evolving background. In any of these examples, you need to characterize a region of interest by specifying the subset of pixels that repre-sent the interesting object.

In nearly all such applications, the first step is to deci-pher the boundaries or the edges of a region relative to the background or the adjacent regions. Hence,

edge detection methods are of paramount impor-tance and are in widespread use in segmentation and tracking applications.

There are a variety of edge detection techniques available. In methods like Prewitt or Sobel, edges are found by determining the sharp changes in the gradient of the image intensity. In Laplacian-based methods, edges are characterized by zero-crossing of the Laplacian function of the intensity. There are parameters associated with each of these algorithms. For example, the threshold of the Sobel algorithm plays a significant role in deciding how much change of intensity is tolerated across a pixel before the pixel is deemed to reside on an edge.

Adopting different edge detection algorithms and their parameterization has a direct impact on the viability of the overall object detection and track-ing performance. Studying these compromises and trade-offs when designing and implementing an edge detection system can take several days for a group of engineers. By using the block libraries provided in the Video and Image Processing Blockset (see Figure 1), the same group can design a model-based representa-tion in a few hours.

The Video and Image Processing Blockset provides a library of basic primitives, advanced video algorithms, and other features for designing real-time video and imaging systems and specifications.

Figure 1. Video & Image Processing Blockset

continued on page 10


Features


Features


Features

Verification: The Number One Bottleneck

As design complexity increases, the challenge of design verification grows proportionately. In a recent article (see References), Dr. Jack Horgan notes that, “hardware verification has itself become more chal-lenging. Verification times have increased with ris-ing gate count and as the overall design complexity grows.” According to a survey by Collett International Research in 2002, only 39 percent of designs were bug-free at first silicon, while 60 percent contained logic or functional flaws. More than 20 percent required three or more silicon spins. A Collett survey also showed that nearly 50 percent of total engineering time was spent in verification. Figure 2 shows the typical trend of introduction and detection of defects in hardware design using conventional design flow.

Continuous Test & Verification

Modeling and simulation is the foundation of all system development. By performing detailed simula-tions of a system, including testing its behavior under different conditions, using a variety of parameter val-ues and inputs, you can quickly identify, isolate, and fix system design flaws. At this stage of a design, it is relatively simple to differentiate between design flaws and programming problems.

Once your model is finalized, you can use this validated design as an executable specification or reference to gen-erate test signals and, as a result, streamline the verifica-tion of your hardware or embedded software designs. The model can also be used as a blueprint by teams that implement and verify that design in hardware.

Digital Signal Processor & FPGA Implementations

Once the model is performs successfully in simulation, you then need to transfer the system design to a hard-ware platform for implementation on an embedded tar-get. This is increasingly being done using automatic code generation capabilities inherent in Model-Based Design.

However, because of the size and complexity of the systems being developed, and the dependence on leg-acy code, you must balance using automatically gen-erated code with hand-written code. You can use code profiling, or selective manual optimization, to review automatically generated code and quickly identify the segments that require manual optimization. When compared to manually writing and optimizing all the system implementation code, or using auto-gener-ated code as it stands, selective manual optimization is gaining acceptance as a faster and more practical way to implement complex designs.

Furthermore, to provide users with more efficient methods to achieve design implementation and pro-duce target-ready systems, vendors such as Altera pro-vide specialized blocksets that integrate with Simulink for multi-technology designs. Because DSP system design in FPGAs requires both high-level algorithm and hardware description language (HDL) develop-ment tools, Altera’s DSP Builder integrates these tools by combining MATLAB and Simulink with VHDL synthesis, and Altera development tools such as Quartus® II and SOPC Builder. The DSP Builder allows engineers to shorten the DSP design cycle by creating the hardware representation of a DSP design in an algorithm-friendly environment. Using DSP Builder, for example, an engineer can verify perfor-mance on a Stratix® II FPGA and download opti-mized code when the design is complete. Working at a higher level of abstraction, the designer can more thoroughly explore the design space, achieving system-level optimizations that cannot be obtained using C or HDL-based tools.

Conclusion

There is growing acceptance for the practice of design development in an environment that enables the engineer to maintain a bit-true executable specifica-tion, particularly in with more complex systems. The increasing demand to shorten time to market while providing better product quality is difficult to meet using traditional manual design methods. Clearly, when hardware engineers use a common model-based specification to test and verify the final imple-mentation, a significant portion of the verification pain is reduced, and increased design complexity with reduced design cycles become an achievable goal.

References

n Horgan, Jack. March 29, 2004. Hardware/Software Co-verification. EDA Café Weekly.

n The MathWorks web site at www.mathworks.com/dsp

n Altera web site at www.altera.com/dsp

Figure 2. Design Stages

��

��

��

��

��

��

��

��

��

��

��

�

��

��


Features


Features

by Joel RotemChief Application EngineerMango DSP Corporation

Digital video surveillance systems now offer capa-bilities that make them a compelling alternative to the traditional analog systems. In addition to offer-ing advanced video compression techniques, digital video surveillance systems can now be augmented with algorithms, such as stabilization, panorama, and video motion detection. This article discusses the benefits of these new technologies and their optimal implementation on a platform using a combination of discrete digital signal processors and FPGA co-pro-cessors. It will also detail the requirements of modern surveillance systems, the algorithms commonly used in these systems, and the development platforms available to accelerate system design.

Typical requirements for commercial video surveil-lance systems range from one-to-eight camera sup-port, advanced video compression such as MPEG-4, Windows Media 9 H.264, low-latency encoding (1-3 frames), and simultaneous view and record at dif-ferent frame rates. Encoding resolutions ranging from CIF (approximately VCR resolution) up to D1 (approximately DVD resolution). Video rates range from 2 frames per second (home security) to up to 30 frames per second (used by casinos and other pre-mium-type systems).

Implementation

A combination of digital signal processors and FPGA co-processors using high-performance, high-density Stratix® II FPGAs deliver the high performance and highly flexible signal processing required for digital video surveillance systems. The benefits of digital sig-nal processing (DSP) includes high clock rates (up to 1 GHz), C/C++ language-based development, built-in memory management, and built-in I/O interfaces. At the same time, digital signal processors have a limited number of instructions/clocks and multipliers, as well as fixed word sizes and I/O interfaces. In addition, most digital signal processors allow very limited inter-proces-sor communication, relying on low-speed buses such as PCI to connect to other digital signal processors.

FPGAs, on the other hand, include a high number of instructions/clocks, one-to-two orders of magnitude more multipliers than digital signal processors, and flexible word size. Stratix II FPGAs, for example, have up to 384 18 × 18 multiplier/accumulators per device, each capable of running at 370 MHz, as well as nearly 180K standard logic elements (LEs). FPGAs also enable access to advanced memory devices such as double data rate (DDR), DDRII, RLDRAM, and

quad data rate (QDR). Additionally, high-perfor-mance FPGAs can be connected to other FPGAs or other devices, such as digital signal processors, via 1-Gbps high-speed LVDS and multi-gigabit serializer/deserializer (SERDES) buses.

The two types of devices clearly complement each other. While digital signal processors enable rapid development of new and complex algorithms, they can only run two to four calculations at a time. On the other hand, FPGAs can perform mathematical opera-tions on an entire vector or even matrix at a time. Furthermore, FPGAs are excellent for connecting multiple processing nodes together, distributing the data among digital signal processors and collecting and recombining the sub-calculations into a single output stream.

Specifically, in video surveillance applications, FPGAs can be used to preprocess the video, providing video stabilization, filtration, and motion detection. The sta-bilized video, along with the motion detection infor-mation, can then be fed into a digital signal processor to provide video compression and network stack.

Enhancing Video Surveillance Quality

Given a fixed bandwidth, video quality can be improved using several different methods, including using advanced coder/encoders (CODECs), defin-ing the region of interest, image stabilization, and panorama.

The most commonly used advanced video compres-sion technique is MPEG-4. Designers, however, are examining the H.264 baseline profile, which, by comparison, provides a 33 percent improvement in video quality, significantly enhancing the detection capabilities of a video surveillance system.

Video quality, and, therefore, detection capability, can also be enhanced by defining areas of greater interest in terms of surveillance. In areas that are of low inter-est, such as the sky, ceilings, treetops moving in the wind, etc., the system can increase the level of video compression, thereby reducing the video bandwidth and processing load dedicated to those regions where the danger of a security breach is low. This in turn allows the system to focus more closely on areas of high interest, such as outer doors, windows, interiors of high-security areas or areas where motion is antici-pated or has been detected. Essentially, by defining the area of interest and focusing on those areas of greater concern, the system can reduce the number of false alarms, while increasing the likelihood of detecting a true security breach.

Leveraging FPGA Co-Processors to Optimize High-Performance Digital Video Surveillance Systems



Features

Camera movement and/or vibration can also degrade video surveillance quality. Camera movement, of course, may be necessary to ensure coverage of an entire surveillance sector, while vibration may be caused by environmental factors, such as wind or passing vehicles. Either of these factors, however, can reduce compression quality and possibly result in dropped video frames, thereby degrading the effectiveness of the surveillance system. In worst-case scenarios, these factors can cause system processing overload.

Digital video stabilization techniques can now be used to overcome physical vibration of a camera. Several algorithm types can be used to this end, but all fol-low the same principle: certain parts of the image are compared to the previous image. The picture is offset by various vectors, and a search is used to find the point where the correlation between the images is the highest. The offset vector is then applied to the entire image, with the edges ending up a little cropped, but most of the image remaining stable.

An FGPA can be used to perform the search and cor-relation. Typical requirements for a single channel of video at 30 fps D1 resolution are approximately 3,000 to 5,000 FPGA LEs—the equivalent of approximately 4 to 7 percent of the logic area in high-density devices like Altera’s Stratix® II FPGAs.

The ability to provide a panoramic view is also a critical feature in video surveillance systems that incorporate swivel cameras. This feature minimizes the number of cameras required to cover a particular site and enables security personnel monitoring the system to view a wider area at a glance or to focus on a particular area where a potential security breach has been detected. When the panorama algorithm is coupled with a swiveling camera (PTZF), the system can track the movement of the video image. Rather than shifting the image back to center, the image is expanded to a larger resolution picture. The new image is “stitched” onto the old with the overlapping parts updated. The same FPGA mechanism used for stabilization is used for panorama, with the stitching requiring minimal additional computation.

Video motion detection, which is effective both indoors and outdoors and regardless of time of day, can significantly enhance the capabilities of a video surveillance system. This feature uses a tracking algo-rithm that receives noisy detections from surveillance cameras and filters out insignificant motions caused by noise in the image, camera movements caused by environmental factors such as wind, and false images caused by clouds or moving branches. A wide variety of algorithms are available to implement this func-

tion. It facilitates tracking intruders and can be com-bined with traditional motion detection to minimize false identifications. Motion detection algorithms range from the very simple high pass, or edge detec-tion filters implemented using several hundred LEs, up to very complex algorithms that can overcome rain and wind interference, as well as differentiate between people, small animals, cars, etc.

Advanced algorithms typically use motion track-ing, similar to the motion estimation blocks used in MPEG compression. The motion of various parts of the image is tracked over time and, if the move-ment appears consistent, an intruder is detected and tracked. This allows the system to ignore rain, dust, and light changes. Anywhere from 1,000 to 3,000 FPGA LEs are required to implement an advanced motion detection algorithm.

Video Archiving

Video archiving enables security personnel to docu-ment possible intrusions and maintain video that can be used to identify intruders. It can be done either locally, where the image was created, or remotely at a more secure location. Intellectual property (IP) cam-era or video servers send all the compressed video to a back office, where a central recording unit collects all the video streams and archives them. This configura-tion allows for inexpensive end units, and easy video management, but requires a very reliable high-band-width network to support all the cameras transmit-ting at once. Another configuration uses local hard disk recording, allowing the back office to view only one camera at a time, or access any of the archived video on any unit.

Conclusion

Digital video surveillance is just one of the many video-imaging applications that increasingly require very high signal processing and memory bandwidth processing, as well as the ability to communicate among multiple processing units to deliver a required level of resolution and live video viewing. Other applications include medical imaging, optical inspec-tion, video broadcast, scientific computing, and military applications. It is likely that the engineers designing these systems will increasingly leverage the combined power of digital signal processors and high-performance FPGAs to deliver the required video imaging quality.


Features


Features


Features

An FPGA-Based Algorithm Accelerator for Software Designers

Contributed by SBS

FPGAs have come into wide use by hardware design-ers to provide high-performance digital signal pro-cessing (DSP), enabling solutions that are often 10× to 100× faster than can be accomplished with PC or single board computer (SBC) processors. For software design teams without hardware-design capability, this option has not been available, because FPGAs are usu-ally programmed in hardware description languages (HDLs), which require specialized hardware design knowledge.

A new solution, offered by SBS Technologies and Celoxica, brings FPGA power to software designers, without the need for in-depth hardware expertise (though it does require a useful learning experience in basic FPGA operation). The solution consists of SBS’s high-performance Tsunami FPGA PCI board, featuring Altera® Stratix® devices, and Celoxica’s PDP development environment. As a part of Celoxica’s DK design suite of system design tools, the PDP environ-ment allows programming in a variant of the stan-dard C language familiar to software designers.

This article describes a project based on this solution that in the end provided an impressive 370× signal-processing speed improvement. This reduced the time required to perform a time-critical image-processing operation from an agonizing 12 minutes on a stan-dard Pentium 4 Windows XP PC, to a near-instan-taneous two seconds on the same PC with the SBS Tsunami Board, SBS Wave Software, and Celoxica’s PDP development environment.

Although achieving this remarkable acceleration does not require hardware knowledge, it does require a bit of a learning experience, and the designer does need to become familiar with the basic elements of FPGA-based design, something that can be done relatively quickly. The toolset makes this an interesting and forgiving learning experience.

The Application

Figures 1 and 2 show the accelerated application in action. The processing required was a stream of Hough and inverse Hough processing, which was used to highlight lines or “cracks” on an image. In this case, it was used to highlight small cracks on images of thousands of kilometers of road surface, as shown in Figure 1.

Figure 1. Original Image

Figure 2. Hough Result Overlay


Features


Features

How It Works

The process of accelerating a C-based algorithm with this toolset involves starting with a C-based imple-mentation, translating it to Handel-C, then simulat-ing the design on the PC, and finally running the design on the FPGA processor.

The team discovered that the design process worked best if a more thorough 6-step process was used, described in detail in the following sections.

First Step: Determine What to Accelerate

The team determined that the algorithm stream really was CPU bound, and required 12 agonizing minutes of 3-GHz Pentium instructions to execute. The customer requested a time of 2 seconds, 360 times faster. The code was profiled to see what functions were consum-ing the most processor bandwidth. In this case, a few functions took 99.9 percent of the processor MIPs.

Second Step: Design the FPGA Implementation

The next challenge is to lay out an FPGA design that will accelerate the functions of this code in terms of a paper design. The paper design should include analy-sis of the algorithm for the following:

n Memory size requirements for input, output, and look-up tables (LUTs)

n Memory accesses to determine how many times a memory must be accessed per clock

n Mathematical functions required

n Dynamic range of values to determine the number of bits required in mathematical functions

Additionally, the following can be considered during the paper design (see Figure 3):

n What can be parallelized

n What can be pipelined

Once the paper design is completed, the total FPGA clock cycles for each step are counted to determine approximately how long the processing will take. In the case of the Hough transform, the 9 processing cycles were fully pipelined (1 result per clock after ini-tial latency) and embedded in a 3-dimensional loop of X, Y, and θ. The total number of cycles would be 9 + (9 × X × Y × θ), which in this case was 9 cycles of latency + (9 cycles × 64 pixels × 64 pixels × 64 steps) cycles per processed tile.

It is not important to get the design fully optimal on the first try. One of the strengths of the toolset is the ability to do rapid simulations, and to tune the design based on results.

Third Step: Code the Design

With the Celoxica design software, coding the design was a relatively straightforward process. Handel-C looks pret-ty much like C, but has some important new capabilities that provide control of the following new functions:

n Enhanced Bit Manipulation: Take, drop, concatenate, bit selection, and width operators

n Parallelism: Used to take advantage of hardware parallelism

n Macro Procedures and Expressions: Used to produce in-line code that does not share hardware resources

n Arbitrary Width Variables: Used to minimize hardware usage for variables

n Interfaces: Used for connecting to external devices or logic

n RAM and ROM Types: Used to efficiently implement arrays of data in Handel-C

n Signals: Used to represent wires in hardware

n Channels: Used to communicate between parallel branches of code or across clock domains


Figure 3. FPGA-Based Algorithm Processing: Parallel & Pipelined Capability


Features

Fourth Step: Simulate the Design

The toolset provides for a good simulation environ-ment that is easy to set up, operates rapidly, and pro-vides full bit-true/cycle-true simulation, meaning it faithfully simulates the FPGA implementation. With this simulation, the designer can quickly:

n Confirm correct output from the design by comparing it with the original C software version

n Report what the speed of operation will be when run on the FPGA processor

Developing and simulating the new design piece-by-piece is recommended to make it simpler to find any problems. The pieces can then be integrated together step-by-step, to confirm correct overall operation.

Fifth Step: Run the Design at Full-Speed

With the simulation looking good, it is then a simple matter to compile the design for hardware and acti-vate the data streaming manager (DSM) so that the data stream is routed to the FPGA processor board, rather than to the simulator.

Sixth Step: Tune for Even More Speed

As mentioned, one of the benefits of this approach is the ability to quickly tune designs, re-test, and be up and running with the new design in minutes.

Tuning involves the following steps:

n Pipeline the algorithm to accept 1 input value and produce 1 output value per clock cycle

n Continuously divide the processing into more parallel streams and continue until FPGA resource utilization approaches 100 percent

n While compiling in the Quartus® II software, identify slowest spots in algorithm, and optimize that part of the algorithm

n If more speed is required, partition the algorithm across multiple FPGAs and even across multiple Tsunami boards

Although much of the above can be done during the paper design, in practice it is faster to do this with the simulator. The simulator also gives a first estimation of required FPGA resources (memory blocks, multi-pliers, logic elements) needed to implement the paper design. Later in the design cycle, the Quartus II com-piler provides the fully accurate resource estimate.

Hardware

The implemented solution is extremely scalable, sim-ply by plugging in as many FPGAs as is required. The solution auto-detects how many FPGAs are installed (the SBS Tsunami solution can provide from 1 to 5 per PCI board, and multiple boards may be installed). In the pilot project, the design was tile-based. Tiles were dispatched to, and then collected from, each FPGA in order, and the logic to do this is provided with the solution.

The 370:1 acceleration mentioned earlier in this article was achieved with 10 FPGAs installed (5 on each of 2 boards). At the low end, an acceleration of about 37:1 is provided when only a single FPGA is installed.

The SBS offering provides an integrated develop-ment environment. It includes the SBS Tsunami FPGA processor board, the Celoxica PDP development environment, as well as Altera’s Quartus II development software and SOPC Builder that compile solutions to the FPGA targets. It also includes an extensive library from SBS to simplify design of multi-FPGA and multi-board solutions.

Conclusion

By combining SBS’s high-performance Tsunami FPGA PCI board, Altera’s Stratix devices, and Celoxica’s PDP development environment, designers were able to improve a time-critical image processing operation by 370×.


Features


Features


Features

Enabling Real-Time JPEG2000 with FPGA Architectures

by Olivier CantineauBarco

The JPEG2000 standard is being adopted by a wide range of applications, including medical imaging, military, security systems, and digital cinema. To enable these applications, JPEG2000 has many unique features, including scalability, support for regions of interest, lossless support, and low latency. This article describes an FPGA-based JPEG2000 implementation and demonstrates the performance, cost, and integra-tion benefits that can be derived by FPGA and struc-tured ASIC implementations.

Introduction

Many imaging applications are moving from the analog to digital domain for a number of reasons, including perfect copy, controllable transmission quality, easy storage, and easy manipulation. One major challenge to implementing this transition is the large size of the images. For instance, a 640 × 480 VGA RGB image is 1 Mbyte; a 2,048 × 1,536, 8-bit grayscale medical image is 3 Mbytes; and a 4,096 × 2,160, 36-bit digital cinema image is 38 Mbytes. There is a need, therefore, for high quality image compression.

Each application has slightly different requirements. JPEG2000 offers superior benefits to JPEG for a wide variety of applications. It has support for both lossy and lossless compression in a single algorithm. It offers improved quality at the same compression ratio, due to its removal of block artifacts, support for regions of interest, and non-iterative optimal rate control. It has been designed to facilitate on-screen display and computer imagery. It has significantly improved bit-stream scalability, which is defined at the image level. This scalability includes an embed-ded fast preview with further refinements and adapt-ability to instantaneously available bandwidth. All the

features and compression efficiency, however, come at the expense of algorithm complexity. JPEG2000 is up to six times more complex to implement than JPEG. Hardware acceleration is, therefore, required for an efficient solution.

Altera’s Stratix® and Stratix II FPGA—featuring fast and numerous RAM blocks and a large amount of logic and hardware multipliers—make these FPGAs excellent choices for implementing JPEG2000 solu-tions. The presence of large on-chip M-RAM blocks allows the implementation of a large on-chip tile buf-fer, increasing the overall performance and integra-tion level of the core.

JPEG2000 Overview

The JPEG2000 algorithm is illustrated in Figure 1. The processing is divided into two separate stages highlighted with dashed boxes. The first stage per-forms the encoding, while the second stage (Tier-2) builds up the stream and includes an a-posteriori rate allocator.

First Stage: Discrete Wavelet Transform (DWT) Based Compression

This encoding stage is illustrated in Figure 2, show-ing two levels of wavelet decomposition resulting in 7 sub-bands. To apply JPEG2000 compression, the image is divided into rectangular tiles of configurable size. Figure 2 illustrates the JPEG2000 operations on a given tile of pixels.

Each tile separately undergoes the 2-D wavelet trans-form, which splits the frequency information of the tile in a series of pictures, named sub-bands. This is the decorrelation transform of the JPEG2000 algo-rithm. Each sub-band is the result of the 2-D filtering of the original tile for a given frequency range. The wavelet transform is a recursive operation that can be applied for a configurable number of times. This is called the number of decomposition levels. Each application of the transform generates four sub-bands from its original image by combining high-pass and low-pass filtering operations along the lines and the columns of the pictures. This generates sub-bands marked as LL, LH, HL, and HH, where L represents low-pass filtering and H represents high-pass filter-ing (see Figure 2). The two letters are grouped for row-column combinations. Each level of wavelet decomposition applies on the LL result of the previ-ous wavelet decomposition. The level of decomposi-tion for a given sub-band is included in its name. This is the number appearing in the #LL, #LH, #HL, and #HH marks in Figure 2.

Figure 1. JPEG2000 Block Diagram


Features


Features

Each sub-band can then undergo selective quantiza-tion by a programmable factor for lossy compression. Bypassing the quantization gives lossless opera-tion. The resultant quantized sub-bands are further divided into smaller rectangular blocks, named code blocks. Each code block passes through an entropy encoder. This is the compression engine of the JPEG2000 algorithm, which reduces the number of bits needed to represent the code blocks. All bit planes of the current code block are examined starting from the most significant one. In each plane, the bits are scanned in a zigzag order and their context (informa-tion on the predominant value of the surrounding bits) is determined.

Finally, an arithmetic encoder uses the value of the bit and the context. It generates the code stream rep-resenting the compressed code block. The arithmetic encoder also computes distortion metrics. These reflect the image distortion that would be encoun-tered when reconstructing the code block with its currently encoded portion.

Second Stage (Tier-2): Packet Selection & Reordering

The code stream generated by the arithmetic encoder, together with the distortion metrics, allows the JPEG2000 post-processing stage to selectively build the final bit stream. This process is driven by the fol-lowing two user-defined parameters:

n Compression Ratio: The Tier-2 stage selects incoming packets to attain the user-specified compression ratio. The algorithm rejects packets that do not contribute to a sufficient improvement of the compression distortion. This mechanism allows a precise control of the generated compressed file size, while maintaining a good image quality.

n Progression Order: JPEG2000 allows an initial preview of a picture with the first portion of the bit stream. With the subsequent parts of the compressed file, the image is progressively refined. JPEG2000 standardizes various refinement orders by prioritizing an image characteristic, for example, quality or resolution. The Tier-2 stage attains the desired progression order by reordering the incoming packets.

Implementation on FPGA

Due to its powerful features, JPEG2000 requires more computational resources than JPEG to achieve similar encoding and decoding speeds. To increase

the JPEG2000 performance, this article proposes an architecture where computationally intensive tasks are off-loaded to an FPGA co-processor, as shown in Figure 3. JPEG2000 processing is accelerated by executing wavelet, quantization, and entropy encod-ing on an FPGA.

Figure 4 shows a software benchmark of the JPEG2000 algorithm for lossless and lossy compressions, where a large part of the processor time is spent on entropy encoding. This is particularly true for lossless encod-ing, which requires many encoding passes.

Figure 2. Overview of the JPEG2000 Encoding Stage (Showing 7 Sub Bands)

Figure 3. Co-Processor Architecture

Figure 4. Software JPEG2000 Benchmarking



Features

Hardware FPGA implementations can accelerate wavelet transform and quantization by pipelining these operations. Entropy encoding, however, is more difficult to optimize on, due to its bit-serial structure. This is illustrated in Figure 5, which shows the amount of time spent on the discrete wavelet transform (DWT) and entropy operations by the FPGA co-processor proposed in Figure 3. The bottleneck is the entropy-encoding stage showing a permanent activity (100 per-cent on the graph). The hardware wavelet transform is only active during 7 to 10 percent of the time needed to entropy encode the corresponding data.

To compensate for this slow entropy encoding and to better balance the activity of the various blocks of the JPEG2000 encoding, several entropy encoders must be placed in parallel to independently process the code blocks generated by a single wavelet engine.

Figure 6 shows a block diagram of the Barco Silex JPEG2000 encoder core (BA112JPEG2000E), illus-trates the main functional modules, and provides a simplified view of the interfaces. It also gives an over-view of the logic and memory usage for each module

on Altera’s Stratix® and Stratix II devices. The block diagram shows the parallel structure of the core, where several entropy encoders are implemented to process the data generated by the wavelet engine.

Pixel data is input through the pixel interface, and com-pressed streams are made available at the compressed interfaces, together with distortion metrics. The core features a simple generic CPU interface suited for use as a bus peripheral to various processors. The fol-lowing sections describe the modules constituting the BA112JPEG2000E core as shown in Figure 6.

2D DWT Module

The first module of the core is the wavelet-transform engine. This module can be configured to accept tiles of pixels of any size up to 128 × 128. It performs two-dimensional discrete wavelet decomposition on the incoming data with up to five programmable decomposition levels. The wavelet transform can be programmed to be lossy, lossless, or bypassed.

The DWT module accepts incoming pixels of any size up to 12 bits (10 bits for lossy). Finally, it stores its results in the on-chip tile buffer ready to undergo quantization and code-block decomposition.

Quantizer

The quantizer fetches the sub-bands available from the tile buffer and applies a programmable quantization step. Different quantization steps can be programmed for each sub-band. Lower frequency sub-bands can thus be weighted differently from higher frequency ones. The quantizer can be bypassed for lossless operation.

Tile Splitter

This unit further divides the quantized sub-bands into rectangular code blocks of programmable size (up to 32 × 32), ready for the entropy encoding by an arithmetic encoder. The cores feature a configurable number of entropy encoders placed in parallel to sustain high encoding rates. The number of imple-mented chains is selected during the IP synthesis process. Each entropy chain processes a code block independently from neighboring chains. The tile-splitter module is responsible for arbitrating between the available chains, dispatching the various code blocks to be encoded. It stores the code blocks in the local code-block buffers.

�

Figure 5. Hardware JPEG2000 Benchmarking

Figure 6. Block Diagram of the Barco Silex JPEG2000 Encoder



Features


Features


Features

Modeler & Arithmetic Encoder

The modeler performs the first part of the entropy encoding. It examines the code-block, bit plane by bit plane, and extracts relevant bits in zigzag order in each bit plane. Moreover, it computes the context information needed by the arithmetic encoder and the distortion metrics. These will be made avail-able at the compressed interface and are used by the tier-2 part of the JPEG2000 algorithm. The arithme-tic encoder processes the bits and contexts, and makes the stream available at the compressed interface.

Performance Analysis

Table 1 illustrates JPEG2000 decoding capabilities benchmarked on different Stratix II devices. The fol-lowing information is given in the table for each of three members of the family:

n Equivalent logic element (LE) usage for the JPEG2000 decoder core (with device fulfillment percentages)

n Decoding configuration: the number of entropy channels (configured at synthesis stage)

n Resultant sample rate (the left number is for typical lossy compression; the right number is for typical lossless compression)

n Resultant VGA frame rate (640 × 480 24-bit RGB)

n Resultant decoding time for monochrome 8-bit 3-Mpixel medical images (2,048 × 1,536)

These results can be compared to the estimated per-formance of software implementations. A mid-range Stratix II EP2S60C5 device can achieve 100 MSPS. This compares to a 600-MHz Texas Instruments TMS320DM642-600 DSP at 6 MSPS and a 3-GHz Pentium IV at 10 MSPS.

These results can be used to estimate a price-perfor-mance ratio comparison between an FPGA imple-mentation and a digital signal processing (DSP) solution, as shown in Figure 7. The DSP price is based on Texas Instruments’ TMS320DM642 10k-unit price of $45. The Altera price is based on an EP2S30C5 10k-unit price of $80. An FPGA-based solution using Stratix is 4.5 times more efficient than a DSP solu-tion, while a structured-ASIC based solution using an Altera Stratix HardCopy® device is 11.5 times more efficient. These results show the advantages offered by FPGAs and structured ASICs for implementing the highly complex bit-serial operations involved in the JPEG2000 compression algorithm.

Conclusion

The JPEG2000 standard defines an algorithm that is able to offer a large spectrum of features, such as progressive bit stream, precise rate control, region of interest, and high quality lossless and lossy compres-sion. For these reasons, JPEG2000 is being considered in a variety of applications, including medical imag-ing, military, security systems, and digital cinema. These features come at the expense of algorithm complexity. This article supports the performance, cost, and integration benefits that can be derived by FPGA and structured ASIC implementations.

Table 1. JPEG2000 Decoder Performance for Stratix II Devices

Stratix II Device

Area (LEs, Usage %)

Number of Entropy Channels

Sample Rate VGA (Hz) PACS 3M (ms)

EP2S15C5 10,500 (67%) 2 14M/10M 15/10 225/315

EP2S30C5 25,000 (74%) 8 50M/37M 54/40 63/85

EP2S60C5 50,000 (83%) 8 100M/74M 108/80 32/43

Figure 7. Price/Performance Ratio Comparison


Features


Features

Digital Signal Processors & FPGA Co-Processor Development (H.264 Encoder Example)


by François-Xavier ParisotProduct Line ManagerAteme

Algorithm requirements are increasing much faster than off-the-shelf digital signal processors can keep pace. A primary example of this is video compres-sion. H.264 is a new standard which improves video quality by a factor of two over a given bandwidth, but requires approximately four times more processing power than preceding video compression standards. In addition, many applications are moving toward high-resolution video, which further increases the processing requirements. Therefore, hardware accel-erators are required to cost-effectively meet H.264 system requirements. Digital signal processors and FPGA co-processors for H.264 encoding provide a cost-effective and flexible solution.

This article describes H.264 encoding and how it can be implemented with digital signal processors and FPGA co-processors.

Why Encode?

A complete digital transmission chain begins with digitization and color space conversion (CSC) in YUV. For a 720 × 480 image at 30 Hz with an 8-bit sample, the stream is 237 Mbps. The serial data interface (SDI), for example, was defined to transfer 270 Mbps, and is used in broadcast and digital video equipment.

There is a wide range of applications, such as broadcast media (satellite, cable, xDSL, intranet), digital media storage (DVD, file archiving), video conferencing, video on demand, and video over mobile network that rely on networks with different bandwidth, such as:

n Broadband Network (10 Mbps)

n Satellite/Internet (1 to 2 Mbps)

n Mobile Phone 3G (160 Kbps)

These applications impose a compression ratio rang-ing from 20 to 1,500.

Typically, the first step to reduce data is to suppress color information, since the human eye is less sensi-tive to luminance. Sub-sampling in 4:2:0 decreases the data requirement to ~120 Mbps.

Pre-processing is also very important. It enables more efficient video compression by filtering out noise and de-interlacing before the video gets to the video encode.

H.264 Encoding

After defining the MPEG-2/H.262 common stan-dard, the Video Coding Experts Groups (VCEG) of the International Telecommunications Union (ITU) (oriented toward video conferencing – low latency, lower bit rate) and the MPEG committee of ISO/IEC (oriented toward TV, HDTV, VCD, DVD – higher bit rate) once again formed a Joint Video Team (JVT) to finalize a new common standard, designated as ITU-T H.264 and ISO MPEG-4 part 10/AVC.

The previous MPEG standards specified the bit-stream format, but not all the tools to obtain it. This has enabled Ateme to develop its own tools in its MPEG-4 ASP encoder, obtaining a better image qual-ity for the same bit rate than competitors.

The H.264 standard imposes more tools, grouped in three profiles: Baseline, Main, and Extended. Each profile has several levels (up to 14), each defining a degree of capability. See Figure 1.

There are several steps in H.264 encoding. The follow-ing paragraphs focus on intra and inter prediction, deblocking filter, integer transform and quantization, and bitstream coding.

Figure 1. Baseline, Main & Extended Profiles


Features

Intra & Inter Prediction

Intra prediction and coding exploit the spatial redundancy of an image. The image is decomposed in macroblocks, each comprised of 16 × 16 pixels. The following techniques are new to the H.264 (MPEG-4 - part 10) standard:

n 16 × 16 pixel macroblocks can be decomposed into seven types of smaller macroblocks (16 × 8, 8 × 8, 8 × 4, and 4 × 4 pixels)

n Four new predictions for 16 × 16 macroblocks (vertical, horizontal, DC, and plane)

n Seven new predictions for 4 × 4 macroblocks (vertical, horizontal, and diagonal)

Inter prediction and coding exploits the temporal redundancy of an image compared:

n to the one preceding (generates a P frame, predictive)

n to the one preceding and one following (generates a B frame, bidirectional)

The detection of movement can be calculated with half- or quarter-pixel precision. New techniques in H.264 include:

n P and B frames can refer to future frames

n B Frames can be used as a reference frames

n Referenced objects can be in several frames

The Deblocking Filter

A deblocking filter is applied on the encoded-decoded reference frames. As the same is specified for decoders, it can be taken into account in the encoder to further optimize the bitstream.

Integer Transform & Quantization Steps

Integer transform (MPEG-4 uses Discrete Cosine Transform) is used to eliminate round-ing errors. Also, the transform is applied on 4 × 4 blocks. Quantization uses 52 steps (MPEG-4 has 31) in logarithmic progression (+12% per step).

Bitstream Coding Step

Two new processes of entropy coding include: context adaptive variable length coding (CAVLC) and context adaptive binary arithmetic coding (CABAC). Context is selected from 398. CABAC enables a further gain of 10 to 15% in the bitstream compared to CAVLC. Information can thus be encoded in less than one bit.

Bitstream Regulation

Bitstream regulation is not part of the standard itself, but is essential to develop a high quality encoder. The regulations are :

n Variable bit rate (VBR) for fixed quality with low-variation constraints. Ateme also proposes a VBR mode with a maximum bit-rate constraint

n Constant bit rate (CBR) for bandwidth constraints, which imposes quantizer factor variations (thus image quality variations)

n Average Bit-Rate (ABR) provides the best of VBR and CBR and is oriented toward file recording

H.264 FPGA-DSP Encoding Mixed Implementation

Improved quality of H.264 requires intense computa-tional power, making it a very exciting challenge for a real-time main profile, full D1 implementation. Digital signal processors and FPGA mixed designs are the key to success. FPGA resources are used as hardware accel-erators (co-processors) for the digital signal processor.

This solution presents many benefits:

n Time-to-Market: Design time is reduced compared to ASSP and ASIC solutions

n Flexibility: H.264 is an emerging standard and solutions will likely be in flux for first few years

n Risk Reduction: ASSPs may not remain committed to this market

n Differentiation: Digital signal processors and FPGAs offer programmable capabilities and thus the ability to customize each solution

However, there are challenges to properly develop in an FPGA-digital signal processor mixed implementation:

n Functions: which functions are carried out by FPGA versus DSP

n FPGA-to-DSP Interface: bandwidth sizing and the co-processors ease-of-use by DSP developers

n Development Time: Development in FPGAs is longer than in digital signal processors

n System Integration: depending on architecture, 40 to 80 percent of encoding time can be spent in data transfers

Conclusion

With expertise in video compression algorithms, Ateme rec-ommends a step-by-step method to implement co-proces-sors in an iterative approach. To support this method, Ateme and Altera developed DMCK, which is an FPGA co-process-ing kit, including DSP and FPGA development tools.

For the availability of Ateme’s FPGA encoder and accelerator intellectual property products (including CABAC/CAVLC coding, deblocking filters, and others), see the Ateme web site at www.ateme.com.


Features


Features


Features

Custom Algorithm to SOPC Builder System Component

by Chris SullivanDirector, Strategic AlliancesCeloxica

The task of balancing standardization and com-ponent reuse with product differentiation through custom design is a dilemma every new project faces. Celoxica’s DKAccelerator for SOPC Builder has been expressly built to solve this problem. Retaining the familiar design methodology, designers can reuse components and library intellectual property (IP) while using DKAccelerator to rapidly generate and integrate custom IP.

DKAccelerator (part of the third-generation DK Design Suite of system design tools) allows designers to create unique SOPC Builder components from algorithms already described in C and auto-matically integrate them as library components (see Figure 1). These could be specialized digital signal processing (DSP) functions, high-performance encryption, compression or image filtering algo-rithms, or other software algorithms and custom instructions that would benefit from acceleration in hardware.

Built on Celoxica’s already established C-based design and synthesis technology, designers use DKAccelerator to efficiently migrate complex algorithms or system component descriptions to a hardware implementa-tion. This removes the need for difficult and time con-suming re-write of C algorithms into HDL and offers creative breathing space for architectural and algorithm exploration. By maintaining the algorithmic level of design abstraction, DKAccelerator enables simple SOPC Builder components to be built quicker.

For developers using custom instructions, DKAccelerator helps simplify the design pro-cess. Custom instructions are internal to the Nios® II embedded processor and can be used to implement specialist functions such as high-speed communications, a high-performance DSP instruc-tion, or to replace several standard Nios® II instruc-tions. DKAccelerator handles all of the required signaling for custom instructions, allowing rapid integration into Nios II implementations and helps maximize their utility when bus bottle-necks impede overall system performance.

With synthesis support for a comprehensive range of Altera® silicon and processor solutions (including CycloneTM, Stratix®, and Stratix II devices, and Nios and Nios II processors), the output of DKAccelerator is an EDIF netlist or register transfer level (RTL) description optimized for the target device. The resulting custom design component is automatically connected into the SOPC Builder environment using the AvalonTM switch fabric with DKAccelerator auto-matically handling the Avalon interface generation. From there on, the design flow remains the same as any SOPC Builder design. The complete system is generated, simulation models and test benches are created, and the design is driven to silicon via the Quartus® II software.

Image Processing Design Example

In the following design example, a custom image processing component is implemented using DKAccelerator. The design example shows three bouncing and rotating spheres. The other system components of the design (see Table 1) are generated from the SOPC Builder library. No external RAM or frame buffers are used in the example.

Figure 1. DKAccelerator & SOPC Builder


Features


Features

Table 1. Image Processing Design Example Components

Component Source Function

Spheres DKAccelerator VGA output and image generation

Nios II Processor Altera SOPC Builder Controls user interaction with the demonstration

UART Altera SOPC Builder Main control interface for the demonstration and is used by the Nios processor for user interaction

General-Purpose I/O Altera SOPC Builder Interface to buttons on the board. A secondary control interface for the demonstra-tion

On-Chip Memory Altera SOPC Builder Nios II processor code and data

The image is generated as follows:

1. In parallel, the functions X = ScanX - SphereX; Y = ScanY - SphereY; and R2 = X2 + Y2 are calculated for each sphere. This allows the determination of whether the current scan position is within each sphere (i.e., R2 ≤ SphereR2).

2. For the active sphere, the value Z is calculated from the square root of (SphereR2 - R2). The square root is pipelined. This gives a Cartesian point (X, Y, Z) on the surface of the rotated sphere.

3. This point is inverse rotated through two axes by angles Phi and Theta (different for each sphere). Sine and cosine are calculated through a fixed look-up table (LUT). This gives a Cartesian point (X’, Y’, Z’) on the surface of the unrotated sphere.

4. This point is then passed into a series of 3D Perlin noise functions with different spatial frequencies (www.noisemachine.com). These values are summed together to give a texture value for the current pixel.

5. The surface normal of the sphere at a given point is equal to (X/R, Y/R, Z/R). As the spheres are a fixed power of two size, this calculation is trivial. By computing the dot-product with a fixed vector, and adding a small ambient light value, the diffuse lighting value of the current pixel can be calculated. Multiplying this with the texture value gives the underlying shade of the current pixel. The specular component of the lighting is computed with a further dot-product and LUT providing a Phong shading model. The diffuse and specular components are added together and the result is saturated. This gives the final output value for each pixel that lies on a sphere.

6. The spheres are moved by their current velocity. If the spheres impinge on the edge of the screen, a new velocity and rotational speed is randomly generated.

Summary

By augmenting the SOPC Builder component library through custom component design, DKAccelerator provides the fastest and most flexible path for the creation and physical implementation of custom algo-rithms and IP. All IP described in C, whether legacy or custom-built, is now available to SOPC Builder design-ers in the form of flexible, optimized, and reusable components. In competitive markets where design turnaround and product differentiation are the critical elements between failure and success, DKAccelerator delivers an integrated and high productivity SOPC design environment tuned for Altera customers.

For more information email [email protected] or visit www.celoxica.com/dka


Customer Applications



Cyclone Devices Enabling Effective Power Metering

by Martin F. LieProject ManagerWireless Reading Systems ASA, Norway

In the electrical power sales and distribution market, accurate power metering brings efficient resource utilization, better forecasting, and more reasonable power costs. By enabling innovation in the metering market, the Altera® CycloneTM series of FPGAs has become a vital part of a metering solution now enter-ing the Nordic energy marketplace.

The Importance of Metering

Power production in many countries relies on kinetic factors such as water basin level, snow level, and weather, compared with static factors such as nuclear energy, gas, and coal. In the Nordic countries, electri-cal power is an asset that is heavily regulated due to the limited natural resources available and the ever increasing demand for electrical power. Power pric-ing varies greatly from season to season, and power consumption is traditionally reported on a quarterly basis by mail, phone, or Internet. The utility compa-nies’ need for frequent and accurate meter readings, coupled with the consumer’s desire for convenience and competitive billing, results in a demand for an automated and accurate meter reading system. WRS determined that the integration of radio frequency (RF) communications into the meter was the answer.

Wireless Reading

Wireless Reading Systems (WRS) addressed the challenge of last-mile-communication by using the Cyclone device in a highly adaptive wireless sensor network. Most of the RF processing has been imple-mented using digital signal processing (DSP) func-tions rather than discrete electronics. The licensed 60- to 90-MHz band was selected because of its efficient installation demands. However, this solu-tion has created new demands, such as new antenna solutions. Existing power lines can be used as aerial antennas with the fuse cabinet acting as an effective ground plane, leading to lower installation costs because no new cabling needs to be installed. The frequency band selected for WRS’s application has a wavelength ranging from 3.27 to 4.90 meters, but in practice the signal propagates through far more cable. By carefully selecting through already installed power lines, the installation becomes quite efficient, leading to good range and efficiency. Choosing a higher-frequency unlicensed system (i.e., based on 2.4-GHz off-the-shelf hardware) brings disadvantages such as unacceptable sensitivity to noise, which is inherent on industrial, science, and medical (ISM) bands.

Choosing the Right Network Topology

Once the band was chosen, a decision had to be made about how information is routed from the meters to the reader. There are countless network types that can achieve this goal. However, making the right choice involved bal-ancing cost, reliability, complexity, and flexibility.

Sensor networks have an advantage over traditional master/client implementations, like global system for mobile communications (GSM) and wireless local area networks (WLANs). At some point, the wireless signal must be transformed from one network topol-ogy to another. In GSM and WLAN, each client always needs to be in range with its assigned base station at all times for frame delivery (see Figure 1). Even if a WLAN frame is destined for another node in the same wireless topology, the client forwards it to the access point for further routing, making things more complex.

In a sensor network, packet delivery is simplified, and delivery time is not always critical. Sensor networks are seldom real-time networks, as opposed to voice and partial LANs. Other network topologies can be implemented, which can break the master/client rela-tionship. One solution is the multi-hop dynamic net-work topology which WRS has implemented for its wireless metering solution (see Figure 2). Each node is aware of its neighboring nodes and makes routing decisions based on its known geographical position and knowledge about any access points that may exist throughout the network.

Using public networks saves time by providing a backbone infrastructure. Many products exist today that provide a modular interface to GSM function-ality. However, in the Nordic countries, consumers using more than 100,000 kWh of electricity per year are required to report power consumption every hour,

��

��

Figure 1. Master/Client Relationship





every day, all year around. This makes GSM solutions expensive with respect to network transport cost. Low equipment cost and reduced network transport cost is the key for using a sensor network.

Custom Hardware Solution

The multi-hop dynamic network topology is con-trolled by a software stack run by a microprocessor. In addition, RF processing is needed to take care of the wireless links. Unfortunately, few off-the-shelf RF chipsets provide digital radio support in the 60- to 90-MHz frequency band. Constrained by physical limits, and the demand for low cost and quick instal-lation, a system that balances RF discrete components and DSP functionality was built around an FPGA. The advantage of using an FPGA was that not only could the RF processing be performed, but the pro-cessor and software needed for the network control could also be integrated. Because Cyclone devices pro-vide a low-cost solution (zero up-front charges and the ability to prototype in the same platform used for production), this solution was selected for this appli-cation over competing ASIC technologies.

By using a Cyclone FPGA in WRS’ wireless metering system, most of the RF functionality has been moved from the analog domain in discrete components to the digital domain and processing within the FPGA.

The radio signal for transmission is digitally com-posed within the FPGA and created by the digital-to-analog converter (DAC). An amplifier then outputs the signal to the antenna at the system’s specified power. See Figure 3.

All of the RF processing could in theory be done within the FPGA. This solution would need high-speed converters which match the RF frequency. The FPGA would have to run at least the Nyquist frequency (twice the RF frequency = 180 MHz). Although pos-sible, this solution is impractical and would lead to heat dissipation levels and power consumption that is much too high. A down converter, or mixer, is instead used for handling the radio signal at a more appro-priate frequency, the intermediate frequency (IF). Figure 4 illustrates such a system and is the foundation for WRS’ last-mile communication for power metering.

Conclusion

By partitioning the RF system such that the FPGA takes the majority of the workload, it is possible to develop wireless products significantly faster than previously possible, taking advantage of parallel development. At WRS, our discrete radio design has hardly changed since the first revision saw daylight. However, updates to the RF DSP algorithms have caused several revisions of the FPGA configuration memory. This of course was no problem in this system, as a hardware change can be turned around in a matter of minutes. In addition, the ability to integrate a low-cost Nios® embedded processor into the Cyclone FPGA allowed a reduction in board area and had the added flexibility of allowing us to customize the processor and peripherals according to our control and network management needs. Wireless applications make extensive use of multiplication operations, and the introduction of Cyclone II devices takes this even further by providing embedded DSP functionality, thus freeing up valuable general logic for other purposes.

Using the low-cost Cyclone FPGA as a hardware plat-form has allowed our product to meet the aggressive price targets required in the power metering market, while avoiding the huge risks associated with an ASIC and of course with the added benefit of having upgrade-able hardware. The Cyclone series of FPGAs has enabled WRS to develop low-cost, wireless metering solutions which fulfill the demands for today’s metering needs.

��

��

��

��

��

��

��

��

��

��

��

��

��

Figure 2. Dynamic Routing in a Sensor Network

Figure 4. Digital RF Signaling & FPGA Contents

Access Point

��

��

��

��

Figure 3. Digital RF Signal Processing

Because Cyclone devices provide a low-cost solution (zero up-front charges and the ability to prototype in the same platform used for production), this solution was select-ed for this application over competing ASIC technologies.


Contributed Articles



By Rob IrwinManager, Brand StrategyAltium

The latest hot topic in the chip design world recently has been electronic system level (ESL) design. The idea of ESL design is to raise the level of abstrac-tion at which system designers can work. This higher abstraction is necessary to deal with the increasing complexity that occurs when designing processor-based systems. Dealing with this level of complexity at the register level is not practical because of the expo-nential blow-out in design and verification times that occur when working with fairly low-level primitives

While ESL tools and design methodologies are avail-able, they are not well understood by the majority of system designers and require the adoption of radically different design methodologies and the acquisition of completely new skills.

In a practical sense, board-level system designers have been working at a high level of abstraction for years. The complexity of gate-level or RTL design is to a large extent hidden by the use of large complex logic blocks in the form of off-the-shelf components. At the board level, the system designer only has to deal with the interconnection of the components and the interface between components. The underlying logic, which may entail many millions of gates, is effectively hidden inside the components.

The practical effect of this is that system designers can quickly build very complex applications without the need to resort to new design methods or schemas such as System C.

Board-level system design is not usually considered ESL design because the high level of abstraction offered by the component connection paradigm has not traditionally been applied to creating systems on a chip. At their core, however, the two concepts are trying to achieve the same thing, allowing designers to develop sophisticated systems without having to deal with gate or register-level complexity.

FPGAs: Softening System Hardware

FPGA technology has progressed to the point where vast capacity is available in devices priced in the tens of dollars range. The Altera® CycloneTM and the recently announced Cyclone II family are prime examples of this price advantage. The high capacity and low cost of these devices make them a perfect platform on which to build processor-based systems for production applications.

What makes FPGAs attractive as a system platform is their potential to bring the same level of freedom to hardware design that moving functions into software gave to developers when microprocessors became widely available. For development, the reprogram-mable nature of FPGAs is a boon, allowing hardware design changes to be made without inherent time and cost penalties. Additionally, hardware design changes can be made right up until the time the product goes out the door or even in the field. These luxuries cur-rently enjoyed on the software side of the develop-ment process, can now be extended to the hardware.

However, for the mainstream of engineers to be able to adopt and use these devices in numbers in system development, it will require the availability of a com-plete and integrated hardware and software solution that enables hardware design, software development, intellectual property (IP) block (component) inte-gration, verification, and debug in a cohesive and easy-to-use design environment. In other words, the same level of abstraction and design ease offered at the board-level must be available at the FPGA design level to system designers.

So from a device standpoint, the stage is set for mass adoption of FPGAs as a system development platform. What’s needed from a tools perspective is an FPGA design methodology that provides a high level of abstraction, but is accessible to the majority of engi-neers out there who are currently engaged in system design. The current crop of ESL tools may make some sense in the high non-recurring engineering (NRE) cost world of ASIC design, but they won’t act as the catalyst that brings embedded system design on an FPGA platform to the mainstream of engineers. The learning curve is too steep, and the risks too great.

Board Design at the Nano Level

Altium Limited, a leading developer of EDA and embedded development tools, recently released a design product called Nexar that brings a new approach to the problem of system development on FPGAs. Nexar allows engineers to approach system design on FPGAs using the skills and methodologies common in board-level design.

Central to Nexar’s approach is the inclusion of librar-ies of pre-synthesized, read-to-use components that can be wired together graphically in a schematic environment to create the system hardware. As well as generic logic blocks, Nexar includes high-level devices such as VGA controllers, CAN controllers, LCD drivers, as well as several microprocessor cores. These FPGA components have been pre-synthesized for a variety of target devices and are treated as ‘black boxes’ during synthesis.

Electronic System Level Design by Any Other Name...





The initial release of Nexar includes three 8-bit proces-sor cores that are instruction set compatible with the 8051, PIC 165 and Z80 respectively. On-Chip Debug (OCD) versions of the processor cores are comple-mented by the inclusion of full software development tool chains to enable coding and source-level debug-ging of the embedded software from within Nexar, allowing for integrated hardware and software design.

Another interesting feature of Nexar is the inclusion of a set of “virtual instruments,” such as logic analyz-ers, frequency counters/generators, and I/O blocks. Like the FPGA components, these virtual instruments are pre-synthesized and can be connected into the design at the schematic level. Once the design has been downloaded to Altium’s unique development board (the NanoBoard), the engineer can communi-cate with the instruments (and the processors) via a secondary “soft” JTAG chain, controlling the instru-ments with soft front panels on the connected PC.

These virtual instruments give the designer the ability to easily see inside the FPGA during system debug-ging, and allow for an interactive system development without the need to rely on simulation.

Accessibility is the Key

The combination of ready-to-use FPGA components, integrated software development, virtual instrumen-tation, and the versatile NanoBoard development platform, allows system developers to work at a high level of abstraction, while taking an interactive

approach to the design process, running real software on real hardware right from the start of the design cycle. Altium calls this interactive design method-ology LiveDesign (see Figure 1), and it provides a scalable environment in which to rapidly develop complex embedded systems on an FPGA platform in an intuitive and “hands-on” way. What’s more, Nexar provides a design methodology that is easily accessible to the mainstream of system designers.

This accessibility is in contrast to other chip-level ESL approaches, and is in harmony with the direction that FPGA device development itself is taking. As FPGA prices continue to tumble, the number of applica-tions that can benefit from system-level design on a programmable platform increases exponentially, and more engineers will need to be able to work in this design space. Nexar provides a migration path that takes advantage of system designers’ existing skills, rather than forcing them to learn completely new disci-plines. And this migration is essential for the potential of high-capacity, low-cost FPGA to be fully exploited as a system platform in mainstream products.

About the Author

Rob Irwin has a Bachelor of Engineering (Electrical) from the University of Sydney, Australia. He has over 20 years experience in the electronic design industry and currently holds the position of Manager, Brand Strategy at Altium Limited.

Figure 1. LiveDesign Methodology Flow



��

��

��

��

��

��

��

��

��

��

��

�

�

�

��

��

��

��

�

��



by Anil KhannaMentor Graphics

Achieving rapid timing closure is an emerging FPGA design challenge. Synthesis routines driven by knowl-edge of the physical layout of the target device achieve better results than those that perform logical synthe-sis. This article discusses the importance of perform-ing optimizations with the knowledge of the device’s topography, and analyzes physical synthesis usage with established flows such as floor planning.

Logic Synthesis Falls Short

In the ASIC/FPGA world, synthesis implies Boolean logic synthesis. There is more than one way to rep-resent a logical equation, and, when reduced, there might again be many ways to map an equation to cor-responding resources. The traditional FPGA synthesis approach is to first synthesize and then perform tech-nology mapping.

Cell delay was the dominant delay factor in older FPGAs, where traditional logic synthesis sufficed to achieve the timing requirements. Reducing the logic levels or the area that represented a function meant lower cell delay and thus timing was met. This formula does not extend to new FPGAs. Transistors shrink as Moore’s Law is validated every two years, which mandates a shift in focus from reducing cell delays to optimizing interconnect delays. In fact, net delays now regularly exceed 70 percent of the total delay in new designs!

Synthesis routines aimed at producing the most efficient circuit cannot guarantee better performance after place and route. Traditional synthesis tools estimate the route delay based on wire-load models and these numbers are calculated based on a net’s statistical estimated delay. Optimization decisions based on a wire-load estimate can result in timing-inefficient netlists. A significant amount of performance is still left on the table.

Synthesis Must Get Physical

Some synthesis algorithms are common to logical and physical synthesis. However, the same algorithms are more effective when performed with knowledge of the physical structure. Popular routines used by physi-cal synthesis tools are re-timing, register replication, re-synthesis, and placement optimization.

Re-timing moves registers in a synchronous circuit such that the register-to-register delay is balanced. Register re-timing is often accompanied by register replication (see Figure 1). Re-timing works favor-ably with the FPGAs’ register-rich architecture. With knowledge of the placement and interconnect delay values, the tool can place the resources of the re-timed circuit in optimal locations.

Register replication benefits from the ability to con-trol placement of replicated registers. Registers that fan out to different areas are improved by placing individual registers in each region. This improves on the typical approach of logic synthesis, which replicates solely on fan-out count. Delay estimates are calculated using knowledge of the FPGA’s architecture and available routing resources, enabling educated calculations of the new net delays.

Re-synthesis restructures logic based on physical requirements. Often, an optimal implementation of a logical structure becomes inefficient after place and route. During physical synthesis, any timing-critical logic is optimally restructured using knowledge of device topology.

Placement optimization is a simple push-button auto-mated flow that optimizes the logic and modifies the placement. FPGA vendor place-and-route tools use timing information to control placement. However, by operating only on critical timing paths, users can make local changes that significantly improve design performance. For example, the location of RAM blocks, multipliers, and internal logic is optimized.

Physical Synthesis Optimizes Complex FPGA Designs

Figure 1. Manually Replicating a Register





Technical Articles

Floor Planning Misconceptions

Consider a highly utilized design with many paths (involving several blocks) missing timing. The tradi-tional method was to use pre-place-and-route floor planning. Without immediate timing feedback, this technique becomes non-deterministic and results in painfully long iterations. This process can take months to meet timing goals. Moreover, the physical constraints created during floor planning cannot be reused later.

Physical synthesis is often misconstrued as a floor planner. Floor planning is a process aimed at handling large designs. Both tools are unique, and there are areas where users should exploit their capabilities in tandem. Users may use floor planning on sections of a design and run physical synthesis on the individual modules until performance is achieved. This “divide and conquer” approach coupled with the predictabil-ity saves design time.

Unified Data Model

Users get significant performance and analysis capa-bilities by tying register transfer level (RTL) synthesis to its physical counterpart. It is impossible to think of these two capabilities existing exclusive of each other. RTL and physical synthesis in a unified data model gives designers unprecedented flexibility. Unlike in stand-alone physical synthesis, the designer’s vis-ibility does not stop at the post-synthesis technol-ogy level. Instead, the designer is able to cross-probe all the way up to RTL. Users can perform timing analysis and extend this functionality to cross-probe between the timing report and the physical view (see Figure 2). This way, a bottleneck can be solved either at the RTL or physical level (by re-coding if neces-sary). Thus, users have significant control when ana-lyzing a design, be it at the RTL, constraint, technol-ogy, or physical level.

Summary

Physical synthesis is becoming accepted as a “must have” process in the overall FPGA design cycle. While all physical synthesis tools might seem to work the same, it is worthwhile to try to understand the inher-ent algorithms and capabilities of each tool. With the ability to efficiently synthesize and place a netlist, the core functionality of a tool (e.g., the Precision® Physical tool from Mentor Graphics) can be extended into other FPGA timing-closure methods. Doing so gives users better control and analysis of their complex designs.

Figure 2. Unified Data Model Eases Cross Probing




Technical Articles

Stratix GX Devices: The Total Solution for PCI Express

PCI Express is poised for rapid adoption as the inter-connect of choice throughout the electronics industry. Today, PCI Express is establishing its initial presence in PCs, with systems available now that feature PCI Express-based graphics components. PCI Express adapter cards featuring networking, storage, and other functions are expected shortly. The reason behind this rapid adoption of PCI Express in the PC industry is the higher data bandwidth requirements of today’s PCs. It is no longer possible to service the high volumes of data processed by 3-GHz processors using parallel buses like conventional PCI. PCI Express is a serial, serializer/deserializer (SERDES) based interconnect providing much higher bandwidth than parallel buses. Adoption of PCI Express is not limited to PCs. Other industries have already adopted SERDES-based inter-connects for a wide range of applications. However, there is no clear winner among standards-based serial protocols that include XAUI and the Serial RapidIOTM standard. PCI Express can leverage its success in PCs to become the standard SERDES-based interconnect for these applications. Altera’s Stratix® GX device family (featuring SERDES technology that supports PCI Express, in addition to XAUI, the Serial RapidIO standard, and other SERDES-based serial interfaces) is an attractive solution as designers migrate their designs to PCI Express.

At the virtual level, PCI Express provides a system interface that is a superset of the existing PCI stan-dards, allowing backwards software compatibility with previous revisions of the specification. End users will be able to unplug a traditional PCI card and replace it with a PCI Express Cardalthough not in the same socketand expect the card to operate in the same way, only faster. Below the software layer, the protocol consists of three sublayers: transaction, data link, and physical. Figure 1 shows the PCI Express protocol stack.

Physical Layer

The PCI Express protocol specifies the use of clock- data-recovery-based transceiver technology to pro-vide the lane interface between devices. Each device port can support multiple lanes aligned together in a link to prove the physical connection and data path between two PCI Express devices. In its basic form, this is a single-lane solution, which at 2.5 gigabits per second (Gbps), is equivalent in bandwidth to a stan-dard 32-bit/66-MHz PCI implementation with each PCI Express lane using four pins instead of a PCI bus’s 48 pins. The PCI Express protocol implements 8b/10b encoding. This is used to support self-clocking data by guaranteeing transitions in the data path, as well as to enable control characters for framing, rate matching, and lane alignment.

The physical interface can be further subdivided into 3 blocks: physical medium attachment (PMA), physical coding sub-layer (PCS), and multiply- accumulator (MAC)similar to other protocols, such as Ethernet. Each block is responsible for successful data transfer:

n PMA is responsible for serializing/deserializing the data, serial transmission, and reception and frame alignment at the receiver

n PCS is responsible for 8b/10b encoding/decoding and rate matching between the recovered clock domain and the system domain

n MAC is responsible for lane alignment and overall transmitter and receiver control state machines

��

��

��

��

��

��

��

��

��

��

Figure 1. PCI Express Protocol Stack



Technical Articles


Technical Articles

The Stratix® GX architecture fully implements the PMA block within the transceivers. The majority of the PCS and MAC functionality is performed in FPGA fabric, to allow for some subtleties in the PCI Express specification, which have not been imple-mented in other protocols.

The high-speed signaling required by the PCI Express protocol can provide some board layout challenges, particularly if the product is to be used in a non- standard chassis. The dynamic transmit pre-empha-sis (or de-emphasis as stated in the PCI Express Specification) and receive equalization helps to overcome any problems, provided good board layout techniques have been observed.

The transceivers also offer a low-power solution, with each full duplex endpoint requiring only 175 mW. This is extremely important for the PCI Express environment because transceivers are often close to backplanes, where cooling is both expensive and difficult to implement.

Data Link Layer

The data link layer interfaces between the transac-tion layer and the MAC and is responsible for packet priority and data integrity. The transmit side takes the data from the transaction layer, orders it for transmission, and generates a cyclic redundancy code (CRC). If required, it will also copy the contents into the retry buffer for retransmission, should the pro-cess fail. The receiver side takes the data and checks for corruptions, retransmitting if necessary. The Stratix GX FPGA architecture can be used to implement the layer, while the TriMatrixTM memory blocks are used to provide the buffers needed to store retry packets.

Transaction Layer

The transaction layer is responsible for taking the various types of data transaction and prioritizing them into virtual containers for transmission. The PCI Express protocol allows for between one and eight virtual containers for prioritizing transactions. The transaction layer requires buffer memory for prioritizing and storing data ready for transmission. These buffers can again be implemented within the Stratix GX TriMatrix memory. The architecture allows for scalability, depending on the number of virtual containers to be supported, lane count and packet size, all of which can be selected when generating a core.

Total Solution

Stratix GX devices provide a total solution for PCI Express architecture. Altera Megafunction Partners Program (AMPPSM) members, Mentor Graphics and PLDA have intellectual property (IP) solutions avail-able today to provide full support for PCI Express. In addition, Altera has recently demonstrated working solutions at the PCI-SIG and successfully interoperat-ed with Intel chipsets. Figure 2 shows an eye diagram taken at the recent PCI-SIG testing. The eye is taken with spread spectrum clocking enabled. Full details are available in the characterization report.

Altera also provides collateral to support board lay-out. Tools include board layout guidelines, Gerber files, and schematics from the Stratix GX develop-ment boards and secure server network (SSN) guide-lines. Altera has also partnered with leading EDA partners, Mentor Graphics and Cadence, to provide board simulation design kits. This helps to model the board design, allowing the layout engineer to find problems before committing to the printed circuit board (PCB).

Conclusion

PCI Express is emerging as a lead protocol for next- generation backplane architectures, led by the PC industry. Capable of supporting PCI Express today, Stratix GX devices offer a low-risk path because the devices are pre-characterized to meet the protocol, and device flexibility allows the user to modify designs while the protocol is in flux. Altera and its partners provide a variety of tools to help simplify design and ensure customers can get to market early.

Figure 2. PCI Express Eye Diagram from PCI-SIG Testing

Overall Result: Pass Data Rate: 2.499787 GbpsData Rate Pass Median to Peak Jitter: 62.832618 psMedian to Peak Jitter Pass Peak to Peak Jitter: 105.778067 ps Peak to Peak Jitter Pass Eye Violations: 0 pointsEye Test Pass


Technical Articles


Technical Articles

Quartus II Offers Unmatched Flexibility with Advanced Scripting Technology

The Quartus® II software features a rich graphical user interface (GUI) that supports simple to complex design flows. However, many designers prefer to use a command-line interface or to create custom scripts to control their design flow. The Quartus II software pro-vides the easiest to use and most powerful environment available for command-line operation and tool com-mand language (Tcl) scripting from an FPGA vendor. This article provides a high-level overview of Quartus II command-line operation and Tcl scripting support and lists resources for more information.

Benefits of Command-Line Operation & Scripting Support

Each stage of the Quartus II design flow has a corre-sponding executable file that can be run from the GUI or from the command line. Many of these executable files also support industry-standard Tcl scripting to add in custom functionality or processing, beyond what is offered in the GUI. The easiest way to remem-ber the benefits of command-line operation and scripting support is to use the acronym CAR:

n Custom Analysis

n Automation

n Reproducibility

For example, building a script to perform custom analysis allows you to build in test procedures and then change design processing based on test results. Scripts can be used to automate design flows to per-form repetitive tasks, launch multiple compilations on multiple computers simultaneously, and to easily archive and restore projects. Reproducibility means that scripts can ensure the same project set up and assignments are used for every compile, even when a project is transferred from one engineer to another. Scripts can also be thought of as another level of design documentation.

Quartus II Command-Line Operation Support

Use command-line operation for scripting simple design flows, compiling existing projects, assigning global project assignments, and/or incorporating third-party EDA executable files.

Commands for Quartus II executable files can also be grouped together into a script or batch file or in a make file to automate design flows. Quartus II com-mand-line executable files accept arguments to make project settings and access common settings.

Batch File Example

The batch file example, shown in Figure 1, runs a simple compilation flow. The quartus_map execut-able uses Quartus II integrated synthesis to per-form synthesis on the design targeting a Stratix® EP1S10B672C6 device. The quartus_fit executable performs a timing driven compilation with an fMAX constraint of 100 MHz. The quartus_asm executable takes the output netlist from the quartus_fit execut-able and generates Programmer Object File (.pof)/SRAM Object File (.sof) programming configuration files. The quartus_tan executable is used to perform timing analysis on the design.

For more information on the Quartus II software’s command-line operation features and how to create batch files or make files, refer to the Command Line Scripting chapter of the Quartus II Software Handbook.

Quartus II Tcl Scripting Support

Use Tcl scripting for solving complex analysis, indi-vidual assignments, parsing and generating custom reports, and creating custom solutions.

Tcl is an EDA industry-standard scripting language used by Synopsys, Mentor Graphics, Synplicity, Altera, and others. The Tcl language provides support for control structures, variables, procedures, network socket access, and application programming interfaces (APIs).

Altera’s Tcl support is aligned with major EDA ven-dor solutions by using an API format similar to the Synopsys design constraint (SDC) format used by the Synopsys PrimeTime and Design Compiler products. Quartus II Tcl commands are grouped in Tcl packages that are loaded on demand to reduce runtime memory of executable files when the commands are not needed. Table 1 on page 38 lists the available packages and the types of commands available in each package.

Figure 1. Batch File Example



Technical Articles


Altera News

New Project Tcl Example

The following example uses Tcl to create and open a new project, create global assignments and a location assignment, and compile the project using the flow package. See Figure 2.

For more information on the Tcl language and Quartus II software’s Tcl command API, refer to the Tcl Scripting chapter of the Quartus II Handbook.

Getting Started

When using the Quartus II GUI to make assignments or run compilations, equivalent command-line syntax is pro-vided in the message window as a reference. Table 2 shows the resources and documentation that are also available:

Additional command-line operation and Tcl scripting on-line training and documentation are scheduled to be added to the Altera web site in the second half of 2004.

Conclusion

By allowing customers to use the command line and scripting features to operate the Quartus II software, customers get unmatched flexibility and control over their design process. This article only scratches the surface of what you can do using the command-line operation and Tcl. For more information, refer to the listed resources in Table 2.

Table 1. Tcl Commands Grouped in Packages by Function

Package Name Package Description

project Create and manage projects and revi-sions and make any project assign-ments including timing assignments

flow Compile a project, run command-line executables and other common flows

report Get information from report tables and create custom reports

timing Annotate timing netlist with delay information, compute and report tim-ing paths

timing_report List timing paths

advanced_ timing Traverse the timing netlist and get information about timing nodes

device Get device and family information from the device database

backannotate Back annotate assignments

logiclock Create and manage LogicLockTM regions

chip_editor Identify and modify resource usage and routing with the Chip Editor

simulator Configure and perform simulations

database_manager Manage version-compatible database files

misc Perform miscellaneous tasks

Figure 2. Tcl New Project Example

Table 2. Quartus II Resources & Documentation

Resource Description User Level

Quartus II Online Demonstrations (www.altera.com)

Three to four minute video demonstration of the Quartus II soft-ware command-line operation and scripting features.

All Levels

Introduction to Quartus II Manual (www.altera.com)

Beginning to Intermediate

Scripting and Constraint Entry section of the Quartus II Handbook (www.altera.com)

Detailed instruc-tion.

Beginning to Advanced

Qhelp: Included with the Quartus II soft-ware. Run quartus_sh –qhelp from the command line.

Detailed listing of all command-line executable files and Tcl commands including usage examples.


Enhance Your Design Flow With Scripting TechOnline WebCast (www.altera.com)

Overview of Quartus II com-mand-line opera-tion and scripting support

Beginning to Intermediate

Design examples (www.altera.com)

Located in the support center on the Altera web site


Recorded on-line train-ing (www.altera.com)

Detailed instruc-tion examples

Beginning to Advanced (coming soon)


Technical Articles


Altera News

Altera Introduces Find Answers: Putting Collective Knowledge to Work for Web Customer Service

The new self-support tool, Altera’s Find Answers, powered by Primus Knowledge Solutions uses natural language processing (NLP) technology to analyze the meaning and context of your questions. When you type a natural language question, Find Answers analyzes the usage context, parts of speech, and other language characteristics to match the question to available content, and returns the most rel-evant answer with the matching text highlighted inside the document. Unlike simple search engines that return lists of documents in response to keyword queries, Altera’s Find Answers delivers the actual answer.

In simple terms, Altera’s Find Answers is able to provide answers to inquiries in corporate databases and documents. Corporate-wide information is now within easy reach of customers, employees, and part-ners using the new self-support option.

The benefits include:

n Ask Questions using Plain Text: Find Answers’s NLP technology analyzes the context of your natural language question, as well as the context of the available content, so you do not have to use the exact words.

n Better Answers Faster: See answers immediately and get the information you need in fewer clicks than with a traditional search engine. Instead of getting a list of document titles and then opening each file to find the answer, you get the actual answer.

n Browse to Find Answers: If you do not know exactly what you are looking for, you can still find answers by browsing the left navigation.

n The Best Results for Customer’s Needs: See the answer summary in the results list to determine which will best suit your needs. View whether the answer is from a recently updated file, a brief product fact sheet, or a detailed product manual. Because the size of the document is also presented, you can make a decision whether or not to open a large PDF prior to downloading.

n Multiple Search Options Available: Multiple search tools are provided including natural language, keyword, wildcard, and Boolean. You can use these tools individually or combined to find the exact information you want.

n Continuous Refinements to the Lexicon: You will not need to know the “right” words to use in a question. The lexicon is the database of knowledge about word meaning that the system uses to distinguish among word senses, and relates the senses of different words that have similar meaning.

You can now search Altera technical information whenever you want using the Altera® Toolbar (see Figure 1). The toolbar benefits include:

n Instant access to the Altera Support Center from anywhere on the web

n Your questions are saved in the search history; re-run them with a single click

n Fast access to www.altera.com from any site

n Easy updates: automatic or on command, no re-installation required

You can download the Altera toolbar at http://answers.altera.com/altera/toolbar

Another self-support option is Altera troubleshoot-ers, which are web-based interactive tools that allow you to follow a diagnostic tree and resolve a problem, without having to speak to an Applications Engineer. The Altera Customer Applications group has identi-fied a number of areas where technical problems and questions frequently arise. To make it easier for you to debug these problems, a number of troubleshooters were created.

These troubleshooters work by asking various ques-tions about setup and the problem at hand, then suggesting various actions to take to solve the prob-lem. These tools are useful during the process of debugging designs and systems and are available on the Altera web site at www.altera.com/support/kdb/troubleshooter/ts-index.html.

Figure 1. Altera Find Answers Toolbar


Altera News


Altera News

Subscribe to any of Altera’s email-based e-newsletters and you will be entered into a drawing to win an iPod mini, Apple’s very cool 1,000 song player for use with Macs or Windows PCs.

www.altera.com/subscribe

Stay current on the latest news about Altera’s FPGAs, CPLDs, structured ASICs, software, and intellectual property (IP) with:

n Inside Edge, Altera’s Monthly e-NewsletterGet all the news each month about Altera’s products, solutions, and more.

n Net Seminar e-NewsletterStay current on Altera’s leading-edge solutions with this monthly calendar of upcoming and archived net seminars.

n Code:DSP e-NewsletterReceive this quarterly update on Altera’s comprehensive digital signal processing (DSP) solutions for implementing reconfigurable DSP designs in leading-edge FPGAs.

Subscribe to Altera’s Free e-Newsletters & Enter to Win an iPod Mini


Altera News


Altera News

Upcoming Events

Table 1. Upcoming Events Calendar

Date Event Name Location Altera Presence

October 3-6, 2004 IEEE Custom Integrated Circuits Conference (CICC)

Orlando, FL Presenting Paper

October 14, 2004 SOPC World Taiwan Hsinchu, Taiwan Altera-Sponsored Seminar

October 18, 2004 SOPC World Shanghai Shanghai, China Altera-Sponsored Seminar

October 18, 2004 Mentor EDA Tech Forum San Jose, CA Booth

October 18-20, 2004 Convergence 2004 Detroit, MI Booth 233

October 19-21, 2004 Network System Design Conference San Jose, CA Panel Participation

October 21, 2004 SOPC World Shenzhen Shenzhen, China Altera-Sponsored Seminar

October 25, 2004 SOPC World Beijing Beijing, China Altera-Sponsored Seminar

October 27, 2004 SOPC World Korea Seoul, Korea Altera-Sponsored Seminar

October 27, 2004 SOPC World 2004 Santa Clara, CA Altera-Sponsered Seminar

October 29, 2004 PLD World 2004 Tokyo, Japan Altera-Sponsored Seminar/Exibition

November 3, 2004 SOPC World India Bangalore, India Altera-Sponsored Seminar

November 4, 2004 SOPC World 2004 Boston, MA Altera-Sponsored Seminar

November 4, 2004 SOPC World Italy Milan, Italy Altera-Sponsored Seminar

November 5, 2004 PLD World 2004 Osaka, Japan Altera-Sponsored Seminar/Exibition

November 9-10, 2004 Denali MemCon San Jose, CA Booth

November 15-17, 2004 SDR Forum Phoenix, AZ Booth, Presenting Paper

November 29-December 3, 2004

GlobeCom 2004 Dallas, TX Presenting Paper

Altera takes part in and sponsors a wide variety of trade shows, seminars, and conferences on an ongoing basis. Table 1 lists upcoming events. For more information, visit www.altera.com.

Alte

ra F

PGA

Mat

rix:

New

Dev

ices

Alte

ra F

PGA

Mat

rix:

New

Dev

ices

Strat

ix II

(1.2

V)Hi

gh D

ensit

y, Hi

gh P

erfo

rman

ceCy

clone

II (1

.2 V

)Lo

w Co

st, H

igh Vo

lume

Ada

ptiv

e Lo

gic

Mod

ules

(ALM

s)6,

240

13,5

5224

,176

36,3

8453

,016

71,7

60—

——

——

—

Ada

ptiv

e Lo

ok-U

p Ta

bles

(ALU

Ts)

12,4

8027

,104

48,3

5272

,768

106,

032

143,

520

——

——

——

Logi

c El

emen

ts (L

Es)1

15,6

0033

,880

60,4

4090

,960

132,

540

179,

400

4,60

88,

256

18,7

5233

,216

50,5

2868

,416

Tota

l RA

M B

its (K

)241

91,

370

2,54

44,

520

6,74

89,

383

120

166

240

484

594

1,15

2

M51

2 RA

M B

lock

s (5

12 b

its +

64

pari

ty b

its)

104

202

329

488

699

930

--

--

--

M4K

RA

M B

lock

s (4

Kbi

ts +

512

par

ity b

its)3

7814

425

540

860

976

826

3652

105

129

250

M-R

AM

Blo

cks

(512

Kbi

ts +

65,

536

pari

ty b

its)3

01

24

69

——

——

——

Spee

d G

rade

s (fa

stes

t to

slow

est)

-3, -

4, -

5-3

, -4,

-5

-3, -

4, -

5-3

, -4,

-5

-4, -

5-4

, -5

-6, -

7, -

8-6

, -7,

-8

-6, -

7, -

8-6

, -7,

-8

-6, -

7, -

8-6

, -7,

-8

Ava

ilabl

e Em

bedd

ed P

roce

ssor

Nio

s® II

Nio

s II

Nio

s II

Nio

s II

Nio

s II

Nio

s II

Nio

s II

Nio

s II

Nio

s II

Nio

s II

Nio

s II

Nio

s II

DSP

Blo

cks

1216

3648

6396

——

——

——

18x1

8-bi

t /

9x9-

bit

Embe

dded

Mul

tiplie

rs48

/ 9

664

/ 1

2814

4 /

288

192

/ 38

425

2 /

504

384

/ 76

813

/ 2

618

/ 3

626

/ 5

235

/ 7

086

/ 1

7215

0 /

300

I/O

Reg

iste

rs p

er I/

O E

lem

ent

66

66

66

33

33

33

True

Dua

l-Po

rt R

AM

Glo

bal &

Reg

iona

l Clo

ck N

etw

orks

4848

4848

4848

88

1616

1616

Phas

e-Lo

cked

Loo

ps (P

LLs)

/Uni

que

Out

puts

6 /

286

/ 28

12 /

56

12 /

56

12 /

56

12 /

56

2 /

62

/ 6

4 /

124

/ 12

4 /

124

/ 12

Des

ign

Secu

rity

4

Har

dCop

y™ D

evic

es S

uppo

rtTB

DTB

D—

——

——

—

Conf

igur

atio

n Fi

le S

ize

(Mbi

ts)

510

1728

4053

11.

84

7.1

10.9

14.8

Num

ber

of E

PCS1

Dev

ices

(1 M

bit)

——

——

——

1—

——

——

Num

ber

of E

PCS4

Dev

ices

(4 M

bits

)1

——

——

—1

11

——

—

Num

ber

of E

PCS1

6 D

evic

es (1

6 M

bits

)1

11

——

—1

11

11

1

Num

ber

of E

PCS6

4 D

evic

es (6

4 M

bits

)1

11

11

11

11

11

1

Num

ber

of E

PC2

Dev

ices

(1.6

Mbi

ts)

24

711

1621

11

24

57

Num

ber

of E

PC4

Dev

ices

(4 M

bits

)1

——

——

—1

11

——

—

Num

ber

of E

PC8

Dev

ices

(8 M

bits

)1

1—

——

—1

11

11

—

Num

ber

of E

PC16

Dev

ices

(16

Mbi

ts)

11

1—

——

11

11

11

I/O

Vol

tage

Lev

els

Supp

orte

d1.

5V, 1

.8V,

2.5

V, 3

.3V

1.5V

, 1.8

V, 2

.5V,

3.3

V

I/O

Sta

ndar

dsLV

DS,

LV

PECL

, Hyp

erTr

ansp

ort,

Dif

fere

ntia

l SST

L-18

(I &

II),

Dif

fere

ntia

l SST

L-2

(I &

II),

1.

5-V

Dif

fere

ntia

l HST

L (I

& II

), 1.

8-V

Dif

fere

ntia

l HST

L (I

& II

), SS

TL-1

8 (I

& I

I),

SSTL

-2 (I

& I

I), 1

.5-V

HST

L (I

& I

I), 1

.8-V

HST

L (I

& I

I), P

CI, P

CI-X

1.0

, LV

TTL,

LV

CMO

S

LVD

S, R

SDS,

Min

i-LV

DS,

LV

PECL

, Dif

fere

ntia

l SST

L-18

(I &

II),

Dif

fere

ntia

l SST

L-2

(I &

II),

1.5-

V D

iffe

rent

ial H

STL

(I &

II),

1.8

-V D

iffe

rent

ial H

STL

(I &

II),

SSTL

-18

(I &

II),

SS

TL-2

(I &

II),

1.5-

V H

STL

(I &

II),

1.8-

V H

STL

(I &

II),

PCI,

PCI-

X 1

.0, L

VTT

L, L

VCM

OS

Exte

rnal

Mem

ory

Dev

ice

Inte

rfac

esQ

DRI

I, D

DR2

, RLD

RAM

II,

DD

R, S

DR

QD

RII,

DD

R2, D

DR,

SD

R

True

-LV

DS™

Max

imum

Dat

a Ra

te (M

bps)

1,00

01,

000

1,00

01,

000

1,00

01,

000

——

——

——

True

-LV

DS

Chan

nels

(Rec

eive

/Tra

nsm

it)38

/ 3

858

/ 5

880

/ 8

411

4 /

118

152/

156

152

/ 15

6—

——

——

—

Med

ium

-Spe

ed L

VD

S D

ata

Rate

(Mbp

s) (R

ecei

ve/T

rans

mit)

——

——

——

805

/622

805

/622

805

/622

805

/622

805

/622

805

/622

Med

ium

-Spe

ed L

VD

S Ch

anne

ls—

——

——

—55

7512

520

019

227

5

RSD

S D

ata

Rate

(Mbp

s)—

——

——

—17

017

017

017

017

017

0

Min

i-LV

DS

Dat

a Ra

te (M

bps)

——

——

——

170

170

170

170

170

170

Embe

dded

Dyn

amic

Pha

se A

lignm

ent

(DPA

) Cir

cuitr

y—

——

——

—

Seri

es &

Dif

fere

ntia

l On-

Chip

Ter

min

atio

n—

——

——

—

Prog

ram

mab

le D

rive

Str

engt

h

Not

es: 1 F

or S

trat

ix I

I, th

e va

lues

rep

rese

nt t

he n

umbe

r of

equi

vale

nt lo

gic

elem

ents

(1 A

LM =

2.5

LEs

); 2 K

=1,0

00; 3 K

bit=

1,02

4 bi

ts; 4 D

esig

n Se

curi

ty f

or C

yclo

ne II

ava

ilabl

e w

ith M

AX

® II

conf

igur

atio

n so

lutio

n

I/O Features Density & Speed

EP2S15

EP2S30

EP2S60

EP2S90

EP2S130

EP2S180

ArchitecturalFeatures & Other

Configuration Devices

EP2C5

EP2C8

EP2C20

EP2C35

EP2C50

EP2C70

| 43

Alte

ra F

PGA

Mat

rix:

New

Dev

ices

Alte

ra F

PGA

Mat

rix:

Prod

uctio

n D

evic

es

Dev

ice

Ava

ilabl

e N

ow in

Com

mer

cial

(0 to

85º

C) &

In

dustr

ial (

-40

to 1

00º C

) Tem

pera

ture

s.D

evic

e A

vaila

ble

Now

in C

omm

erci

al Te

mpe

ratu

re;

Con

tact

Alte

ra fo

r Ind

ustri

al Te

mpe

ratu

reVe

rtica

l Mig

ratio

n (S

ame

V CC, G

ND

, ISP

& In

put P

ins)

��

��

��

��

��

��

��

��

��

�

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

�(1

)

��

��

��

��

�

��

��

(1)

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

�

�� (

1)��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

Alte

ra F

PGA

Mat

rix:

New

Dev

ices

Alte

ra F

PGA

Mat

rix:

Prod

uctio

n D

evic

es

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

�

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

Nio

s® II

Nio

s II

Nio

s II

Nio

s II

Nio

s II

Nio

s II

Nio

s II

Nio

s II

Nio

s II

Nio

s II

Nio

s II

Nio

s II

Nio

s II

Nio

s II

Nio

s II

Nio

s II

Nio

s II

Nio

s II

Nio

s II

��

��

6��

��

��

��

��

��

��

��

��

�

��

��

��

��

��

��

��

24 /

4840

/ 80

40 /

8048

/ 96

56 /

112

72 /

144

88 /

176

24 /

4824

/ 48

40 /

8040

/ 80

40 /

8056

/ 11

256

/ 11

2�

��

��

��

�6

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

�

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

�

��

��

��

��

��

��

��

��

��

��

��

��

��

�

��

��

��

��

��

��

��

��

��

��

��

��

��

��

�

��

��

��

��

��

��

��

��

��

��

��

��

��

�

��

��

��

��

��

��

��

��

��

��

��

��

��

�

��

��

��

��

��

��

��

��

��

��

��

��

��

�

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

�

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

�

��

��

��

��

��

��

��

��

��

��

��

��

�

��

��

��

��

��

��

�

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

Core Voltage & I/O Options Density & Speed ConfigurationDevices

Architectural Features & Other

| 45

Alte

ra F

PGA

Mat

rix:

Prod

uctio

n D

evic

es

Alte

ra C

PLD

Mat

rix

Dev

ice

Ava

ilabl

e N

ow in

Com

mer

cial

(0 to

85º

C) &

Indu

stria

l (-4

0 to

100

º C) T

empe

ratu

res.

Dev

ice

Ava

ilabl

e N

ow in

Com

mer

cial

Tem

pera

ture

; C

onta

ct A

ltera

for

Indu

stria

l Tem

pera

ture

.

Verti

cal M

igra

tion

(Sam

e V

CC, G

ND

, ISP

& In

put P

ins)

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

�

��

��

��

��

��

��

��

��

��

�

��

��

��

��

��

�

��

��

��

��

��

��

�

��

��

��

��

��

�

��

��

��

��

��

�

��

��

��

��

��

��

��

��

��

��

�

��

��

��

��

��

��

��

��

�

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

Alte

ra F

PGA

Mat

rix:

Prod

uctio

n D

evic

es

Alte

ra C

PLD

Mat

rix

Dev

ice

Ava

ilabl

e in

Com

mer

cial

Tem

pera

ture

. C

onta

ct A

ltera

for

Indu

stria

l Tem

pera

ture

.

Dev

ice

Ava

ilabl

e in

Com

mer

cial

& In

dustr

ial

Tem

pera

ture

s.

Dev

ice

Ava

ilabl

e in

Com

mer

cial

& In

dustr

ial,

and

Qua

lifie

d to

Ext

ende

d Te

mpe

ratu

res.

Num

ber

Indi

cate

s A

vaila

ble

Use

r I/

O P

ins.

Verti

cal M

igra

tion

(Sam

e V c

c , G

ND

, ISP

, &

Inpu

t Pin

s)

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

�

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

�

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

�

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

� ��

��

��

��

��

��

��

��

��

��

��

� ��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

�

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

�

��

��

��

��

��

��

��

��

��

� ��

��

� ��

� ��

� ��

��

��

� ��

��

��

� ��

� ��

��

��

� ��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

�2 �

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

| 47

Alte

ra C

PLD

Mat

rix

Alte

ra P

acka

ging

Dim

ensi

ons

� ��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

� ��

��

��

��

��

�

��

��

��

��

��

��

�

��

� � �

� �

� �

� �

��

��

��

��

�

��

�

� �

��

��

��

��

��

��

��

�

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

�

��

�

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

Alte

ra C

PLD

Mat

rix

Alte

ra P

acka

ging

Dim

ensi

ons

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

0.80

9.00x9.00

32

0.50

16.00x16.00

100

0.50

22.00x22.00

144

10.03x10.03

1.2716

5.00x6.00

1.278

12.00x12.00

0.8044

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

0.8049

7.00x7.00

0.80

169

11.00x11.00

0.80

11.00x8.00

88

11.00x11.00

1.00

100

1.00

144

13.00x13.00

1.00

256

17.00x17.00

1.00

324

19.00x19.00

1.00

400

21.00x21.00

1.00

672

27.00x27.00

1.00

780

29.00x29.00

1.00

1,020

33.00x33.00

1.00

896

31.00x31.00

484

23.00x23.00

1.00

1.00

1,508

41.00x41.00

��

��

��

��

��

D1(mm)xE1(mm)

Pitch(mm)

PinCount

D1

E1

PinCount

D

E

D(mm)xE(mm)

Pitch(mm)

��

��

| 49

Alte

ra P

acka

ging

Dim

ensi

ons

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

0.50

34.60x34.60

240

(PQFP

orRQFP)

0.50

42.60x42.60

304

(RQFP)0.50

30.60x30.60

208

(PQFP

orRQFP)

0.65

17.20x23.20

100

(PQFP)

0.65

18.30x24.30

100

(EPC8&EPC16)

(PQFP)

0.65

31.20x31.20

160

(PQFP)

0.80

13.20x13.20

44(PQFP)

SG-PCKGMTRX-2.0

Copyright2004AlteraCorporation.Allrightsreserved.Altera,TheProgrammableSolutionsCompany,thestylizedAlteralogo,specificdevicedesignations,andallotherwordsandlogosthatareidentifiedastrademarksand/orservicemarksare,unlessnotedothewise,

thetrademarksandservicemarksofAlteraCorporationintheU.S.andothercountries.Allotherproductorservicenamesarethepropertyoftheirrespectiveholders.AlteraproductsareprotectedundernumerousU.S.andforeignpatentsandpendingapplications,mask

workrights,andcopyrights.Thisdocumentissubjecttochangewithoutnotice.

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

1.27

256

27.00x27.00

1.27

356

35.00x35.00

724

35.00x35.00

1.27

672

35.00x35.00

1.27

40.00x40.00

956

1.27

600/652

45.00x45.00

1.27

��

��

��

��

��

SG-PCKGMTRX-2.0

Copyright2004AlteraCorporation.Allrightsreserved.Altera,TheProgrammableSolutionsCompany,thestylizedAlteralogo,specificdevicedesignations,andallotherwordsandlogosthatareidentifiedastrademarksand/orservicemarksare,unlessnotedothewise,

thetrademarksandservicemarksofAlteraCorporationintheU.S.andothercountries.Allotherproductorservicenamesarethepropertyoftheirrespectiveholders.AlteraproductsareprotectedundernumerousU.S.andforeignpatentsandpendingapplications,mask

workrights,andcopyrights.Thisdocumentissubjecttochangewithoutnotice.

Alte

ra P

acka

ging

Dim

ensi

ons

��

��

��

��

��

��

��

��

��

��

��

The Cyclone™ family has taken the industry by storm. Already shipping tothousands of customers and available in high volume, the Cyclone familyoffers the ideal combination of cost, density, features, and performance for a wide range of volume-driven applications. Cyclone devices are the lowest-cost FPGAs ever, making them a compelling alternative to ASICs for high-volume designs.

When you need a company to rely on, Altera delivers. Forhigh performance, fast time-to-market, and a price that willblow you away, contact us today at www.altera.com/cyclone.

The lowest-cost FPGAs ever.

®

The Programmable Solutions Company®

www.altera.com/cyclone

Delivering everywhere in volume.

Copyright © 2004 Altera Corporation. All rights reserved. Altera, The Programmable Solutions Company, the stylized Altera logo, specific device designations, and all other words and logosthat are identified as trademarks and/or service marks are, unless noted otherwise, the trademarks and service marks of Altera Corporation in the U.S. and other countries. All other product or service names are the property of their respective holders. Altera products are protected under numerous U.S. and foreign patents and pending applications, mask work rights, and copyrights.

Delivering everywhere in volume.

Third Quarter 2004 Newsletter for Altera...

Documents

Transcript of Third Quarter 2004 Newsletter for Altera...