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
C-Code Generation Real-time Workshop
Xilinx System Generator
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
Software Development
C Libs
Executable Code
Hardware In The Loop
Implementation
Platform DB
7
Whats 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
COOL Top Block

• COOL conformant applications are Portable
  Maintainable and Verified

9
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 COOL tools 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
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 Users 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
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 becaus
e 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 do not 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 Users 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 gt
read_addr, ADDRB gt write_addr,
DIA gt gnd_bus(35 downto 4), DIPA gt gnd_bus(3
downto 0), DIB gt write_data(63
downto 32), DIPB gt gnd_bus(3 downto 0),
WEA gt gnd, WEB gt pwr, CLKA gt clock, CLKB
gt clock, SSRA gt gnd, SSRB gt
gnd, ENA gt read_allow, ENB gt write_allow,
DOA gt read_data(63 downto 32), DOPA gt
unused_1(3 downto 0) ) bram1 RAMB16_S36_S36
port map (ADDRA gt read_addr, ADDRB gt
write_addr, DIA gt gnd_bus(35
downto 4), DIPA gt gnd_bus(3 downto 0),
DIB gt write_data(31 downto 0), DIPB gt
gnd_bus(3 downto 0), WEA gt gnd,
WEB gt pwr, CLKA gt clock, CLKB gt clock,
SSRA gt gnd, SSRB gt gnd, ENA gt
read_allow, ENB gt write_allow,
DOA gt read_data(31 downto 0), DOPA gt unused_2(3
downto 0) )
bram sync_ram_dualport port map ( clk_in gt
clock, clk_out gt clock, we gt
write_allow, re gt read_allow, addr_in gt
write_addr, addr_out gt read_addr, data_in gt
write_data, data_out gt 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 (2addr_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
51
COOL Technical Review (4)

• Mapping User Logic to hardware architectures
• Methods will present designers with consistent
  user-side interfaces, but the architecture-side
  interfaces will be platform-specific
• Appropriate mapping between methods and
  architecture will be accomplished at build-time
  by the COOL tools (Application Builder)

Mapping methods to an architecture