chipsalliance / aib-protocols

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[1.0] AXI Streaming test failure

nij-intel opened this issue · comments

*** SEQUENCE_START: axist_master_zero_delay_random_sequence
UVM_INFO ./eximius/1.0/llink/dv/axist/tests/ts.zero_delay_random_test.sv(124) @ 4333000: uvm_test_top [zero_delay_random_test] *** MAIN_PHASE_END: zero_delay_random_test
UVM_ERROR ./eximius/1.0/llink/dv/axist/env/axist_scoreboard.sv(856) @ 4366000: uvm_test_top.axist_scb [axist_scoreboard] Transmit tdata:: 59 Not Matched received tdata:: 00
UVM_ERROR ./eximius/1.0/llink/dv/axist/env/axist_scoreboard.sv(870) @ 4367000: uvm_test_top.axist_scb [axist_scoreboard] Transmit tdata:: 0d Not Matched received tdata:: 59
UVM_ERROR ./eximius/1.0/llink/dv/axist/env/axist_scoreboard.sv(870) @ 4367000: uvm_test_top.axist_scb [axist_scoreboard] Transmit tdata:: b7 Not Matched received tdata:: 0d
UVM_ERROR .rs/eximius/1.0/llink/dv/axist/env/axist_scoreboard.sv(870) @ 4368000: uvm_test_top.axist_scb [axist_scoreboard] Transmit tdata:: 84 Not Matched received tdata:: b7
UVM_ERROR ./eximius/1.0/llink/dv/axist/env/axist_scoreboard.sv(870) @ 4368000: uvm_test_top.axist_scb [axist_scoreboard] Transmit tdata:: 58 Not Matched received tdata:: 84

--- UVM Report catcher Summary ---

Number of demoted UVM_FATAL reports : 0
Number of demoted UVM_ERROR reports : 0
Number of demoted UVM_WARNING reports: 0
Number of caught UVM_FATAL reports : 0
Number of caught UVM_ERROR reports : 0
Number of caught UVM_WARNING reports : 0

--- UVM Report Summary ---

Quit count reached!
Quit count : 5 of 5
** Report counts by severity
UVM_INFO : 19
UVM_WARNING : 0
UVM_ERROR : 5
UVM_FATAL : 0
** Report counts by id
[AIB ENV CFG] 1
[MASTER CFG] 1
[MAXQUITSET] 1
[SLAVE CFG] 1
[axist_master_zero_delay_sequence] 1
[axist_scoreboard] 5
[new] 3
[zero_delay_random_test] 11

to reproduce:

./simv +UVM_TESTNAME=zero_delay_random_test +ntb_random_seed=51175275 +UVM_VERBOSITY=UVM_NONE +UVM_MAX_QUIT_COUNT=5 +AIB_IF_COUNT=1 +AIB_CONFIG_DIR=./ +AIB_MASTER_CONFIG_FILE=./master_0_config_aib.dat +AIB_SLAVE_CONFIG_FILE=./slave_0_config_aib.dat -l ./logs/sim_zero_delay_random_test_m2s2.log -cm line+cond+tgl+fsm+branch+assert +nospecify

sent VPD files over

Added a fix to llink_gen.py that should resolve this, but please confirm. The issue is only in AXI-ST with TVALID and without TREADY. It has no effect on LPIF or other AXI configurations. The fix is in a drop called design.release_1.0_2022_02_21.tgz that is the same as the 2/18 drop except for the the llink/script/lllink_gen.py script.

fix did not work uploaded 2 sets of files:

  1. showing error in VPD (with_fix*)
  2. showing compilation error (sb_error*)

This was primarily a TB issue as was explained to Nij. Nij asked I write that up here, so here is that explanation in detail.

The LLINK AXI-ST operates in 3 modes:

  • With TVALID and With TREADY (aka "normal mode")
  • With TVALID and no TREADY
  • With no TVALID and no TREADY (technically illegal per AXIST spec)

I directed the DV team to work on normal mode first, then the no TVALID, no TREADY case. Once those two were done, the With TVALID, and no TREADY case should be somewhere in the middle.

Normal mode is easy enough and plugs into the VIP nicely. However, the no TVALID, no TREADY case is tricky because the VIP requires TVALID on the receive side per AXIST spec, so the TB must "fake" a TVALID for the receive VIP / data. However, it is not immediately clear when to drive the TVALID on the RX side due to the unknown latency of the AIB, channel skew, etc and no VALID to indicate good data. So, since the AIB tends to default to all zeros in reset, in the TB we look for the first non-zero piece of data and assume that is the first beat of data transmitted and drive the receive TVALID and begin the data comparison. For this reason, it is important the first beat of transmitted data not be all 0s. Probabilistically, with 32 bit or even 16 bit TDATA, probabilistically, the odds of hitting all 0s with a random word is pretty low, but for 8 bit data, it is a 1 in 256 chance, so we've added code to exclude this possibility. To be clear, this caveat that the first beat of data be non-zero is only a TB construct and implies no restriction to the DUT itself.

The "with" TVALID with no TREADY case leveraged heavily the no TVALID and no TREADY case, and so it picked up the same requirement that the first beat of data should not be zero. The waves provided by Nij show the 8 bit TDATA case did indeed hit the all 0 case as the first beat, which is why the logs show the data was "off" by one beat of data and the first beat of all 0s was simply dropped. This was the mistake in the code, and it should be more like the "normal" case, where we use the TVALID transmitted to qualify the first beat of data. That is what was changed here, and once that was done, the first beat of data for the normal and "with" TVALID with no TREADY can be any value.

To be clear, we verified the above by forcing the first beat of data to be all 0s and we successfully received the data. We still cannot reproduce the exact same simulation with the same SEED. But I expect this to be fixed in 1.0.1.

fixed in 1.0.1