Delevopment Tools Beyond HDL Wolfgang Kühn, Univ. Giessen

Wolfgang Kühn, Univ. Giessen Overview Introduction FPGA Design Challenges VHDL Tools with higher abstraction level Handel-C Features Differences to VHDL Advantages Drawbacks Possible applications Wolfgang Kühn, Univ. Giessen

Wolfgang Kühn, Univ. Giessen Common Prejudice ….. FPGAs are good for applications which involve simple algorithms which can be executed in parallel require high speed (few ns level) response to real time events do not need frequent redesigns (expert knowledge required !) DSPs are good for applications which involve complex algorithms with many arithmetic operations are less demanding in real time requirements require programming in C / C++ because sometimes even a physicst needs to change part of the code Wolfgang Kühn, Univ. Giessen

FPGA / DSP Performance (3/2003) Example: XILINX Virtex-II and Virtex-II Pro Function Industry’s Fastest DSP Processor Core Xilinx Virtex-II Virtex-II Pro 8 x 8 Multiply Accumulate (MAC) 4.8 billion MAC/s 0.5 Tera MAC/s 1 Tera MAC/s FIR Filter - 256 taps, linear phase - 16-bit data/coefficients 9.3 MSPS 600 MHz 180 MSPS 180 MHz 300 MSPS 300 MHz Complex FFT - 1024 point, 16-bit data 10.2 s 1 s* 140 MHz 1 s** 150 MHz DSP processor is: TI C64x 8x8 MAC: TMS320C64x: Has four 16x16 MACs running at 600 MHz in parallel. Each can be used as two 8x8 MACs => 8 x 600 MHz = 4.8 billion MAC/s XC2V8000: 2V8000 has 46,592 slices; therefore, we can fit 46,592/4,800 = 9.7 256-tap FIR filter. Round it off to 10 256-tap FIR filters running at 180 MHz: 10 x 256 x 180 MHz = 461 BMACs. Add to this 168 embedded multipliers running at ~180MHz (for an 8x8): 168 x 180MHz = 30 BMACs, for a grand total of 461 + 30 = 491 BMACs and almost 0.5 Tera MACs 256-tap FIR filter: Based on the DA FIR filter implementation with coefficients generated by MATLAB for a low pass filter, a 256-tap, 8-bit data, symmetric filter uses 4,800 slices. Such a filter can run at 180 MHz in parallel, and hence reaches 180 MSPS. 1024-point FFT: The latest 1024-point FFT core has an execution time of 7.3 us @fclk = 140 MHz, requires 12 multipliers, ~2,500 slices and 12 block memories. Including eight such FFTs in one FPGA allows a new transform to be completed every microsecond. XC2VP125 – Virtex-II PRO: 2VP125 has 62,568 slices and 556 embedded multipliers. There are two ways to implement a FIR Filter. The MAC approach requires the multiplier and the accumulator. The Distributed Arithmetic approach uses exclusively slices. - # of 8x8 MACs using embedded multipliers: 556 If we add a 16-bit accumulator, this will also require 556 x 8 = 4,448 slices. 556 multipliers running at 300 MHz results in 556 x 300 = 167 BMAC/s - # of 8x8 MACs implemented in slices One 8-bit data, 8-bit coefficient, symmetric, 256-tap FIR filter consumes 4,800 slices when implemented in slices. We can therefore fit (62,568-4,448)/4,800 = 12.1 256-tap FIR filter. Round it off to 12 256-tap FIR filters running at 260 MHz: 12 x 256 x 260 MHz = 798 BMACs, for a grand total of 167 + 798 = 965 BMACs and almost 1 Tera MACs 256-tap FIR filter: Implementing this filter using 256 embedded multipliers in parallel, or 128 embedded multipliers if we take advantage of coefficient symmetry, along with fully pipelined adders can be clocked at 300 MHz. As a new sample can be sent on each clock cycle, this results in a 300MSPS FIR filter. 1024-point FFT: The latest 1024-point FFT core has an execution time of 7.3 us @fclk = 150 MHz, requires 12 multipliers, ~2,500 slices and 22 block memories. Including eight such FFTs in one FPGA allows a new transform to be completed every microsecond. * Using 96 embedded multipliers in the largest Virtex-II device (XC2V8000) ** Using 96 embedded multipliers and 176 Block Ram in V-II PRO (XC2V125) Wolfgang Kühn, Univ. Giessen

Wolfgang Kühn, Univ. Giessen

Typical FPGA Design Flow Plan & Budget Create Code/ Schematic HDL RTL Simulation Implement Functional Simulation Synthesize to create netlist Translate Map Place & Route These are the major stages of implementing a design in a Xilinx device. The implementation stage consists of three steps, which will be discussed later in this presentation. Although simulation points can happen in other parts of the design cycle, the three simulation points in the above diagram are the Xilinx recommended simulation points. More details on Timing Closure in a coming slide. For more detailed flow diagrams, refer to Chapter 2 (Design Flow) of the Development System Reference Guide at support.xilinx.com > Software Manuals Attain Timing Closure Timing Simulation Create Bit File Wolfgang Kühn, Univ. Giessen

XILINX Tools for Digital Signal Processing Simulink® DSP Modeling MATLAB® Automatic Translation Generate: - VHDL/Verilog - IP cores ISE® 4.1i Implementation & Verification ® XST® Leonardo Spectrum® Synplify® Synthesis Xilinx offers the most advanced tool suite for doing DSP design on FPGAs For the front-end, customers can use popular industry standards for developing DSP models and algorithms. From then on, Xilinx offers a complete front-to-back DSP design flow for FPGAs which includes System Generator v2.1, XST for synthesis and the industry’s best implementation tool suite ISE4.2i. Simulink DSP Systems modeled with System Generator can be translated into VHDL or Verilog for synthesis. Synthesis can be performed using third party tools from companies like Exemplar or Synplicity, or using XST whish is actually integrated into ISE. The benefit of this flow is that Professors, Researchers, and students that are not familiar with FPGAs can still use tools that they are familiar with (e.g. MATLAB and Simulink from Mathworks) and let Xilinx tools do the rest. Wolfgang Kühn, Univ. Giessen

Wolfgang Kühn, Univ. Giessen MATLAB MATLAB™, the most popular system design tool, is a programming language, interpreter, and modeling environment Extensive libraries for math functions, signal processing, DSP, communications, and much more Visualization: large array of functions to plot and visualize your data and system/design Open architecture: software model based on base system and domain-specific plug-ins The MathWorks has been developing system design tools since 1984. Its latest product is MATLAB 6.5 (from MATLAB tools release 13, July, 2002). Visit The MathWorks website at http://www.mathworks.com for further details. Other vendors of system-level modeling packages are: Visual data flow SPW (Cadence), COSSAP (Synopsys), Ptolemy (UC Berkeley), SystemView (Elanix) Programming language based C++ SystemC, OCAPI (IMEC) C Streams-C (Gokhale et al.), Handel-C (Celoxica) Java JHDL (BYU) Relative success of each approach, at least to date, is indicated by the predominance of commercial offerings in VDF (Visual Data Flow) as compared to research activity. Wolfgang Kühn, Univ. Giessen

Wolfgang Kühn, Univ. Giessen Simulink Simulink™ - Visual data flow environment for modeling and simulation of dynamical systems Fully integrated with the MATLAB engine Graphical block editor Event-driven simulator Models parallelism Extensive library of parameterizable functions Simulink Blockset - math, sinks, sources DSP Blockset - filters, transforms, etc. Communications Blockset - modulation, etc. Simulink, The MathWorks’ visual data flow tool, presents an alternative to using programming languages for system design. This enables designers to visualize the dynamic nature of your system while illustrating their complete system in a realistic fashion with respect to the hardware design. Most hardware design starts out with a block diagram description and specification of the system, very similar to the Simulink design. The main part of Simulink is the Library browser that contains all the available building blocks to the user. This library is expandable and each block is parameterizable. Users can even create their own libraries of functions they have created. An important point of note about Simulink is that it can model concurrency in a system. Unlike the sequential manner of software code, the Simulink model can be seen to be executing sections of a design at the same time (in parallel). This notion is fundamental to implementing a high-performance hardware implementation. Wolfgang Kühn, Univ. Giessen

Traditional Simulink FPGA Flow System Architect System Verification GAP Simulink FPGA Designer HDL Synthesis Functional Simulation Verify Equivalence In the past, if a DSP designer wanted to target an FPGA, he would have no option but a “dual path” of development. The DSP designer writes an algorithm in pseudo-C, using filters, certain C code, certain precision. He may know everything about DSP and Simulink models, but may not know anything about FPGAs. Not only does he not know how to target an FPGA, he doesn’t know how to take advantage of the FPGA architecture, or how to write a design to avoid a bad FPGA implementation. When he’s done with his DSP design, he may have a working model in Simulink, but he must design the same thing in VHDL, or he gives his design to an FPGA implementer (who may know nothing about DSP) who writes the VHDL for him. The implementer might end up using a core that doesn’t do exactly what the designer wants, but not being a DSP expert, the FPGA implementer is just trying to translate the pseudo code that came to him into VHDL for an FPGA. There is also no way to co-simulate: one is simulating in C in MATLAB, the other simulating in VHDL in a behavioral simulation. It’s only when they get into the lab and simulate the board, late in the process, that they find out something’s wrong. Implementation Timing Simulation Download In-Circuit Verification Wolfgang Kühn, Univ. Giessen

XILINX System Generator MATLAB/Simulink VHDL IP Testbench Constraints File HDL System Verification System Generator Synthesis Functional Simulation Implementation Timing Simulation Now, with the System Generator, our DSP designer has a single development path - no need for parallel development effort and the possibility of two different results. Currently, only XST from Xilinx, as well as Synplify (from Synplicity) and Leonardo Spectrum (from Exemplar) support the VHDL code generated by System Generator. There is no schedule for FPGA Express to support the VHDL code. Download In-Circuit Verification Wolfgang Kühn, Univ. Giessen

Handel-C ( http://www.celoxica.com ) Handel-C is a language for programming applications Handel-C is not an HDL. It is not C used as an HDL Handel-C is meaningful to both s/w and h/w engineers Focus of describing solutions to problems as algorithms VHDL/Verilog focus on describing the structure of a system capable of performing an algorithm. Hardware design means controlling space (parallelism) and time (sequential processing) The par command gives control over space The Single clock assignment rule gives control over time Wolfgang Kühn, Univ. Giessen

Handel-C Core Language Features Standard ISO-C (ANSI-C) Control commands: if, while, switch etc. Functions, structures, pointers Extensions for hardware implementation par{…} construct - specifies spatial-parallel architecture Single cycle assignment – specifies temporal architecture Arbitrary widths on variables, expressions etc. Type-checked bit-width inference system Recursive macro expansion system Multiple clock domains with automatic metastability resolution Powerful bit manipulation operators Signals, channels, interfaces to pins, external IP cores RAMs/ROMs and external pin connections Wolfgang Kühn, Univ. Giessen

Wolfgang Kühn, Univ. Giessen Timing is predictable Designer has control over timing Simple model: assignments take one clock cycle Cycle-accurate, fast simulator Parallelism is deterministic Language extensions include parallel processing and communications between parallel elements Parallelism based on sound mathematical formalism Changes are predictable Changes in Handel-C code produce predictable changes in hardware Enables fast iterative refinement Wolfgang Kühn, Univ. Giessen

Hardware/Software Co-Design Enables development of complete systems, ideal for: Board-level prototyping Reconfigurable SoC designs Hybrid CPU & FPGA devices Design kit (DK1) facilitates co-design with: Instruction set simulators VHDL simulators External C test benches Enables hardware/software partitioning decisions later in the design cycle Rapid conversion of software algorithms into custom hardware Wolfgang Kühn, Univ. Giessen

DK1 Design Suite Features Handel-C Simulate Compiler Output is: Optimised Deterministic Target specific Targets Xilinx and Altera net lists directly (EDIF) RTL VHDL output Generation of IP cores (Handel-C, EDIF, VHDL) Inclusion of IP cores as ‘black boxes’ GUI for integrated project management, code editing and source level debugging Fast simulation/debug Compile Netlist Place And Route FPGA Vendor’s Tools Configure Wolfgang Kühn, Univ. Giessen

Wolfgang Kühn, Univ. Giessen Conclusions Exploiting the power of modern FPGAs gets increasingly difficult using only „traditional“ HDL design methods 1 Million Gate XILINX Spartan III costs only 12 $ !!! New areas of application beyond traditional FPGA domains require higher levels of abstraction Tools such as Handel-C look promising Experience with real designs needed Wolfgang Kühn, Univ. Giessen