About Xiangshan IFU, where is the 2nd cacheline used? Is it a bug?

[Jerry-Tianchen]

Hi Guys. While I was reading the code of Xiangshan's IFU code. I realized that the return data of the second cacheline from ICache was never used?

Based on my understanding it should be used by f2_data_2_cacheline, but the current f2_data_2_cacheline is

  val f2_data_2_cacheline    = Cat(f2_cache_response_data(0), f2_cache_response_data(0)) 

Is it really correct?

I thought it should be the following in order to deal with the situation that a 4B instruction crossing the cacheline.

  val f2_data_2_cacheline    = Cat(f2_cache_response_data(1), f2_cache_response_data(0)) 

I am not sure. Please correct me if I was wrong.

Jerry

[eastonman]

No, this is legacy code that needs refactoring. Historically we use 2 ports in ICache for crossline fetching. However, this wastes power and registers. Because a fetch block in XiangShan is 34B max, so at most we need 48B of ICache data (with 16B banking). These 48B data are passed through port 0 now, and port 1 is no longer used.

[ngc7331]

This is actually a frequently asked question. I've added comments to the code that you can refer to. -> #3874

[Jerry-Tianchen]

I'm sorry to bother you, but I have a follow-up question. Does this also mean some of the logic in the Predecode class is obsoleted? We don't need to separate the validStart and ValidEnd processing into 2 halves: 0-->PredictWidth/2 and PredictWidth/2 --> PredictWidth

[ngc7331]

No, Predecode works on the selected 34B data (i.e. f2_cut_data), it has nothing to do with the number of cachelines before selection (i.e. f2_data_2_cacheline). So it works the same way on old and new ICache.

We separate validStart processing into 2 halves for better timing:

XiangShan/src/main/scala/xiangshan/frontend/PreDecode.scala

Lines 160 to 163 in 8cbf000

	val lastIsValidEnd = if (i == 0) { true.B }
	else { validEnd(i - 1) || !HasCExtension.B }
	validStart(i) := (lastIsValidEnd || !HasCExtension.B)
	validEnd(i) := validStart(i) && currentIsRVC(i) || !validStart(i) || !HasCExtension.B

As you can see, validStart(i) relies on validEnd(i-1), which in turn relies on validStart(i-1), so this forms a long combinatorial path.

Therefore, we split the whole validStart into two halves, and there are two possible cases for the second half: a valid instruction start at PredictWidth / 2 (validStart_half) and at PredictWidth / 2 + 1 (validStart_halfPlus1). So we can generate these two cases and the first half in parallel.

Then, we can use the last entry of the first half to choose one of the two cases of the second half:

XiangShan/src/main/scala/xiangshan/frontend/PreDecode.scala

Lines 221 to 227 in 8cbf000

	// if PredictWidth / 2 - 1 is a valid end, PredictWidth / 2 is a valid start
	for (i <- PredictWidth / 2 until PredictWidth) {
	validStart(i) := Mux(validEnd(PredictWidth / 2 - 1), validStart_half(i), validStart_halfPlus1(i))
	validEnd(i) := Mux(validEnd(PredictWidth / 2 - 1), validEnd_half(i), validEnd_halfPlus1(i))
	h_validStart(i) := Mux(h_validEnd(PredictWidth / 2 - 1), h_validStart_half(i), h_validStart_halfPlus1(i))
	h_validEnd(i) := Mux(h_validEnd(PredictWidth / 2 - 1), h_validEnd_half(i), h_validEnd_halfPlus1(i))
	}

Thus, we can halve the combinational logic path at some hardware cost, achieving a better timing.