syn.directive.bind_storage - 2024.1 English

Description

Vitis HLS assigns arrays in the code using specific memory resources (or types). The tool automatically determines the resource to use. Alternatively, you can define syn.storage to generally specify the memory type, as explained in Storage Configuration.

The syn.directive.bind_storage command assigns a specific variable in the code (an array, or function argument) to a specific memory type (type) in the RTL. For example, you can use the syn.directive.bind_storage command to specify which type of memory, and which implementation to use for an array variable. Also, this allows you to control whether the array is implemented as a single or a dual-port RAM.

You can also use the latency option of syn.directive.bind_storage to specify the latency of the implementation. For block RAMs on the interface, the latency option allows you to model off-chip, non-standard SRAMs at the interface, for example supporting an SRAM with a latency of 2 or 3. For internal operations, the latency option allows the operation to be implemented using more pipelined stages. These additional pipeline stages can help resolve timing issues during RTL synthesis.

Syntax

syn.directive.bind_storage=[OPTIONS] <location> <variable>

• <location> is the location (in the format function[/label]) which contains the variable.
• <variable> is the variable to be assigned.
  Tip: If the variable is an argument of a top-level function, then use the storage_type and storage_impl options of syn.directive.interface.

Options

type=<value>

Defines the type of memory to bind to the specified variable.

Supported types include: fifo, ram_1p, ram_1wnr, ram_2p, ram_s2p, ram_t2p, rom_1p, rom_2p, and rom_np.

Table 1. Storage Types

Type	Description
FIFO	A FIFO. Vitis HLS determines how to implement this in the RTL, unless the -impl option is specified.
RAM_1P	A single-port RAM. Vitis HLS determines how to implement this in the RTL, unless the -impl option is specified.
RAM_1WNR	A RAM with 1 write port and N read ports, using N banks internally.
RAM_2P	A dual-port RAM that allows read operations on one port and both read and write operations on the other port.
RAM_S2P	A dual-port RAM that allows read operations on one port and write operations on the other port.
RAM_T2P	A true dual-port RAM with support for both read and write on both ports.
ROM_1P	A single-port ROM. Vitis HLS determines how to implement this in the RTL, unless the -impl option is specified.
ROM_2P	A dual-port ROM.
ROM_NP	A multi-port ROM.

Tip: If you specify a single port RAM for a PIPO, then the binder will typically allocate a merged-PIPO, with only one bank, and reader and writer accessing different halves of the bank. The info message reported by the HLS compiler says "Implementing PIPO using a single memory for all blocks." This is often cheaper for small PIPOs, where all banks can share a single RAM block. However, if you specify a dual-port RAM for a PIPO to get higher bandwidth and the scheduler uses both ports either in the producer or in the consumer, then the binder will typically allocate a split-PIPO, where the producer will use 1 port and the consumer 2 ports of different banks. The info message reported by the HLS compiler in this case says "Implementing PIPO using a separate memory for each block."

impl=<value>

Defines the implementation for the specified memory type. Supported implementations include: bram, bram_ecc, lutram, uram, uram_ecc, srl, memory, and auto as described below.

Table 2. Supported Implementation

Name	Description
MEMORY	Generic memory for FIFO, lets the Vivado tool choose the implementation.
URAM	UltraRAM resource
URAM_ECC	UltraRAM with ECC
SRL	Shift Register Logic resource
LUTRAM	Distributed RAM resource
BRAM	Block RAM resource
BRAM_ECC	Block RAM with ECC
AUTO	Vitis HLS automatically determine the implementation of the variable.

Table 3. Supported Implementations by FIFO/RAM/ROM

Type	Command/Pragma	Scope	Supported Implementations
FIFO	bind_storage 1	local	AUTO, BRAM, LUTRAM, URAM, MEMORY, SRL
FIFO	config_storage	global	AUTO, BRAM, LUTRAM, URAM, MEMORY, SRL
RAM* | ROM*	bind_storage	local	AUTO BRAM, BRAM_ECC, LUTRAM, URAM, URAM_ECC
RAM* | ROM*	config_storage 2	global	N/A
RAM_1P	set_directive_interface s_axilite -storage_impl	local	AUTO, BRAM, URAM
	config_interface -m_axi_buffer_impl	global	AUTO, BRAM, LUTRAM, URAM
When no implementation is specified the directive uses AUTOSRL behavior as a default. However, this value cannot be specified. config_storage only supports FIFO types.

latency=<int>

Defines the default latency for the binding of the storage type to the implementation. The valid latency varies according to the specified type and impl. The default is -1, which lets Vitis HLS choose the latency.

Examples

In the following example, the coeffs[128] variable is an argument of the function func1. The directive specifies that coeffs uses a single port RAM implemented on a BRAM core from the library.

syn.directive.bind_storage=func1 coeffs type=RAM_1P impl=bram

See Also

• syn.directive.bind_op