Closed zzmsir closed 2 years ago
I'm not sure what the error you are seeing is. Why do you expect a.valid to be high on those cycles?
I'm not sure what the error you are seeing is. Why do you expect a.valid to be high on those cycles?
I‘m testing hwachacase vec-daxpy,when a.valid is high,hwacha will load data from a.addr, a.addr is needed butnow a.valid is low
The TL-A channel is a decoupled interface. Most likely on those cycles, the VMU intentionally desserts valid.
Are you seeing an erroring test case that can be traced back to this behavior?
Background Work
Chipyard Version and Hash
Release: 1.7.1 Hash: 992664220d95edf610475031fd8a82d0cd743f7f
OS Setup
dont care
Other Setup
Ex: Prior steps taken / Documentation Followed / etc...
Current Behavior
CONFIG=HwachaRocketConfig change DefaultHwachaConfig case HwachaNBanks => 4 >> case HwachaNBanks => 8 case SystemBusKey => up(SystemBusKey, site).copy(beatBytes = 16) >> case SystemBusKey => up(SystemBusKey, site).copy(beatBytes = 32) Current Behavior:hwacha cannot load complete valid data sometimes meeting needed data, valid single cannot pull up(set 1)
Expected Behavior
CONFIG=HwachaRocketConfig change DefaultHwachaConfig case HwachaNBanks => 4 >> case HwachaNBanks => 8 case SystemBusKey => up(SystemBusKey, site).copy(beatBytes = 16) >> case SystemBusKey => up(SystemBusKey, site).copy(beatBytes = 32) Expected Behavior:hwacha can load complete valid data alltime meeting needed data, valid single must pull up(set 1)
Other Information
CONFIG=HwachaRocketConfig change DefaultHwachaConfig case HwachaNBanks => 4 >> case HwachaNBanks => 8 case SystemBusKey => up(SystemBusKey, site).copy(beatBytes = 16) >> case SystemBusKey => up(SystemBusKey, site).copy(beatBytes = 32)