The SHARED_REGISTER procedure call sets up a shared_register inside the framework module that supports both reading and writing from multiple application modules. Application modules have the capability of reading and writing to the same shared register by making the SHARED_REGISTER procedure call and referencing the same REGISTER_ID. Because any number of application modules have access to the same shared register (or a different one), the SHARED_REGISTER procedure call is said to implement a multipoint control path mechanism, whereas the READ_FIFO_DATA and the WRITE_FIFO_DATA procedure calls implement a point-to-point data path mechanism.

In addition to sharing data between multiple application modules, a single application module has the capability of setting up any number of shared registers for its own private purposes. This is done by making multiple SHARED_REGISTER procedure calls different resource indexes.

In general, an application modules refers to another application module by VHDL entity name but references itself as this_sm. Before compile time, each application modules entity name is mapped to as a constant integer value that specifies the starting resource index assigned to that application module. Thus, it is possible to use an application module entity name as its REGISTER_ID and create unique REGISTER_IDs simply by adding an offset to the application module entity name.

Using a shared register is much more flexible than inferring a normal RTL style register. There is no defined protocol to communicate, however shared registers support multiple writers due to the fact the data is internally 'ORed' or 'ANDed' together by the framework module depending on the default_shared_register_polarity config file parameter. In addition, the bit width of all shared registers is set by the control_width config file parameter. An application module that calls SHARED_REGISTER can choose to write to any range of bits on the shared register and read from a different range provided that the highest indexed bit does not exceed control_width -1. Data is available to be read 1 clock cycle after it is written.

When the SHARED_REGISTER procedure call for writing, data is still placed on the right most bits of data_in. For convince, the optional integer offset parameter can be used to shift the input data range to the left in order to occupy the desired range of bits. When a shared register is only used for reading, the same procedure call is made except that the data_in value is set to 'READ_ONLY'.

Usage Example

Add Example Usage

Example API Call(s):

SHARED_REGISTER( this_sm, read_only, next_state_rec, state_reg_rec );
SHARED_REGISTER( some_module_tb, read_only , next_state_rec, state_reg_rec);
SHARED_REGISTER( some_module, some_data(3 downto 0) , next_state_rec, state_reg_rec, 4 );

Call Data [ 5 parameters (4 mandatory) ]

[in]REGISTER_ID[1] simple index number starting from 0
[in]data_in[2] data to be placed on the shared register or read_only
[in]offset*[5] (optional) integer offset to more 'downto' range to higher bits

Return Data

[in]state_reg_rec(M).shared_register: [1] [std_logic_vector]shared control data returned from the framework

Command Reference

Voice and Hotkey Commands:

See also
Shared Register Commands

Command Parameter Mapping

[in]REGISTER_ID[1] [integer] "index <integer>"
[in]data_in[2] [std_logic_vector] "data (<std_logic_vector>|"read only")"
[in]offset*[5] [integer] "offset <integer>"

Command Return Data

[in]state_reg_rec(M).shared_register: [1] [std_logic_vector] "shared register"

Voice/HotKey Command Sequence

SHARED_REGISTER( example_module, input_vector, next_state_rec, state_reg_rec, 10 );

Voice Command HotKey Sequence
"shared register" sr
"data input vector" data input_vector
"offset ten" offset 10

Notes and Warnings

1) The use of different REGISTER_IDs allows for 'clustering' of application modules, where different groups of application modules share registers that is not shared by other groups.
2) The REGISTER_ID parameter is overloaded for integer and std_logic_vector types, while data_in is overloaded for std_logic, std_logic_vector, std_logic_vector_array, and integers types.

See also


REGISTER_ID: in integer
data_in: std_logic_vector
signal next_state_rec: out NSR
state_reg_rec: in SRR
offset: natural range 0 to NUM_CONTROL_BITS- 1 0
REGISTER_ID: in integer
data_in: std_logic_vector
signal next_state_rec: out NSR_ARRAY
state_reg_rec: in SRR_ARRAY
offset: natural range 0 to NUM_CONTROL_BITS- 1 0
 0verloaded for array next_state_rec and state_reg_rec. REGISTER_ID overloaded for types integer, std_logic_vector.