In this document, implementation flow refers to the comprehensive run of the extractor, synthesis, and Xilinx ISE tools that turn the Verilog or VHDL source into a binary bitstream and configuration file that can be downloaded into the RASC Algorithm FPGA. There are several stages to this process, but the implementation flow has been encapsulated in a Makefile flow for ease of use.

Figure 7-1. RASC FPGA Implementation Flow

There are two supported ways to create a bitstream. The first method, and recommended for most cases, is to implement the Algorithm FPGA using our pre-synthesized Core Services Block EDIF netlist. This allows faster synthesis time and easy trials of multiple algorithms.

The second method, which allows more optimization between the Core Services and the Algorithm Block, is to synthesize from the top-down, including re-synthesis of the Core Services Block source codes.

The supported flow has been tested using the tool versions and operating system shown in Table 7-1.

SGI suggests that you consult the reference documentation associated with the supported tools of your choice for the details on tool setup.

RASC software is distributed either on a CD-ROM or through file transfer protocol (FTP). If an International Standards Organization (ISO) file is received through FTP, put it in a convenient directory in the SGI Altix system. If the directory /mnt/cdrom does not exist, create that directory with the following command:

mkdir /mnt/cdrom

At the directory where the ISO file is saved, execute the following command:

mount -o loop iso_file_name /mnt/cdrom

The CD-ROM image will be visible in the directory /mnt/cdrom.

On the CD-ROM image, there will be one or more files with the extension .rpm and a readme.txt file. Read the readme.txt file for further instructions for installing the software.

This section describes the installation and setup of the RASC Algorithm FPGA Developer's Bundle. Please note that the Xilinx ISE tools and the synthesis tool of choice must be installed on an x86 Linux system and each user must have the associated environment variables defined for their use.

The RASC Algorithm FPGA Developer's Bundle comes as a tar.gz file. This tar.gz file is available in the Altix system after the rasc_cs-xxx.ia64.rpm is installed. It is in the directory /usr/share/rasc/x86_dev_env. Run the executable x86_dev_env_install and read the license agreement. Agree to the agreement to extract the file x86_dev_env. Transfer this file to a directory in the PC. If there is an older version of the bundle software, remove it. Unzip the tar.gz file using the following command:

tar -zxvf file_name 

The Developer's Bundle requires setting one additional environment variable, RASC, to identify the Bundle installation directory to the supporting Makefiles (see Table 7-2).

The directory hierarchy within the RASC Algorithm FPGA Developer's Bundle is shown in the README file at the top level. A description of the top level directories included in the Bundle is shown in Table 7-3.

When the Developer's Bundle is installed and the $RASC variable is set, the user can proceed to experiment with the example implementations.

The comment fields that need to be inserted within the algorithm source or header code are: core services version, algorithm version, sram (denoting where data will be read from and written to on the sram interface), register in (for parameters set through an application writer's code), and register out (for a section of code that needs to be mapped to a debug register).

The comments can be located anywhere within a Verilog, VHDL or header file. They can have Verilog or VHDL syntax (“//” or “- -” respectively). Extractor comments begin with the tag “//extractor” in the source file. The general format is shown below.

//extractor <type>:[<value/specifier1> ... <value/specifierN>] (Verilog)

- - extractor <type>:[<value/specifier1> ... <value/specifierN>] (VHDL)

For details on each extractor comment, see Table 7-6.

A sample of the comments that might be included within a source file is:

// extractor VERSION: 6.3
// extractor CS: 1.0
// extractor SRAM:a_in  2048  64 sram[0] 0x0000 in  u stream
// extractor SRAM:b_in  2048  64 sram[0] 0x4000 in  u stream
// extractor SRAM:c_in  2048  64 sram[0] 0x8000 in  u stream
// extractor SRAM:d_out 2048  64 sram[1] 0x0000 out u stream
// extractor REG_OUT:alg_id 32 u debug_port[0][63:32]
// extractor REG_OUT:alg_rev 32 u debug_port[0][31:0]
// extractor REG_OUT:rd_addr 64 u debug_port[1]
// extractor REG_OUT:rd_data_sram0_lo 64 u debug_port[2]
// extractor REG_OUT:rd_data_sram0_hi 64 u debug_port[3]
// extractor REG_OUT:wr_addr 64 u debug_port[4]
// extractor REG_OUT:wr_data_sram1_lo 64 u debug_port[5]
// extractor REG_OUT:wr_data_sram1_hi 64 u debug_port[6]
// extractor REG_OUT:cntl_sigs 64 u debug_port[7]

Any Makefile variables you want to redefine can be changed using the Makefile.local file. This allows each project you create to use the same base Makefile, but have project-specific customizations in a separate file. The key Makefile variables that are commonly redefined for each project are listed here. Default settings are provided with the Makefile.local version in the templates directory.

Table 7-7 shows common Makefile.local variable settings.

add_file -verilog "$RASC/examples/alg_simple_v/alg_block_top.v"
add_file -verilog "$RASC/examples/alg_simple_v/sort_byte.v”

add_file -edif "$RASC/pd/acs_core/acs_core.edf"

verilog work "../../example/alg_simple_v/alg_block_top.v"

After the Makefile, Makefile.local, and synthesis project file are set up and customized, the next step is to run the make command to generate the bitstream and configuration files for download to the RASC hardware.

FPGA implementation comprises many sub-steps such as synthesis, ngdbuild, map, place-and-route, bitgen, and timing analysis. The user can choose to run the entire flow or individual subsections based on the Makefile target. If no target is specified, the full implementation flow is executed:

% cd $RASC/implementations/alg_simple_v
% make all

Other available targets are described in Table 7-8. The default command is make all.

When synthesizing the full FPGA, including a re-synthesis of the Core Services Block, we only support the use of Synplify Pro. The Core Services Block design has been optimized for use with these tools and results from using another synthesis tool will not likely achieve the same quality-of-results and timing closure. Therefore, the Makefile.local for the full chip project must use the following Makefile variable settings (see Table 7-9).

A synthesis option must be set to allow the Core Services Block to be re-synthesized. This option is in the form of a Verilog compiler directive, which can be added to the synthesis project file with the following TCL command:

set_option -hdl_define -set RESYNTHESIZE_CS=1

This option is commented in the <alg_name>.prj and must be uncommented by the user desiring to re-synthesize the Core Services Block. The rest of the synthesis project should be the same as described earlier.