# 有關於 Chisel debug 技巧的一些想法

###### tags: `Programming`

一般我們在測試編寫的電路行為是否正確的時候，可能會直接寫好 testbench 之後，然後執行，再看輸出或者是 Wave form 來判斷電路行為是否符合預期
但是在 Chisel compilation 的過程中，有時後會遇到一些非常難以判斷問題到底出在哪裡的 error message。以下舉個例子

## Example


上圖是 HW5 中，ALU 的設計（ALU.scala），而其中節錄的是一個 `MuxLookup` 的部份內容

> 在 Chisel 中，如果要利用 MuxLookup 來 assign 某些訊號的話，是不允許候選訊號中有不同的 Dtype，所以在上面的例子中，本來應該所有的候選訊號都要是 `UInt` 這個 Dtype，但是我故意把其中一個改成 `SInt`，使其在 Compilation 的過程中出現錯誤

但是我們分別利用兩種不同的方式去執行

1. __直接跑 topTest.scala__
出現了以下 Error message


從上面的錯誤訊息大概可以看出來，可能是 ALU 的設計出了問題，但是具體是出了哪些問題，光看 error message 其實還是摸不著頭緒，所以我們試著根據我們的推論（ALU 有問題），試試看第二種編譯方式

2. __單純執行 ALUTop__
Recall : 助教在 Lab5-0 文件中所提到的，如何在 `sbt shell` 中去執行單一 module


所以我們在 `ALU.scala` 中加入口函式之後，執行以下指令

    sbt // enter sbt shell
    runMain aias_lab5.Hw4.ALUTop // execute

會得到以下的錯誤訊息


這次的錯誤訊息相較於上一個錯誤訊息，明顯具體很多，可以直接看出是我們 `ALU.scala` 中的 `MuxLookup` 出了問題，所以就可以快速地進行 debug。

## Conclusion

如果在執行 testbench 的時候遇到了一些難以判斷的 error message，或許可以先推論是哪個 module 出了問題，再單一執行該 module，通常得到的 error message 會具體許多。