好的設計習慣II

剛來乍到的工程師，常常會寫一些很炫的技巧，來實現他的硬體設計。我覺得很好，也可以讓我多學學不同的技巧，也是不錯。但是，常常在我問過一些問題後，我就不知道該怎麼說他了。

在這兒想分享一些觀念，希望能有所幫助。

1. 技巧很重要，但是如果你不知道在synthesis階段時，應該要寫什麼樣子的constrain來synthesize你的程式時，建議不要使用，因為你會讓你的整合工程師頭很大。

2. balance clock tree的觀念很重要，請不要告訴你的整合工程師說，你的clock tree 就是要 no balance，timing才會是對的。數位工程師所有的想法都是在balance tree底下設計。只有少數非常特例，才會想要用不balance tree來實作硬體。但那是有特別的流程的。如果你不知道怎麼做，建議不要使用，以免增加你的整合工程師的困擾!

3. 請不要自己自動加快或是變慢clock速度。這種coding style，constrain很難寫，而且很怕你沒有做cross clock domain處理，整合工程師又不知道，然後simulation時出現一大堆meta-stable；或是synthesis時有一大堆register no constrain的報告要看。

4.如果你的負責的方塊(block)裏，有兩個以上的clock domain。如果它們之間有訊號的往來時，請一定做cross clock domain處理。

5.請別把一堆東西寫在同一個always內，然後當我問「那它的netlist長什麼樣子時?」結果卻回答我「誰知道，那麼複雜」。如果不知道，請別用，用那種你知道netlist長什麼樣子的coding style好嗎？

6. 請別用latch，因為它的timing不好分析，建議用D-flip-flop就好；STA比較好看懂. 

以上是一些在寫verilog的習慣，希望對初學者能有所幫助。

好的設計習慣I

在學校時，老師常說「在寫程式前，請先畫好你的流程圖、方塊圖、波形圖，然後才開始動手寫程式。」

我不知道有多少人有這樣子做。不過這真的是好的習慣。我常常遇到剛來的工程師跑來找我說「學長，幫我看看我的程式怎麼了，為什麼出來的不是我想要的結果？」然後他點開他的程式讓我看，我心裏想，這誰會看得懂？

在此建議，做為一個初學者，要習慣畫流程圖、方塊圖、波形圖。當你在畫這些圖時，你的腦袋裏面也同時在依循這些圖在思考、推論，幫助你去思考自己的邏輯的盲點。

程式並不是人類的語言，是電腦的語言。人類最直觀的語言就是圖畫。如果你把流程圖、方塊圖、波形圖都畫好，當你想跟別人討論時，別人才能從圖畫中快速了解你的想法，這樣子才會有後續的討論產生發生。

除此之外，這同時也是執行能力的表現。為什麼這麼說？如果你的流程圖、方塊圖、波形圖都沒有問題，那麼理論上你應該可以做出來。如果你就是沒有辦法做出來，或許在執行的細節裏有盲點，而自己疏忽了。修正這些錯誤，相信你就會比別的初學者學到更多的經驗。多練習幾次之後，你就能徹底貫徹你的想法，你的表現也會被你的同伴認同、信賴。

流程圖、方塊圖、波形圖並不單純只是設計前需要先做好。當你完成工作時，你也需要把後續的設計引導(design guide)完成。而這時你只需要剪貼你之前的流程圖、方塊圖、波形圖，並加上一些文詞並茂的文字，不就完成了。當別的同事在忙著寫報告時，而你已經完成紙上作業，相信長官看到這些後，也會信賴你的工作態度及認真態度；慢慢得，就會交付你更重大的任務。