For now, I fixed this on the sflow branch by directly connecting the in.wdata.valid and out.wdata.valid. It seems to fix the issues for a subset of tests apps on the DE1 board. I'm not sure if it would cause problems for the Xilinx boards. We may want to try this fix with the regressions on Xilinx boards and see what happens. @mattfel1 What do you think?
Right now, it seems that our WVALID assertion depends on AWREADY. This is caused by how we implement wdata.valid signal coming out of AXICmdIssue: https://github.com/stanford-ppl/spatial/blob/b50476a7ffedf0d996a81ebeb601931a08b1b557/fringe/src/fringe/templates/dramarbiter/AXIProtocol.scala#L86. Since qsys' interconnect scheduler only assigns AWREADY to network ready when AWVALID and WVALID are both high, our implementation would lead to a deadlock when SpatialIP is connected with an Intel qsys interconnect.
For now, I fixed this on the sflow branch by directly connecting the in.wdata.valid and out.wdata.valid. It seems to fix the issues for a subset of tests apps on the DE1 board. I'm not sure if it would cause problems for the Xilinx boards. We may want to try this fix with the regressions on Xilinx boards and see what happens. @mattfel1 What do you think?