The SGI Core Services, described in Chapter 3, “RASC Algorithm FPGA Hardware Design Guide”, are designed to interact with the algorithm that you are creating. Certain configuration files are necessary to ensure that the Core Services and the algorithm are both aware of the resources in use. Prior to the RASC 2.20 release, these configuration files needed to be hand-edited based on templates provided with the RASC software source code.
The SGI RASC Algorithm Configuration Wizard enables you to select the resources to be used in a given algorithm through a GUI. Core Services features, such as, streaming direct memory access (DMA), memory resources, algorithm defined registers (ADRs), and debug degristers can be configured.
The tool then creates the customized files required to integrate the algorithm design with Core Services and the implementation scripts used to generate a bitstream from the source code.
This chapter covers the following topics:
The SGI RASC Algorithm Configuration Wizard is a Tool Command Language (TCL) script located in the $RASC/design/tools directory. You must run it in the same filesystem as the source code. To run the script , perform the following:
The welcome screen appears, as shown in Figure 8-1.
Every screen in the Wizard allows you to cancel your configuration and exit the tool without updating the output design and implementation files. The following sections in this chapter will walk you through using the Wizard. Click Start to begin the configuration steps.
The algorithm name is used to create the directories for the design files and the implementation files. It is also used as a way of attaching constraint files to the design during the implementation steps of the bitstream. Enter the name of your algorithm, as shown in Figure 8-2.
Since the algorithm name is used to create directories in which to place the output files, it is highly recommended that the you use an algorithm name that conforms to Unix/Linux directory names.
The SGI Core Services provide an algorithm clock that enables communication between the Core Services and the algorithm interfaces. There are four acceptable frequencies for this clock. For more information on the algorithm clock rate, see “FPGA Clock Domains” in Chapter 3.
You can select one of the available frequencies, as shown in Figure 8-3. A supplemental clock is available at a later configuration stage.
SGI Core Services provide four input and four output streaming DMA engines that allow data to transfer directly into the FPGA. These are individually selectable and you may select them in any combination using the interface, as shown in Figure 8-4.
There are three acceptable and mutually exclusive memory configurations allowed in RASC Core Services. The first is the same as the configuration found in the prior RASC 2.1 release. This configuration pairs up two 64-bit memory ports to be used as a 128-bit memory. There is a fifth 64-bit memory port available in this configuration.
A new configuration is available in the RASC 2.20 release (and later) to enable five 64-bit memory ports. All five of these ports are independent and can be configured individually.
You may also decide that you do not need memory ports and all data will flow in and out through the streaming DMA engines. This enables an area optimization by removing the memory interfaces from the integrated design.
Select the appropriate memory configuration, as shown in Figure 8-5.
Once your memory configuration has been selected you can make further optimizations and usage directions, as shown in Figure 8-6. This screen has four columns. The first, leftmost, column has checkboxes that, when checked, enable the use of the port. If the checkbox is clear, the port will be configured out of the design, and the area will be optimized.
The second and third columns define the ports of the memory that the algorithm intends to make use of. The algorithm can read and/or write each of the memory ports based on the checkboxes in these columns.
The rightmost column enables further area optimization. If the algorithm intends to make use of the memory as a scratchpad or temporary storage, and the algorithm intends to take responsibility to move the data, you can check the box in the Alg Only column and thus eliminate the core services DMA connections and arbitration to that memory port.
The SGI Core Services provides up to 64 registers to handle the communication between the host program and the bitstream. The number of registers is selected using the slider, as shown in Figure 8-7.
The algorithm defined registers can be further specified for usage, as shown in Figure 8-8.
Core Services provides up to sixty-four (64) 64-bit debug registers. These registers are up to the algorithm author to specify, and they can be read through GNU Debugger (GDB). For more information about the debug registers and the GDB, see “Using the GNU Project Debugger (GDB)” in Chapter 9. These registers are also specified using a slider, as shown in Figure 8-9.
The SGI generated implementation scripts support two synthesis tools: Synplify Pro and Xilinx XST. Since Xilinx XST is part of the Xilinx ISE Foundation, it is selected as default, as shown in Figure 8-10. Xilinx and SGI recommend Synplify Pro for the highest quality of results, and if it is available, checking this box will ensure that the proper Synplify Pro scripts will be generated.
A supplemental algorithm clock is provided by the Core Services. This clock is configured according to the Xilinx Virtex 4 User's Guide. It involves the specification of a numerator and a divisor for a scaling factor, as shown in Figure 8-11.
The checkbox at the top of the window enables the use of the supplemental clock. The two lower boxes enable the specification of the numerator and divisor.
This is the last step of the configuration. Clicking Write Config Files will generate the proper scripts.
The output files are split into two categories. The first is the design category. These are Verilog files that are placed in the design tree. They are located at:
The second category is implementation scripts. These scripts are used to feed the synthesis and implementation tools, and they can be found at:
If the algorithm name specified already exists, there may already be files in these locations that can be overwritten (see Figure 8-12).
|Note: The alg_block_top.v file may contain the user algorithm code that will be overwritten during this reconfiguration stage. It is important to save any of the logic in this file elsewhere and replace it in the newly generated alg_block_top.v file. Save the orginal file to alg_block_top.v.backup.|
If the files are writable, clicking Continue will generate the proper files and exit the Wizard.
If this is a reconfiguration, and the files are not writable, you will see the write-protect file notification, as shown in Figure 8-13.
This screen displays the filenames for files that exist and are write-protected. A change in the permissions of these files, or a change in the algorithm name is required before the files can be written. The screen can be closed, and you are sent back to the final stage of configuration. If you have changed permissions, you may select Write Config Files again, and the files will be generated and the program will exit. If you wish to change the algorithm name instead, you may use the Back buttons to return to the algorithm name configuration, or you may exit the Wizard and start over.