[VTA][Runtime] fix hardcoded VerifyDep step

[zhanghaohit]

Bug Description

VerifyDep hardcode step check of 2, which is not true in other dependence settings (e.g., if we change the acc dependence distance in VTA hardware implementation)

Solution

add ACC_DEP_DISTANCE in vta_config.json and use that to derive checking step.

ACC_DEP_DISTANCE is also used in VTA hardware implementation when defining acc dependence distance (see here)

[zhanghaohit]

@tqchen @tmoreau89 Could you kindly help review this PR? Thanks.

[tmoreau89]

Thanks @zhanghaohit for the proposed change, moving away from a hardcoded value is the right move!

I find the ACC_DEP_DISTANCE to be confusing however. Ultimately it's derived from the latency (in cycles) it takes for a write to address X to be visible on the read port at address X. Maybe we can dub this SRAM_WRITE_TO_READ_LATENCY or something along those lines?

[zhanghaohit]

Thanks @zhanghaohit for the proposed change, moving away from a hardcoded value is the right move!

I find the ACC_DEP_DISTANCE to be confusing however. Ultimately it's derived from the latency (in cycles) it takes for a write to address X to be visible on the read port at address X. Maybe we can dub this SRAM_WRITE_TO_READ_LATENCY or something along those lines?

Thanks @tmoreau89 for the suggestion. I think VerifyDep here is to verify that we don't write to the same acc_mem index two cycles in a row (I may also need to change the comments).

The ACC_DEP_DISTANCE is the same as here. Did I get the correct meaning of VerifyDep?

[tqchen]

ping @tmoreau89 @zhanghaohit please followup :)

[zhanghaohit]

ping @tmoreau89 @zhanghaohit please followup :)

Thanks @tqchen for the reminder. I think this PR depends on this PR in VTA repo.
@tmoreau89 could you kindly review and what do you suggest? Thanks.