Subsections


4 Processor Generator (ProGe)

Processor Generator (ProGe) produces a synthesizable hardware description of a TTA target processor specified by an architecture definition file (Section 2.2.1) and implementation definition file (Section 2.2.3).

Input: HDB, ADF, IDF

Output: VHDL implementation of the processor

There is a command line client for executing this functionality, but the functionality can also be used in the Processor Designer (Section 4.1). This section is a manual for the command line client.

Processor generation can be customized with plugin modules. The customizable parts are the generation of control unit and the interconnection network.

The CLI-based version of the processor generator is invoked by means of a command line with the following syntax:

generateprocessor <options> target

The sole, mandatory argument target gives the name of the file that contains the input data necessary to generate the target processor. The file can be either a processor configuration file or an architecture definition file. If the file specified is a PCF, then the names of ADF, BEM and IDF are defined in it.

The given PCF may be incomplete; its only mandatory entry is the reference to the ADF that defines the architecture of the target processor. If the file specified is an ADF, or if PCF does not contain BEM and IDF references, then a BEM is generated automatically and the default implementation of every building block that has multiple implementations is used.

The processor architecture must be synthesizable, otherwise an error message is given.


\begin{longtable}[htb]{@{}p{.10\textwidth}@{}p{.20\textwidth}%
@{}p{.65\textwid...
...y. Even though other options are ignored they must
be valid.
\\
\end{longtable}

1 IC/Decoder Generators

IC/Decoder generators are implemented as external plug-in modules. This enables users to provide customizable instruction decoder and IC implementations without recompiling or modifying the existing code base. One can easily add different plug-ins to experiment with different implementation alternatives, and as easily switch from one to another plug-in. To create a new plug-in, a software module that implements a certain interface must be created, compiled to a shared object file and copied to appropriate directory. Then it can be given as command line parameter to the generator.

2 Platform Integrator

Processor Generator supports automated integration of TTA cores to different FPGA platforms. The main use case for platform integrator is to create IP-components out of TTAs for SoC designs for vendor-specific system level design flows. In addition, standalone processor integration to FPGA chips is supported. Platform Integrator is invoked with switches to the generateprocessor command.

Platform Integrator specific command line parameters are the following:


\begin{longtable}[htb]{@{}p{.10\textwidth}@{}p{.20\textwidth}%
@{}p{.65\textwid...
...ert program\vert &
Name of tpef program. \textbf{Required}.
\par
\end{longtable}

Here is an example how to use platform integrator:

generateprocessor -i arch.idf -o proge-output -g Stratix2DSP -d onchip -f vhdl_array -e FFTmuncher -p fft_app.tpef arch.adf

This command would try to integrate processor arch.adf to Stratix2DSP FPGA board using vhdl rom array for instruction memory and FPGA's onchip memory for data memory. HDL files created by Platform Integrator be stored to directory proge-output/platform and project files etc. are written to current working directory.

3 Supported Platforms

This section introduces the Platform Integrators which are shipped with TCE.


1 Stratix2DSP

Stratix2DSP integrator is targeted to integrate TTA core onto a Stratix II DSP Pro board with EP2S180F1020C3 FPGA device. This integrator requires that Altera Quartus II has been installed and the executables are found from the PATH. The integrator automatically invokes 'qmegawiz' program to generate onchip memories.

By default, integrator maps the processor clock signal (clk) to FPGA pin AM17 which provides 100 MHz clock signal from an oscillator. Reset signal (rstx), which is active low, is mapped to FPGA pin J13 which is connected SW7/USER_PB pushbutton on the FPGA board. Pin J13 will be connected to ground when this button is pressed down thus reseting the processor.

Interfacing to FPGA board components can be done by using function units stored in stratixII.hdb. External ports of these function units will be automatically mapped to FPGA pins. It is also vital that the load store unit of the processor is selected from this HDB, otherwise integrator will fail to create the memory component mappings. Unidentified external ports will be connected to the new toplevel entity but they are not mapped to any FPGA pin by default. In this case, the integrator will give a warning message: ``Warning: didn't find mapping for signal name <signal>''.

Stratix2DSP integrator will also generate project files for Altera Quartus II software. These files will be written to the current working directory and they are named as <entity_name>.qpf and <entity_name>.qsf. Project files contain device settings, pin mappings and lists design HDL files. The integrator also creates a quartus_synthesize.sh shell script which will execute the synthesis process and quartus_program_fpga.sh which can be used to program the FPGA after successful synthesis.

Available instruction memory types are:


\begin{longtable}[htb]{@{}p{.20\textwidth}%
@{}p{.80\textwidth}}
\par
\textbf{M...
... type is used. Updating instruction memory requires resynthesis.
\end{longtable}

Available data memory types are:


\begin{longtable}[htb]{@{}p{.20\textwidth}%
@{}p{.80\textwidth}}
\par
\textbf{M...
...that data memory will be uninitialized when this option
is used.
\end{longtable}

Usage examples:

  1. There's a processor with onchip memory compatible LSU and instruction memory will also use onchip memory. Let the name of the new toplevel entity be example1. Command to execute Stratix2DSP integrator is
    generateprocessor -i proc.idf -o proge-out -g Stratix2DSP -d onchip -f onchip -e example1 -p program.tpef proc.adf

  2. Same case as before, but now we want to specify target clock frequency of 150 MHz. Quartus II will then try to reach the specified clock frequency in synthesis process. Command is
    generateprocessor -i proc.idf -o proge-out -c 150 -g Stratix2DSP -d onchip -f onchip -e example1 -p program.tpef proc.adf

    Notice that the clock signal will still be connected to a 100 MHz clock oscillator. You'll have to provide the 150 MHz clock signal yourself. This can be done for example by instantiating and connecting a PLL component in proge-out/platform/example1.vhdl file, which is the new toplevel HDL file.

  3. There's a processor with SRAM compatible LSU and instruction memory will be implemented as VHDL array. In addition we wish to use absolute paths in project files. Command is then
    generateprocessor -i proc.idf -o proge-out -a -g Stratix2DSP -d sram -f vhdl_array -e example1 -p program.tpef proc.adf

2 AvalonIntegrator

AvalonIntegrator can be used to create an Altera SOPC Builder component from TTA processor which includes a function unit that implements Avalon Memory Mapped Master interface. This integrator requires that Altera Quartus II has been installed and the executables are found from PATH. The integrator automatically invokes 'qmegawiz' program to generate onchip memories.

Function units which implement the Avalon Memory Mapped Master interface are stored in avalon.hdb. There are two ways of interfacing with the Avalon bus:

  1. The load-store unit implements the Avalon MM Master interface. The load store unit implementation must be mapped to avalon_lsu which is stored in avalon.hdb. In this method the data memory is selected in SOPC Builder and thus the data memory type parameter must be set to 'none' when integrator is executed. Due to the lack of memory mapper in the current TCE version, the data memory address space must be set to start from 0 in SOPC Builder. Also the size of data memory should match the data memory address space size defined in ADF. It is also possible to include Avalon SFU (see the next bullet) to a processor which has an Avalon LSU but the same data memory restrictions still apply.

  2. A special function unit implements the Avalon MM Master interface. In this case a special function unit (SFU) is used to interface with Avalon and custom operation macros must be used to communicate with other Avalon components. This SFU is called avalon_sfu and it's stored in avalon.hdb. It is also possible to include multiple Avalon SFUs to the processor but currently there is no method to differentiate which SFU is used from C code.

In both cases the instruction memory of TTA is not visible to nor accessible via Avalon. Instruction memory options are the same for Avalon Integrator as for Stratix2DSP Integrator. See section 4.4.3.1 for more information.

Supported data memory configurations are:


\begin{longtable}[htb]{@{}p{.20\textwidth}%
@{}p{.80\textwidth}}
\par
\textbf{M...
...LSU implementation is quite generic for Altera onchip memories).
\end{longtable}

Avalon Integrator creates a SOPC Builder component file <entity_name>_hw.tcl to current working directory. This file can be used to import the TTA processor to the SOPC Builder component library. It can be done by either editing the IP search path from SOPC Builder's options or adding a new component using the created tcl-file.

If the processor has other function units with external ports, these external ports are connected to the interface of the new toplevel entity. These ports are then added to a conduit interface in the SOPC Builder component file which means that they will also be exported out of the SOPC Builder design.

Usage examples:

  1. A TTA with an Avalon LSU. Because of this, the data memory type must be set to 'none'. Instruction memory is reserved from onchip memory in this case. Let the name of the new toplevel entity be tta_sopc. The command to execute Avalon Integrator is

    generateprocessor -i proc.idf -o proge-out -a -g AvalonIntegrator -d none -f onchip -e tta_sopc -p program.tpef proc.adf

    The integrator will generate file tta_sopc_hw.tcl which can be used to import the component to SOPC Builder.

  2. A TTA with an Avalon SFU, the instruction memory is implemented as VHDL array and data memory is reserved from the FPGA's internal memory. Let the name of the new toplevel entity be tta_sopc. Command is

    generateprocessor -i proc.idf -o proge-out -a -g AvalonIntegrator -d onchip -f vhdl_array -e tta_sopc -p program.tpef proc.adf

    Integrator will generate file tta_sopc_hw.tcl which can be used to import the component to SOPC Builder. Avalon SFU must be used with custom operation macros from C code. These macros are named as _TCE_AVALON_<memory_operation>. For example _TCE_AVALON_STW(addr, data) performs 32-bit store operation to address addr.

  3. A TTA with an Avalon LSU and an Avalon SFU. Because Avalon LSU is used, data memory type must be set to 'none'. Instruction memory is reserved from the onchip memory in this case. Let the name of the new toplevel entity be dual_avalon_tta_sopc. Command is

    generateprocessor -i proc.idf -o proge-out -a -g AvalonIntegrator -d none -f onchip -e dual_avalon_tta_sopc -p program.tpef proc.adf

    The integrator will generate file dual_avalon_tta_sopc_hw.tcl which can be used to import the component to SOPC Builder. Component will now have 2 Avalon Memory Mapped Master interfaces.

3 KoskiIntegrator

Koski Integrator can be used to create a Koski toolset compatible IP blocks from TTA processors. The integrated TTA must have an function unit that interfaces with HiBi bus to be compatible with this integrator. Currently this integrator only works with Altera FPGAs and requires Quartus II toolset to be installed and found from PATH.

HiBi compatible load store unit can be found from hibi_adapter.hdb. Currently it is the only function unit shipped with TCE which implements the HiBi interface. This means that the only option for data memory type is 'onchip'. In addition, the onchip memory is generated as a dual port ram which means that the FPGA device must have support for dual port onchip memories.

Instruction memory options are the same as for Stratix2DSP integrator. See section 4.4.3.1 for more information.

Koski Integrator will generate an IP-XACT (version 1.2) description file of the integrated component. File is written to the current working directory and it is named as spirit_comp_def_<entity_name>.xml. This file is used to import the created TTA IP-component to Koski tools.

Usage example:
There's a processor with HiBi LSU and instruction memory is implemented using FPGA's internal memory and toplevel entity will be named as 'koski_tta'. Command is then:

generateprocessor -i proc.idf -o proge-out -a -g KoskiIntegrator -d onchip -f onchip -e koski_tta -p program.tpef proc.adf

Integrator creates IP-XACT file 'spirit_comp_def_koski_tta.xml' to current working directory.



Footnotes

...$ GCU.$[*]
In the initial version, the only keyword accepted is `vhdl'.
Pekka Jääskeläinen 2011-12-08