Design Challenges: Avoiding the Pitfalls, winning the game - Xilinx

More documents

Recommendations

Info

SYSTEM PERFORMANCE PLB PowerPC APU I/F APU Control Hard Processor Block Soft Auxiliary FPGA Processor Interface OCM FPGA Fabric Figure 2 – Virtex-4 FX APU “co-processing” and use the intelligent tools to build a direct connect from the embedded PowerPC cores to high-performance FPGA fabric, where hardware accelerator functions can operate as extensions to the PowerPC. As shown in Figure 2, you can improve the overall system performance by offloading computationally demanding applications from the main CPU. By its very nature, FPGA hardware fabric is parallel in structure and can be used to accelerate system functions orders of magnitude faster than clocking methods can provide. In this example, the PowerPC core is complemented by an APU (Auxiliary Processor Unit), which inter- Figure 3 – XPS performance analysis views faces to a parallel soft processor that can handle applications such as data processing, floating-point mathematics, and video processing. This direct connection provides a high-bandwidth, low-latency solution with parallel advantages over other multi-core processor and arbitrated busing solutions. Performance Analysis Do you need to find out where your performance is lost in your design? Embedded software debugging and analysis is always a bit of a challenge because code execution is often “invisible” to you. On paper, your design looks like it meets specifications, but when running in realtime hardware with asynchronous interrupts and real-world situations, you find that often you don’t meet your own performance requirements. Now is the time when intelligent tools can provide you with a unique view inside the operating device rather than leave you guessing outside of a black box. Version 7.1 of Xilinx Platform Studio introduces a series of performance analysis tools and views that provide great insight as to how your software is actually executing and where performance is leaking away from you (Figure 3). By knowing which software functions take up the most execution time and which functions call other functions – as well as the number of times called – you can get an illuminating view of exactly how your embedded design is running. Functions that take a long time to execute, or functions that are called a large number of times by other routines, may be excellent candidates to accelerate by moving them to parallel hardware as co-processing extensions. Figure 3 also shows that if the tools track and display your software execution clearly, you can quickly and easily identify areas that could be more efficient. This can save a lot of what-if experiment scenarios that are time-consuming and often result in relatively small performance improvements. In-lining some C code or an entire function may provide tiny localized speed-ups, but moving time-consuming routines into high-performance FPGA hardware can often result in an order-of-magnitude improvement. With intelligent views of the code execution by specific function names, you can see exactly which software routines to adjust, providing a much higher return on improving system performance. Conclusion Intelligent platform-aware tools can help you identify the inefficiencies in your embedded software code and allow you to optimize performance. Knowing which specific software functions you need to streamline allows you to evolve your hardware/software partitioning and accelerate more modules in programmable FPGA fabric. The high-performance nature of parallel FPGA hardware resources and the advent of easy-to-use, programmable co-processing technologies like the Virtex-4 FX APU enable you to create faster and more flexible embedded processing systems. Xilinx offers clear advantages for embedded processing over traditional discrete or competitive FPGA solutions. Our tools, combined with our programmable embedded Platform FPGAs, offer a significant performance improvement for realtime developers. To learn more about the Platform Studio tool suite, please visit www.xilinx.com/edk. A good starting point to learn about all of our embedded processing solutions is www.xilinx.com/processor. 12 Xcell Journal Third Quarter 2005
Designing Control Circuits for High-Performance DSP Systems by Narinder Lall Sr. DSP Marketing Manager Xilinx, Inc. narinder.lall@xilinx.com Brad Taylor System Generator Applications Manager Xilinx, Inc. brad.taylor@xilinx.com FPGAs have made significant strides as engines for implementing high-performance signal processing functions, whether for ASIC replacement or performance acceleration in the signal processing chain with DSP processors. Although much has been written about how to use FPGAs as signal processors, not much has been published about building control circuits within such systems. There are perhaps two key decisions to make when implementing control circuits for FPGA-based DSP systems: • Should the control circuit be implemented in hardware or developed as a software algorithm? • What building blocks are available to make the development of the control circuit as efficient and painless as possible? Software or Hardware? In this first stage, you can make tradeoffs between algorithms that are implemented in hardware, and those that are better implemented in software using a soft microprocessor (Xilinx ® PicoBlaze and MicroBlaze processors) or hard embedded microprocessor (PowerPC 405). Table 1 shows the tradeoffs between hardware- and software-based approaches. A number of attributes need to be considered when making tradeoffs between these approaches. These include: • Algorithm complexity. You can easily implement simple algorithms (like those that do not need many lines of C-code) in both software and hardware. Although no absolute measure exists to correlate how many lines of C-code represent one slice, a good SYSTEM PERFORMANCE These simple techniques could save you days of work. rule of thumb is that one line equals 1 to 10 slices. When algorithm complexity rises, implementing and testing the algorithm in hardware becomes more challenging. You can more easily implement complex algorithms in lines of C code on a microprocessor, which is the preferred route most designers choose. • Need for an RTOS. If an RTOS is a mandatory piece of the control algorithm, this again favors a software approach that exploits the use of the hard embedded PowerPC on Virtex-II Pro or Virtex-4 FX FPGAs, or on external microprocessors. RTOS support for these microprocessors currently includes support from Wind River and MontaVista. • Communication with the host. Communication with a host processor will often – but not always – require a bus architecture of some kind. In this instance, a microprocessor such as the Third Quarter 2005 Xcell Journal 13
Page 1 and 2: Xcell Issue 54 Third Quarter 2005 j
Page 3 and 4: EDITOR IN CHIEF Carlis Collins edit
Page 5 and 6: THIRD QUARTER 2005, ISSUE 54 Xcell
Page 7 and 8: Hardware Said ... The design flow s
Page 9 and 10: The second idea is to have the hard
Page 11: and automatic module generation wil
Page 15 and 16: Figure 2 - Implementing an FSM in S
Page 17 and 18: Let’s consider these challenges i
Page 19 and 20: demonstrated by Dr. Howard Johnson,
Page 21 and 22: Pblocks can direct the flow of the
Page 23 and 24: Virtex-4 beats competing FPGAs in e
Page 25 and 26: In addition, you may also use techn
Page 27 and 28: Using Precision Sythesis, Block Mul
Page 29 and 30: 14-Bit, 125Msps ADC Only 395mW Lowe
Page 31 and 32: Non-Symmetric Aspect Ratios/FWFT Ap
Page 33 and 34: QWERTY Building Blocks Our solution
Page 35 and 36: FPGA-Based Video Games Implementing
Page 37 and 38: The Atari 2600 Video Computer Syste
Page 39 and 40: The architecture wizards inside ISE
Page 41 and 42: Smart Telematics Systems from Xilin
Page 43 and 44: interfaces available, Microsoft int
Page 45 and 46: TXPLL TxData[7:0] FIFO an x4 link c
Page 48 and 49: POWER MANAGEMENT Design Techniques
Page 50 and 51: Power Estimation Tools Xilinx provi
Page 52 and 53: POWER MANAGEMENT Performance vs. Po
Page 54 and 55: POWER MANAGEMENT is the first time
Page 56 and 57: POWER MANAGEMENT Merging CPLD Featu
Page 58: POWER MANAGEMENT A Clear Choice Wit
Page 62 and 63:
POWER MANAGEMENT Spartan-3 FPGA Pow
Page 64:
POWER MANAGEMENT 5 V_INPUT Highly i
Page 67 and 68:
Tool Example Electrical Simulations
Page 69 and 70:
y Bill Hargin Product Manager, Hype
Page 71 and 72:
Typically used bit patterns, or “
Page 73 and 74:
ages and densities for increased fl
Page 75 and 76:
see the start sequence, it continue
Page 77 and 78:
The Virtex-4 ML450 Development Boar
Page 79 and 80:
CONNECTIVITY Bridging System Packet
Page 81 and 82:
put stream of SPI-4.2 data. A progr
Page 83 and 84:
Controlling Noise A well-designed p
Page 85 and 86:
Prototype Your PCIe ASIC HERE See u
Page 87 and 88:
knowing what is in R3 of the proces
Page 89 and 90:
X-ray X-ray vision vision for for y
Page 91 and 92:
The program size is smaller because
Page 93 and 94:
Communications) and Verilog PLI, so
Page 95 and 96:
Figure 1 - Period constraint in Syn
Page 97 and 98:
DEBUGGING Using the actual constrai
Page 99 and 100:
Bus Triggering and Display Traditio
Page 101 and 102:
Designer Challenges for Pb-Free and
Page 103 and 104:
A Shortcut to Effective Hierarchica
Page 105 and 106:
Xilinx Education Services: Knowledg
Page 107 and 108:
BIDIR_PAD(7.0) BIDIR this course, w
Page 109 and 110:
Xesium Global Clocking • 500MHz D
Page 111 and 112:
Xilinx Virtex-4 FPGAs www.xilinx.co
Page 113 and 114:
Xilinx CPLD www.xilinx.com/devices/
Page 116:
Design Example: 1.5 volt LVCMOS 4mA
show all

Design Challenges: Avoiding the Pitfalls, winning the game - Xilinx

Create successful ePaper yourself

Delete template?

Save as template?