Title: Writing Platform-independent Code Demonstrated by COOL FPGA (Component-Oriented Logic for FPGAs)
1Writing Platform-independent CodeDemonstrated
by COOL FPGA(Component-Oriented Logic for FPGAs)
- Dan Gardner, Mentor Graphics
- Ken Simone, Consultant
- Bill Turri, Systran Federal Corporation
Final BOF MAPLD Presentation
2Agenda
- Overview
- Application Builder
- System Analyzer
- Example of Portability
- Questions Action Summary
3Understanding 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
4COOL 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
5Why 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
6The 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
7Whats 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
8COOL Top Block
- COOL conformant applications are Portable
Maintainable and Verified
9COOL Components
Constraints
COOL System
COOL Rules
System Analyzer
Application Builder
COOL Conformant Application
User Designs
COOL IP Tools
10Application Builder
- 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
11System Analyzer
System Analyzer is launched from the Application
Builder to ensure Program Requirements for
Portability, Maintainability, and Verifiability
are achieved.
12System 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.
13Portability Demo (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
14Portability Demo (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
15Portability Demo (3)
- 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
16Portability Demo (4)
- 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)
17Portability Demo (5)
- 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
18COOL 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
19Questions