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.
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.
function new( |
| ); |
Constructor to create a new AXI master write driver axi_mst_wr_driver. ~name~ is the name of the instance.
function void set_vif( |
| ); |
Assigns the virtual interface vif to the virtual interface of axi_mst_wr_driver.
function void set_bready_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.
Returns bready_gen of the AXI master write driver
function void set_forward_progress_timeout_value ( |
| ); |
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.
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.
function void set_waiting_valid_timeout_value ( |
| ); |
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.
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.
function void set_transaction_depth( |
| ); |
Sets the number of transactions that the Driver will have in flight at one time.
Returns the maximum number of transactions that the Driver will have in flight at one time.
function void set_awaddr_watchdog_delay( |
| ); |
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.
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.
Returns the current state of adjust_addr_delay_enabled.
virtual function void set_adjust_addr_delay_enabled( |
| ); |
Sets the value of adjust_addr_delay_enabled of the transaction.
Returns the current state of adjust_data_beat_delay_enabled.
virtual function void set_adjust_data_beat_delay_enabled( |
| ); |
Sets the value of adjust_data_beat_delay_enabled of the transaction.
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.
Returns number of transactions in flight
Start control processes for operation
Stops all control processes.
Allows for all inflight transactions to complete and no new transaction will be serviced. All other transactions will halt in axi_mst_wr_driver.
Resumes processing of the pending transactions in <axi_mst_rd_drive>.
task send( |
| ); |
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
task wait_rsp( |
| ); |
This blocking function will not return until driver send back response transaction of <axi_mst_wr_driver>.please refer example design for the usage.
virtual function axi_transaction create_transaction ( |
| ); |
Returns an axi transaction class that has been "newed" of <axi_mst_wr_driver>.please refer example design for the usage.
task send_bready( |
| ); |
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.
virtual function axi_ready_gen create_ready ( |
| ); |
Returns a ready class that has been "newed".
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.