Subsections

7 Supported Platforms

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

1 Altera based devices

Notice that TCE does not contain the vendor specific IP components such as on-chip memory components. In order to simulate and synthesize the hardware you need to have Altera Quartus II software and libraries installed.


1 Stratix2DSP

Stratix2DSP integrator is targeted to integrate TTA core onto a Stratix II DSP Pro board with EP2S180F1020C3 FPGA device. 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 AG18 which is connected SW8/CPU RESET pushbutton on the FPGA board. Pin AG18 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 Stratix3DevKit

Stratix3DevKit integrates a TTA core onto the Stratix III FPGA Development Kit board from Altera with an EP3SL150F1152C2 FPGA device. Default clock signal is routed to 125 MHz oscillator connected to pin B16. Active low reset is connected to CPU RESET button on pin AP5.

Board specific function units are stored in stratixIII.hdb. For successfull integration, you must select the Load Store Unit from this HDB. This integrator will create project files for Altera Quartus II software in the same manner as Stratix2DSP integrator (see subsection 4.7.1.1).

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...
...ith\_bytemask (FU entry ID
1) which is stored in stratixIII.hdb.
\end{longtable}

3 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.

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.7.1.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.

4 KoskiIntegrator

Koski Integrator can be used to create a Koski/Kactus2 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 FPGA devices.

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.7.1.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.

2 AlmaIFIntegrator

AlmaIF Integrator can be used to create an AlmaIF-compatible processor wrapper for a TTA processor. AlmaIF is a simple control interface that can be used for control and debug access to devices in a system-on-a-chip. Due to the constrants placed by the specification, the TTA processor must have data and parameter memory spaces. The integrator recognizes these by the address space names, which should be set to 'data' and 'param' respectively. These memory spaces and instruction memory can be accessed through the AXI4 interface presented by the processor wrapper. Both data and parameter memory spaces must have 32-bit data width; instruction memory does not have this constraint. All other memory spaces are mapped as scratchpad memory, inaccessible from the AXI bus.

The LSU compatible with this integrator can be found in almaif.hdb. Currently it is the only function unit shipped with TCE which implements this interface. This means that the only option for data and instruction memory type is 'onchip'. The memories will be synthesized as Xilinx-compatible single port block RAM.

Because the control interface for AlmaIF is implemented through the external debugger interface, this must be enabled from the Implementation-dialog's IC / Decoder Plugin tab by setting the bustrace plugin parameter as 'external'.

Usage example:
There's a processor with AlmaIF LSU and external debugger interface, and the toplevel entity will be named 'almaif_tta'. Command is

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

Pekka Jääskeläinen 2016-11-24