Attempted to directly push to develop, but permission was denied.
Therefore, I moved my changes to my development branch located on my fork.
I have permission to commit changes to my fork, and I can open a PR to bring those changes into main repo
Since the core's response ready signal depends on response valid, but core does
not accept write ACKs, we need to manually assert ready when there is a valid
response coming in for a write regardless of the core's ready state (which would
be 0).
It seems many of the initial arch/uarch states, including the GPR, are
uninitialized in the VCS simulation, which results in functional errors caused
by propagated X's. In this particular case it resulted in a dcache request not
being fired due to the rs1 data for an lw instruction having values as X,
causing the smem_unit to not arbitrate the request correctly.
A workaround of this issue is to stop the X propagation by using the
===-operation instead of == in the GPR unit, which had been the main source of X
propagation into the raddr port of the GPR.
Also, we run the simulation with GSR_RESET set to 1 so that the contents of the
GPR are initialized at the beginning of the simulation (however, this alone does
not prevent reading in X's, hence this fix.)
FIXME: This is a slight deviation from the upstream code; ideally, we want to do
clean & full initialization of microarchitectural states.
Need to use DCACHE_NOSM_TAG_WIDTH instead of DCACHE_TAG_WIDTH; otherwise, the
`ASSIGN_VX_MEM_BUS_IF macro in VX_smem_unit.sv does assignment of packed structs
with different widths for the tag field, resulting in misaligned bit error.
This results in wrong memory addresses for the core requests.
