From 8affa755d0e42de11c0c8c94cc1dc712dcee0f5b Mon Sep 17 00:00:00 2001 From: Hansung Kim Date: Tue, 24 Oct 2023 11:37:49 -0700 Subject: [PATCH] Remove overly strict enq.ready assertion on respQueues This used to make sense when we used MemTraceCores which never blocks the response channel, but now that we're integrating with Vortex cores, we cannot make the same assumption on the core's actual pipeline behavior (although it is unclear why a core would ever block receiving responses.) --- src/main/scala/tilelink/Coalescing.scala | 8 -------- 1 file changed, 8 deletions(-) diff --git a/src/main/scala/tilelink/Coalescing.scala b/src/main/scala/tilelink/Coalescing.scala index 9885a16..49f501c 100644 --- a/src/main/scala/tilelink/Coalescing.scala +++ b/src/main/scala/tilelink/Coalescing.scala @@ -1132,14 +1132,6 @@ class Uncoalescer( (foundRow.lanes zip io.respQueueIO).zipWithIndex.foreach { case ((foundLane, enqIOs), lane) => foundLane.reqs.zipWithIndex.foreach { case (foundReq, depth) => val enqIO = enqIOs(depth) - - // TODO: rather than crashing, deassert tlOut.d.ready to stall downtream - // cache. This should ideally not happen though (and hasn't happened yet - // in testing.) - assert( - enqIO.ready, - s"respQueue: enq port for ${depth}-th uncoalesced response is blocked for lane ${lane}" - ) // spatial-only coalescing: only looking at 0th srcId entry enqIO.valid := false.B enqIO.bits := DontCare