Writing Platformindependent Code Demonstrated by COOL FPGA ComponentOriented
Writing Platform-independent Code Demonstrated by COOL FPGA (Component-Oriented Logic for FPGAs) Dan Gardner, Mentor Graphics Ken Simone, Consultant Bill Turri, Systran Federal Corporation Final MAPLD Presentation
Agenda n n n Overview Application Builder System Analyzer Example of Portability Questions & Action Summary Gardner Page 2 MAPLD 2005/P 129
Understanding Mil/Aero Needs n Programs like the Navy JSF program need a new design methodology to develop logic designs for large, complex FPGA systems — Integrated Core Processor (ICP) is such a system n — Methodology must allow development of designs that are easily portable and maintainable n n Gardner ICP is a shared processing resource providing data processing for multiple on-board JSF sensors ICP designs must be ported to new hardware whenever a “techroll” occurs to update one or more ICP components Key requirements are portability, maintainability, and verifiability Page 3 MAPLD 2005/P 129
COOL Concept n n COOL concept was developed by Systran Federal Corporation for a Navy SBIR Ad hoc methodologies need to be replaced with proven methodologies COOL is an example of one way this can be done Something like this is necessary and possible today for large, Mil/Aero FPGA designs Gardner Page 4 MAPLD 2005/P 129
Why COOL Works n COOL will provide users with a set of tools offering GUI-driven functionality for ease of design entry and debugging, combined with libraries offering flexible, platform-independent design options — COOL improves portability — COOL improves maintainability — COOL improves verifiability Gardner Page 5 MAPLD 2005/P 129
The “BIG” Picture Requirement Management Reqs COOL SCOPE C-Code Generation Real-time Workshop DSP Algorithm Development With MATLAB DSP Toolbox PSL C/C++ Synthesis With Catapult. C TBs DSP Algorithm Analysis With Simulink Test Sets Build Applications With HDL Designer Verification With Modelsim COOL Library Platform DB Synthesis Constraints DSP Libs S/W Debug C Libs Xilinx System Generator COOL Rules System Analysis With Design Analyst RTL Synthesis Software Development Executable Code Hardware In The Loop Implementation Platform DB Gardner Page 6 MAPLD 2005/P 129
What’s Cool About COOL n COOL allows platform independence — FPGAs are big and fast enough for real production design, so users need COOL support for n n n Embedded RAM, DSP, microcontroller and microprocessor Complex I/O Higher level of abstraction IP and Design reuse COOL allows implementation independence to shield the user — — — Gardner True vendor independent flows utilize COOL Mixture of new languages emerging for design and verification New entrants in FPGA devices Page 7 MAPLD 2005/P 129
COOL Top Block Constraints COOL System COOL Conformant Application User Designs COOL IP & Tools n COOL conformant applications are: Portable; Maintainable; and Verified Gardner Page 8 MAPLD 2005/P 129
COOL Components Constraints COOL System COOL Rules System Analyzer Application Builder COOL Conformant Application User Designs Operating Logic COOL IP & Tools Gardner Page 9 MAPLD 2005/P 129
COOL Conceptual Overview (1) n COOL consists of three major components Operating Logic: libraries of platform-independent logic modules, used to create interfaces, “glue logic, ” etc. in a user design. Designed to isolate application logic from hardware-specific platform details. — Application Builder: design entry, management of Operating Logic libraries, mapping functions, and interfaces with other tools — System Analyzer: system-level code analysis and simulation — Gardner Page 10 MAPLD 2005/P 129
COOL Conceptual Overview (2) n Portability – Applications created with OL can be easily ported to new hardware platforms — — — n Maintainability– All applications will be designed with Application Builder from self-contained modules — — n Interfaces between applications and OL will be consistent across platforms OL will enforce well-structured logic designs Hardware-specific “back ends” will be addressed by the COOL tools and will not be of concern to the designer Modules are isolated from changes made to other modules This need is critical in applications with very long product lives (such as the JSF) Verifiability – System Analyzer allows analysis and verification — Gardner System-wide problems will be identified for correction before they appear in a real implementation Page 11 MAPLD 2005/P 129
Application Builder (1) n COOL will consist primarily of the Application Builder — This GUI-driven tool will allow designers to work with COOL methods and libraries, and will offer some or all of the following capabilities n n n n n — Gardner Create modules (from existing components and methods) Construct applications (from existing and custom modules) Define new methods Build method libraries Define resources Share resources Invoke other tools Manage projects Map applications to hardware Application Builder functions implemented and integrated with Mentor Graphics HDL Designer Page 12 MAPLD 2005/P 129
Application Builder (2) COOL Method COOL Architectures COOL Libraries HDL Designer allows the creation and management of multiple libraries within a user-friendly graphical interface Gardner Page 13 MAPLD 2005/P 129
Application Builder (3) Application Builder COOL Method Architectures HDL Designer allows the creation and management of multiple architectures for any given library component Gardner Page 14 MAPLD 2005/P 129
Application Builder (4) Provides integration with • Compilation tools • Simulation tools • Synthesis tools • Verification tools An entire COOL design, from start to finish, should be managed through a single interface. This is why HDL Designer was chosen to serve as the COOL Application Builder Gardner Page 15 MAPLD 2005/P 129
System Analyzer Overview Constraints COOL System COOL Rules System Analyzer Application Builder COOL Conformant Application User Designs Operating Logic COOL IP & Tools Gardner Page 16 MAPLD 2005/P 129
System Analyzer (1) System Analyzer is launched from the Application Builder to ensure Program Requirements for Portability, Maintainability, and Verifiability are achieved. Gardner Page 17 MAPLD 2005/P 129
System Analyzer (2) Users control the scope of analysis Gardner Page 18 MAPLD 2005/P 129
System Analyzer (3) Library dependencies can be identified within the Application Builder. Gardner Page 19 MAPLD 2005/P 129
System Analyzer (4) Errors and Warnings are categorized by Program Rules for easy identification and prioritization of actions. Gardner Page 20 MAPLD 2005/P 129
System Analyzer (5) Users have explicit Controllability and Visibility of Rules applied to analysis. Gardner Page 21 MAPLD 2005/P 129
System Analyzer (6) Users can access detailed descriptions of violations. Gardner Page 22 MAPLD 2005/P 129
System Analyzer (7) Users can explore the categories of violations. Gardner Page 23 MAPLD 2005/P 129
System Analyzer (8) Users can better understand the reasoning of the rules through online documentation. Gardner Page 24 MAPLD 2005/P 129
System Analyzer (9) Cross-probing between violations and source code enables rapid iterations to achieve program compliance. Gardner Page 25 MAPLD 2005/P 129
System Analyzer (10) Results are easily exported for downstream processing. Gardner Page 26 MAPLD 2005/P 129
System Analyzer (11) This is an example of the results displayed in MS Excel spreadsheet. Gardner Page 27 MAPLD 2005/P 129
System Analyzer (12) Remember to Check In the modified code to your project archive! Gardner Page 28 MAPLD 2005/P 129
System Analyzer Summary n n n n Integration within Application Builder provides ease of use. Results are clearly presented, and exportable. Users control the scope of analysis for efficiency. Program Rules are applied to ensure consistency amongst developers. Rules are well documented and extensible. Cross-Probing enables rapid iterations to compliance. Code modifications and reasoning are easily documented. Gardner Page 29 MAPLD 2005/P 129
Portability Demo Summary (1) n This demo uses two FIFO-based COOL Methods to transfer data from one part of an application to another — — Data originates in one simulated processing element (FPGA) and is received in a different simulated processing element (FPGA) In neither location does the User Logic need to be aware of the location of the rest of the application n n In this simple example, the data only traverses two switching nodes, but any number of nodes (or none at all) could be used with no impact on the design (from the User’s perspective) This demo will illustrate what could happen if we ported the application from a Xilinx-based platform to any other FPGA device with built-in memory blocks (a realistic scenario) — — Gardner Demo will illustrate portability Demo will illustrate maintainability Page 30 MAPLD 2005/P 129
Portability Demo Summary (2) 2) Data traverses the Rapid. IO packet switching network SE B SE C PE B 1) Data is generated here, and sent through the FIFO_Out Method IOE PE C PE D SE A Gardner 3) Data is received here via the FIFO_In Method SE D Page 31 MAPLD 2005/P 129
Portability Demo (1) User Logic • Supplies data to the FIFO method Method Configuration Parameters • User-defined values Data Method • Implements one of two FIFO architectures Gardner Page 32 Infrastructure Method • Controls access to system resources (Rapid. IO network here) MAPLD 2005/P 129
Portability Demo (2) Case 1 a: Instantiated Block. RAM-based FIFO architecture BRAM FIFO uses Block. RAM… Highly efficient for Xilinx FPGAs Simulate to verify post-synth results… Synthesize for Xilinx FPGA Gardner Page 33 MAPLD 2005/P 129
Portability Demo (3) Results do agree with original simulation … because Block. RAMs do exist in Xilinx libraries! Gardner Page 34 MAPLD 2005/P 129
Portability Demo (4) Case 1 b: Instantiated Block. RAM-based FIFO architecture BRAM FIFO uses Block. RAM… Highly efficient for Xilinx FPGAs Simulate to verify post-synth results… Synthesize for Altera Stratix-II FPGA Gardner Page 35 MAPLD 2005/P 129
Portability Demo (5) Results do not agree with original simulation … because Block. RAMs do not exist in Altera libraries! Gardner Page 36 MAPLD 2005/P 129
Portability Demo (6) Case 2 a: Array-based FIFO architecture Array FIFO uses generalized array-based architecture Simulate to verify post-synth results… Synthesize for Xilinx Virtex-II FPGA Gardner Page 37 MAPLD 2005/P 129
Portability Demo (7) Results still agree with original simulation … because no platform dependencies exist! Gardner Page 38 MAPLD 2005/P 129
Portability Demo (8) Case 2 b: Array-based FIFO architecture Array FIFO uses generalized array-based architecture Simulate to verify post-synth results… Synthesize for Altera Stratix-II FPGA Gardner Page 39 MAPLD 2005/P 129
Portability Demo (9) Results now agree with original simulation … because platform dependencies no longer exist! Gardner Page 40 MAPLD 2005/P 129
Portability Demo (10) Results of Block. RAM-based and Array-based FIFO agree … change in architecture remains transparent to User’s Application! Gardner Page 41 MAPLD 2005/P 129
Portability Demo (11) n Lessons Learned from this example: Simple change to replace instantiated memory block — RAM inferencing allows this design to be portable without sacrificing device area or performance — Code is specific to the functionality required by the application, not the device architecture — Easier to simulate and understand than hand instantiated or vendor-created IP — Gardner Page 42 MAPLD 2005/P 129
Portability Demo (12) n How it was done — Original design had two Xilinx Virtex-4 Block. RAM cells instantiated bram 0: RAMB 16_S 36 port map (ADDRA => read_addr, ADDRB => write_addr, DIA => gnd_bus(35 downto 4), DIPA => gnd_bus(3 downto 0), DIB => write_data(63 downto 32), DIPB => gnd_bus(3 downto 0), WEA => gnd, WEB => pwr, CLKA => clock, CLKB => clock, SSRA => gnd, SSRB => gnd, ENA => read_allow, ENB => write_allow, DOA => read_data(63 downto 32), DOPA => unused_1(3 downto 0) ); bram 1: RAMB 16_S 36 port map (ADDRA => read_addr, ADDRB => write_addr, DIA => gnd_bus(35 downto 4), DIPA => gnd_bus(3 downto 0), DIB => write_data(31 downto 0), DIPB => gnd_bus(3 downto 0), WEA => gnd, WEB => pwr, CLKA => clock, CLKB => clock, SSRA => gnd, SSRB => gnd, ENA => read_allow, ENB => write_allow, DOA => read_data(31 downto 0), DOPA => unused_2(3 downto 0) ); — Modified version had dual-port RAM block coded in RTL bram: sync_ram_dualport map ( clk_in => clock, clk_out => clock, we => write_allow, re => read_allow, addr_in => write_addr, addr_out => read_addr, data_in => write_data, data_out => read_data); Gardner Page 43 MAPLD 2005/P 129
Portability Demo (13) n Portable RAM block — Parameterized address and data width entity sync_ram_dualport is generic (data_width : natural : = 64; addr_width : natural : = 9); — This example was tested and maps to dedicated memory blocks for these devices n n Xilinx Virtex-4 and Spartan 3 E Altera Stratix-II and Cyclone II Actel Pro. ASIC 3 E and Axcellerator Lattice Semiconductor Lattice-EC architecture rtl of sync_ram_dualport is type mem_type is array (2**addr_width downto 0) of std_logic_vector(data_width - 1 downto 0) ; signal mem : mem_type ; Gardner Page 44 MAPLD 2005/P 129
COOL Lessons Learned n n User-friendly Application Builder for creating and managing modular logic designs Flexible methodology allowing for portability and maintainability of designs — — n n Near-term benefit to JSF program Long-term benefit for any applications desiring platformindependent designs for implementation on multiple systems Integrated System Analyzer allowing for verifiability, to detect flaws in large-scale designs before they appear in real operation Synthesis inferencing capabilities allow comparable area and timing results to vendor specific instantiations, yet allow FPGA vendor independent code Gardner Page 45 MAPLD 2005/P 129
Questions n Further Questions? Gardner Page 46 MAPLD 2005/P 129
Appendix n Technical Discussion Support Slides Follow Gardner Page 47 MAPLD 2005/P 129
COOL Technical Review (1) n Operating Logic includes several major concepts — — — Gardner User Logic: logic created by the user to form the foundation of applications Resources: system components (may be memory, CPU, communication, channels, registers, etc. ) Methods: logic elements instantiated to provide access between User Logic and Resources Architectures: logic instantiated (by the tools) to link platformindependent methods to platform-dependent resources Modules: User Logic combined with one or more methods for accessing surrounding resources Applications: consist of one or more modules designed to perform specific tasks Page 48 MAPLD 2005/P 129
COOL Technical Review (2) COOL Module (consists of User Logic and methods) Relationships among User Logic, methods, architectures, and resources Gardner Page 49 MAPLD 2005/P 129
COOL Technical Review (3) Structure of a COOL Application Gardner Page 50 MAPLD 2005/P 129
COOL Technical Review (4) n Mapping User Logic to hardware architectures — — Methods will present designers with consistent user-side interfaces, but the architecture-side interfaces will be platformspecific Appropriate mapping between methods and architecture will be accomplished at build-time by the COOL tools (Application Builder) Mapping methods to an architecture Gardner Page 51 MAPLD 2005/P 129
- Slides: 51