Writing Platform-independent Code Demonstrated by COOL FPGA (Component-Oriented Logic for FPGAs)

1. Writing Platform-independent CodeDemonstrated by COOL FPGA(Component-Oriented Logic for FPGAs) Dan Gardner, Mentor Graphics Ken Simone, Consultant Bill Turri, Systran Federal Corporation Final MAPLD Presentation

2. Agenda • Overview • Application Builder • System Analyzer • Example of Portability • Questions & Action Summary

3. Understanding Mil/Aero Needs • 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 • ICP is a shared processing resource providing data processing for multiple on-board JSF sensors • Methodology must allow development of designs that are easily portable and maintainable • ICP designs must be ported to new hardware whenever a “tech-roll” occurs to update one or more ICP components • Key requirements are portability, maintainability, and verifiability

4. COOL Concept • 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

5. Why COOL Works • 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

6. The “BIG” Picture COOL SCOPE Requirement Management Xilinx System Generator C-Code Generation Real-time Workshop COOL Library DSP Algorithm Development With MATLAB Reqs Platform DB Build Applications With HDL Designer C/C++ Synthesis With CatapultC DSP Toolbox PSL TBs Synthesis Constraints DSP Libs COOL Rules DSP Algorithm Analysis With Simulink Verification With Modelsim Test Sets RTL Synthesis System Analysis With Design Analyst S/W Debug C Libs Software Development Executable Code Hardware In The Loop Implementation Platform DB

7. What’s Cool About COOL • COOL allows platform independence • FPGAs are big and fast enough for real production design, so users need COOL support for • 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 • True vendor independent flows utilize COOL • Mixture of new languages emerging for design and verification • New entrants in FPGA devices

8. Constraints COOL System COOL Conformant Application User Designs COOL IP & Tools COOL Top Block • COOL conformant applications are: Portable; Maintainable; and Verified

9. Operating Logic COOL Components Constraints COOL System COOL Rules System Analyzer Application Builder COOL Conformant Application User Designs COOL IP & Tools

10. COOL Conceptual Overview (1) • 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

11. COOL Conceptual Overview (2) • Portability – Applications created with OL can be easily ported to new hardware platforms • 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 COOLtools and will not be of concern to the designer • Maintainability– All applications will be designed with Application Builder from self-contained modules • 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 • System-wide problems will be identified for correction before they appear in a real implementation

12. Application Builder (1) • 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 • 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

13. 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

14. Application Builder (3) Application Builder COOL Method Method Architectures HDL Designer allows the creation and management of multiple architectures for any given library component

15. 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

16. Operating Logic System Analyzer Overview Constraints COOL System COOL Rules System Analyzer Application Builder COOL Conformant Application User Designs COOL IP & Tools

17. System Analyzer (1) System Analyzer is launched from the Application Builder to ensure Program Requirements for Portability, Maintainability, and Verifiability are achieved.

18. System Analyzer (2) Users control the scope of analysis

19. System Analyzer (3) Library dependencies can be identified within the Application Builder.

20. System Analyzer (4) Errors and Warnings are categorized by Program Rules for easy identification and prioritization of actions.

21. System Analyzer (5) Users have explicit Controllability and Visibility of Rules applied to analysis.

22. System Analyzer (6) Users can access detailed descriptions of violations.

23. System Analyzer (7) Users can explore the categories of violations.

24. System Analyzer (8) Users can better understand the reasoning of the rules through online documentation.

25. System Analyzer (9) Cross-probing between violations and source code enables rapid iterations to achieve program compliance.

26. System Analyzer (10) Results are easily exported for downstream processing.

27. System Analyzer (11) This is an example of the results displayed in MS Excel spreadsheet.

28. System Analyzer (12) Remember to Check In the modified code to your project archive!

29. System Analyzer Summary • 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.

30. Portability Demo Summary (1) • 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 • 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) • Demo will illustrate portability • Demo will illustrate maintainability

31. SE B SE C PE B PE C IOE PE D SE A SE D Portability Demo Summary (2) 2) Data traverses the RapidIO packet switching network 3) Data is received here via the FIFO_In Method 1) Data is generated here, and sent through the FIFO_Out Method

32. Portability Demo (1) • Method Configuration Parameters • User-defined values • User Logic • Supplies data to the FIFO method • Infrastructure Method • Controls access to system • resources (RapidIO network • here) • Data Method • Implements one of two • FIFO architectures

33. Portability Demo (2) Case 1a: Instantiated BlockRAM-based FIFO architecture BRAM FIFO uses BlockRAM… Highly efficient for Xilinx FPGAs Simulate to verify post-synth results… Synthesize for Xilinx FPGA

34. Portability Demo (3) Results do agree with original simulation … because BlockRAMs do exist in Xilinx libraries!

35. Portability Demo (4) Case 1b: Instantiated BlockRAM-based FIFO architecture BRAM FIFO uses BlockRAM… Highly efficient for Xilinx FPGAs Simulate to verify post-synth results… Synthesize for Altera Stratix-II FPGA

36. Portability Demo (5) Results do not agree with original simulation … because BlockRAMs donot exist in Altera libraries!

37. Portability Demo (6) Case 2a: Array-based FIFO architecture Array FIFO uses generalized array-based architecture Simulate to verify post-synth results… Synthesize for Xilinx Virtex-II FPGA

38. Portability Demo (7) Results still agree with original simulation … because no platform dependencies exist!

39. Portability Demo (8) Case 2b: Array-based FIFO architecture Array FIFO uses generalized array-based architecture Simulate to verify post-synth results… Synthesize for Altera Stratix-II FPGA

40. Portability Demo (9) Results now agree with original simulation … because platform dependencies no longer exist!

41. Portability Demo (10) Results of BlockRAM-based and Array-based FIFO agree … change in architecture remains transparent to User’s Application!

42. Portability Demo (11) • 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

43. Portability Demo (12) • How it was done • Original design had two Xilinx Virtex-4 BlockRAM cells instantiated • Modified version had dual-port RAM block coded in RTL bram0: RAMB16_S36_S36 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) ); bram1: RAMB16_S36_S36 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) ); bram: sync_ram_dualport port 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);

44. Portability Demo (13) • Portable RAM block • Parameterized address and data width • This example was tested and maps to dedicated memory blocks for these devices • Xilinx Virtex-4 and Spartan3E • Altera Stratix-II and Cyclone II • Actel ProASIC3E and Axcellerator • Lattice Semiconductor Lattice-EC entity sync_ram_dualport is generic (data_width : natural := 64; addr_width : natural := 9); 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 ;

45. COOL Lessons Learned • User-friendly Application Builder for creating and managing modular logic designs • Flexible methodology allowing for portability and maintainability of designs • Near-term benefit to JSF program • Long-term benefit for any applications desiring platform-independent 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

46. Questions • Further Questions?

47. Appendix • Technical Discussion Support Slides Follow

48. COOL Technical Review (1) • Operating Logic includes several major concepts • 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 platform-independent 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

49. COOL Technical Review (2) COOL Module (consists of User Logic and methods) Relationships among User Logic, methods, architectures, and resources

50. COOL Technical Review (3) Structure of a COOL Application