
Mentor VIP AE AXI3/4 User Guide, V10.2b
152
SystemVerilog Tutorials
Verifying a Slave DUT
September 2013
The write transaction, trans1, is then executed onto the protocol signals by calling the
execute_write_addr_phase() and execute_write_data_burst() functions in parallel within a
fork.. join_any statement. By calling the execute_write_addr_phase() and
execute_write_data_burst() functions in parallel, subsequent address phase transactions can be
transmitted before the write data burst has completed.
Example 6-15. Outstanding Write Burst Transaction Creation and Execution
/************************
** Traffic generation: **
************************/
// 4 x Writes
// Write data value to address 0.
trans1 = bfm.create_write_transaction(0,3); //Burst length=3+1
trans1.set_data_words('hACE0ACE1, 0);
trans1.set_data_words('hACE2ACE3, 1);
trans1.set_data_words('hACE4ACE5, 2);
trans1.set_data_words('hACE6ACE7, 3);
for(int i=0; i<4; i++)
trans1.set_write_strobes(4'b1111, i);
$display ( "@ %t, master_test_program: Writing data (1) to address (1)",
$time);
fork
bfm.execute_write_addr_phase(trans1);
bfm.execute_write_data_burst(trans1);
join_any
Subsequent write transactions are created and assigned to unique variables, trans2, trans3,
trans4, etc., allowing multiple write transactions to exist at the same time. The write
transactions are then executed in a similar manner to that shown in Example 6-6, resulting in
outstanding write transactions. See the SystemVerilog AXI4 Master BFM Test Program code
listing for details.
handle_write_resp_ready()
The handle_write_resp_ready() task handles the BREADY signal for the write response
channel. In a forever loop it delays the assertion of the BREADY signal based on the settings of
the master_ready_delay_mode and m_wr_resp_phase_ready_delay as shown in Example 6-16.
If the master_delay_ready_mode = AXI4_VALID2READY then the BREADY signal is
immediately deasserted using the nonblocking call to the execute_write_resp_ready() task and
waits for a write channel response phase to occur with a call to the blocking
get_write_response_cycle() task. A received write response phase indicates that the BVALID
signal has been asserted, triggering the starting point for the delay of the BREADY signal by the
number of ACLK cycles defined by m_wr_resp_phase_ready_delay. After the delay another
call to the execute_write_resp_ready() task to assert the BREADY signal completes the
BREADY handling. The seen_valid_ready flag is set to indicate the end of a response phase
when both BVALID and BREADY are asserted, and the completion of the write transaction.
Komentarze do niniejszej Instrukcji