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.
VCS requires the output of the dpi calls to be of a type that can come
at the LHS of a procedural assignment, i.e. reg type. Seems to be a
different requirement from Verilator.
addResource() calls in Chisel BlackBox does not preserve order of the
files being included; the actual compile order for these files are
re-arranged to be in alphabetical order.
Therefore, while VX_gpu_pkg.sv has to be compiled before all the other
modules because it holds the top-level package definition, that order
cannot be ensured from Chisel. As a hacky workaround, simply `include
this file in some of the sv files whose name starts earlier than
VX_gpu_pkg in lexicographical order.
