axi_mst_wr_driver

AXI Master Write Driver object.

The Driver will issue drive on the commands on the AW channel and payload on the W channel.

It will declare the transaction as complete when the B channel is acknowledge with the same ID.

Receives WRITE transactions from the user environment and drives the AW and W channels.

Trigger an event when the AW Command is accepted.

Trigger an event when the WLAST is accepted.

Receives READY transactions from the user environment and drives the BREADY signal of the B channel.

Collects and re-orders B Channel response and returns a completed transaction when the B channel is accepted.

Information
class member

axi_vif_mem_proxy `AXI_PARAM_ORDER vif_proxy; AXI VIF Proxy Class

xil_seq_item_pull_port #(axi_transaction,axi_transaction) seq_item_port; provides method to send read transaction to axi_mst_wr_driver

xil_seq_item_pull_port #(axi_ready_gen, axi_ready_gen) bready_seq_item_port; provides the method to send bready information to axi_mst_wr_driver.

Functions
new

function new( |
string | name | = | "unnamed_axi_mst_wr_driver"
| );

Constructor to create a new AXI master write driver axi_mst_wr_driver. ~name~ is the name of the instance.

set_vif

function void set_vif( |
axi_vif_mem_proxy ` | AXI_PARAM_ORDER | vif
| );

Assigns the virtual interface vif to the virtual interface of axi_mst_wr_driver.

set_bready_gen

function void set_bready_gen( |
input | axi_ready_gen_t | new_gen
| );

Sets bready_gen of the AXI master write driver. There are three ways for bready generation in AXI master write driver. 1.User can first create a axi_ready_gen, customerize it and then use set_bready_gen to send it to AXI master write driver.User can't fill in more than 500 axi_ready_gen at one time, otherwise it will error out.

2.User can can first create a axi_ready_gen, customerize it and then use send_bready to send it to AXI master write driver.

3. If neither of above method is being called, then AXI master write driver will a) if XIL_DO_NOT_USE_ADV_RANDOMIZATION is being defined, bready is being generated with cheap_random(this is for tools which doesn't support advanced randomization. b) else bready will be randomly generated.

get_bready_gen
function axi_ready_gen_t get_bready_gen();

Returns bready_gen of the AXI master write driver

set_forward_progress_timeout_value

function void set_forward_progress_timeout_value ( |
input | xil_axi_uint | new_timeout
| );

Sets the number of cycles that the driver will wait for AW/W/B accepted until it will flag a watch dog error of the axi_mst_wr_driver. Default value is 50000. Setting this to a very large value will cause a hung simulation to continue for a longer time. Setting this to a very small number may not allow enough time for simulation to respond.

get_forward_progress_timeout_value
function xil_axi_uint get_forward_progress_timeout_value ();

Returns the number of cycles that the driver will wait for AW/W/B accepted until it will flag a watch dog error of the axi_mst_wr_driver. Default value is 50000 and user can use set_forward_progress_timeout_value to change it.

set_waiting_valid_timeout_value

function void set_waiting_valid_timeout_value ( |
input | xil_axi_uint | new_timeout
| );

Sets waiting_valid_timeout_value of the <axi_mst_wr_driver>.waiting_valid_timeout_value is used for driver to wait a certain number of cycles for bvalid/bready, awvalid/awready and wvalid/wready handshake occurs before it time out.

get_waiting_valid_timeout_value
function xil_axi_uint get_waiting_valid_timeout_value ();

Returns waiting_valid_timeout_value of the axi_mst_wr_driver. waiting_valid_timeout_value is used for driver to wait a certain number of cycles for bvalid/bready, awvalid/awready and wvalid/wready handshake occurs before it time out.

set_transaction_depth

function void set_transaction_depth( |
input | xil_axi_uint | new_depth
| );

Sets the number of transactions that the Driver will have in flight at one time.

get_transaction_depth
function xil_axi_uint get_transaction_depth();

Returns the maximum number of transactions that the Driver will have in flight at one time.

set_awaddr_watchdog_delay

function void set_awaddr_watchdog_delay( |
input | xil_axi_uint | new_depth
| );

Sets awaddr_watchdog_delay of the axi_mst_wr_driver. When axi_transaction's xfer_wrcmd_order is XIL_AXI_WRCMD_ORDER_DATA_BEFORE_CMD and get_allow_data_before_cmd() greater than zero, AW channel of axi_mst_wr_driver will fire watchdog AXI_WR_MST_ORDER_DATA_BEFORE_CMD WATCHDOG fired if it doesn't see enough beat_counts as desired after waiting awaddr_watchdog_delay clock cycles.

get_awaddr_watchdog_delay
function xil_axi_uint get_awaddr_watchdog_delay();

Returns awaddr_watchdog_delay of the <axi_mst_wr_driver>.awaddr_watchdog_delay is the number of clock cycles axi_mst_wr_driver waits before it fires watchdog AXI_WR_MST_ORDER_DATA_BEFORE_CMD when AW channel does not have enough payload beats.

get_adjust_addr_delay_enabled
virtual function xil_axi_boolean_t get_adjust_addr_delay_enabled();

Returns the current state of adjust_addr_delay_enabled.

set_adjust_addr_delay_enabled

virtual function void set_adjust_addr_delay_enabled( |
input | xil_axi_boolean_t | update
| );

Sets the value of adjust_addr_delay_enabled of the transaction.

get_adjust_data_beat_delay_enabled
virtual function xil_axi_boolean_t get_adjust_data_beat_delay_enabled();

Returns the current state of adjust_data_beat_delay_enabled.

set_adjust_data_beat_delay_enabled

virtual function void set_adjust_data_beat_delay_enabled( |
input | xil_axi_boolean_t | update
| );

Sets the value of adjust_data_beat_delay_enabled of the transaction.

is_driver_idle
function xil_axi_boolean_t is_driver_idle();

Returns TRUE if driver is idle(no outstanding write command from write address channel, no outstanding data from write data channel,no outstanding write response from write response channel), else FALSE.

get_num_transactions_inflight
function xil_axi_uint get_num_transactions_inflight();

Returns number of transactions in flight

run_phase
task run_phase();

Start control processes for operation

stop_phase
virtual task stop_phase();

Stops all control processes.

halt_phase
virtual task halt_phase();

Allows for all inflight transactions to complete and no new transaction will be serviced. All other transactions will halt in axi_mst_wr_driver.

resume_phase
virtual task resume_phase();

Resumes processing of the pending transactions in <axi_mst_rd_drive>.

send

task send( |
input | axi_transaction | t
| );

Sends the AXI transaction to axi_mst_wr_driver. Usually user would create a new axi_transaction by calling create_transaction of axi_mst_wr_driver, either randomize the transaction or set it up. Then it calls send to send the transaction to axi_mst_wr_driver. It is a blocking process. please refer example design for the usage

wait_rsp

task wait_rsp( |
output | axi_transaction | t
| );

This blocking function will not return until driver send back response transaction of <axi_mst_wr_driver>.please refer example design for the usage. NOTE: The driver_return_item_policy of the transaction must be set to XIL_AXI_PAYLOAD_RETURN or XIL_AXI_CMD_PAYLOAD_RETURN. The default is NO_RETURN and this policy causes wait_rsp to hang

create_transaction

virtual function axi_transaction create_transaction ( |
string | name | = | "unnamed_transaction"
| );

Returns an axi transaction class that has been "newed" of <axi_mst_wr_driver>.please refer example design for the usage.

send_bready

task send_bready( |
input | axi_ready_gen | t
| );

Sends the ready structure to the axi_mst_wr_driver for controlling the READY channel. Usually user would create a new axi_ready_gen by calling create_ready of axi_mst_wr_driver, either randomize the bready or set it up manually. Then it calls send to send the bready to axi_mst_wr_driver.

create_ready

virtual function axi_ready_gen create_ready ( |
string | name | = | "unnamed_ready"
| );

Returns a ready class that has been "newed".

wait_driver_idle
task wait_driver_idle();

This is a blocking task which will wait until there are no outstanding transactions in the axi_mst_wr_driver. This means that all the transactions send to the driver have received a corresponding B channel response.