Lab4-2 Performance Optimization

[boledulab]

This is to initate a thread of discussion to improve Lab4 Caravel FIR, in particular, how to have firmware feed data to FIR to match the hardware throughput, i.e. 11 or 12 T a data output.

[nthuyouwei]

我們這組的優化過程如下:
lab4-2優化過程.pdf

[vic9112]

Here is my improvement after reordering some of the instructions.

FurtherOptimizationVic.pdf

[nthuyouwei]

感謝 @vic9112 提供更改assembly code順序的方式(直接進入.hex中更改對應的順序就好了)，所以我再優化，從原先的waveform發現38000028卡住了整個時間，所以我把他往前移如下圖

所以優化後的waveform為

這樣y->x只要2個cycle

[boledulab]

It is good that you find out it is a load-to-use case, i.e.
lw a2, 132(a3)
sw a2, 0(a4) => this sw is stalled thus delays the following write x ( sw a5, 128 (a3). This is an in-order processor.

Until now, the host firmware is not a bottleneck.
Next, You can hack FIR HW design to remove the actual FIR calculate, i.e. to bypass X to Y, to see how fast the firmware can run. Then set this as a target to optimize hardware.

[nthuyouwei]

更新一下:目前優化程度，因一開始硬體設計上並沒有加一層FF，所以每次做完y都要等到收到x才能繼續，這時極限只能做到2+14 cycles per data且在此狀況下還要花時間去設計究竟x->y還是y->x哪段要比較快來配合硬體。不過感謝台大同學的報告，從中發現加了一層FF確實可以再進一步優化。有了FF後，我們可以再運算的過程中也可以收x，所以我們現在只要思考如何讓smtready之間的距離縮短即可。所以我試著再去縮短smtready之間的cycle數，最後做出來12cycles per data。

下圖為firmware code中while迴圈對應的 assembly code以及waveform

[boledulab]

It is great. This is to preload X so that hardware does not need to wait for X. The throughput 12T is probably the maximum hardware can go?
FYI. The NTU team unfolded the loop by 2 (still fit the code into the instruction cache) to reduce the branch overhead (as attached).
lab4-2 best result.pptx.pdf