2014年5月25日 星期日

什麼是DMA ?

什麼是DMA?
如果你上網搜尋DMA,相信你可以找到很詳細的解釋。例如下方的解釋。

直接記憶體存取(Direct Memory Access,DMA)是電腦科學中的一種記憶體存取技術。它允許某些電腦內部的硬體子系統(電腦外設),可以獨立地直接讀寫系統記憶體,而不需繞道中央處理器(CPU)

簡單來說,就是搬資料,不需要用到CPU的指令。換言之,搬資料時,CPU不用知道。要怎麼做可以確保搬的資料不會錯。

1.要知道原始資料的位置。
2.要知道目地的位置。
3.要知道要搬多少資料長度。

這個跟你找搬家公司一樣。你要先告訴搬家公司你家的地址。然後告訴他你新家的地址。然後再告訴他,你家的哪些搬東西要搬走。之後搬家公司就可以開始搬。主人不用每一樣都要告訴他怎麼搬。

所以搬家公司就是控制器(controller),舊家是地址,新家是目地。傢俱是資料。詳細清楚搬家內容後,就開始搬,這就是DMA。

所以要看懂DMA的設計,就是找兩個地址,一個資料長度。然後就沒有了。很多人告訴我,他設計的DMA有多複雜又多複雜。很難看懂。我請他畫 Bus,請他告訴我定址空間。然後請他告訴我,他的DMA控制器的哪一段是記錄兩個地址和資料長度。之後我在 Bus diagram上,告訴他DMA如何在 Bus上移動。一清二楚,有沒有做錯,一目瞭然。
那兩個地址,一個資料長度誰給?誰給不重要,重要是「搬資料時,CPU不用知道」,這就是DMA。

或許有人覺得他設計的DMA比較複雜,較難懂。就像有人家裏東西多、種類多。所以找比較多搬家公司,有人專門負責搬黃金、有人專門搬傢俱、有人專門搬家電,搬家時,你家會不會很熱鬧?當然會,只看搬黃金的,會很複雜嗎?只看搬傢俱的,會很複雜嗎?做好一套DMA後,再來就簡單了。初學者不用擔心會很複雜。

另外會增加DMA複雜度的是arbter(仲裁器),它會決定是哪個DMA的需求會被滿足。把這個部份程式和DMA的程式分開來研讀,相信初學者就可以解決DMA的問題。

2014年5月18日 星期日

數位工程師對DC-compiler的觀念是什麼?

數位工程師是離不開 DC-compiler,他需要 DC-compiler幫他合成 netlist,所以 DC-compiler對數位工程師而言是一個很重要的工具,但是數位工程師有用正確的態度來使用 DC-compiler嗎?
DC-compiler公司因為不曉得你的想法,不曉得你的晶片設計是什麼,所以他們絕大多數都不會用error message來告訴你,你的晶片有什麼問題。他們用warning message來告訴你,你的晶片有什麼異常,請你自己去看,由你自己去判斷。他們用error message來告訴你,你操作DC-compiler的方法是錯的,例如:語法錯、指令錯等等,這是他們肯定知道錯的,所以用error message來告知。

曾有數位工程師跟我說,那只是warning message,又不是 error message,有什麼關係,不用看。我聽了著實嚇了一大跳,一個D-flip-flop沒有辦法 report timing,無法得知它的setup-time和hold-time,會叫做「沒有關係」嗎?。在 DC-compiler裏,它只會列出一大堆沒有辦法計算的 timing 的D-flip-flop,不會告訴你那是 error message。數位工程師要自己去判斷。那你或許會說,為什麼要數位工程師自己判斷,電腦為什麼不自己判斷,DC-compiler有那麼差嗎?

是的,電腦會判斷,但前提是數位工程師要提供完整的條件告訴DC-compiler。曾有數工程師說,DC-compiler會幫你檢查 timing,如果他們的clock是同源的。乍聽下是對的,我就問,DC-compiler有怎麼知道他們是同源的?他回答:「一看就知道。」忽然間我感到不對勁,再問:「要怎麼看?它是電腦,又沒有眼睛。」他回答:「他應該就是會知道。」原來他認為,他所有的 design寫好後,DC-compiler就是會從RTL code知道,不用寫條件,只要create clock 就會知道。這下子,我才明白,原來 DC-compiler還是一個有極高度智慧的AI程式。我想DC-compiler公司聽到這些話,應該會高興到跳起來,因為有人給予DC-compiler這麼高評價。

DC-compiler是一個很棒的工具,但是它不是人工智慧的程式:

DC-compiler並不是一個會自我成長的程式,所以,當你使用它的時候,你一定要給足所有的條件,讓它來幫你工作。所以它不會「本來就知道」你的設計想法,它需要你「告訴它你的設計想法是什麼」。所以,如果是同源的clock,就是要宣告generated clock。而 Multi-cycle path,一定要寫出來不然它不會曉得。每個 D-flip-flop的clock port都是要接到一個被宣告的clock描述語法上,如果沒有,那它就不知道怎麼做,所以會被列到沒有timing constrain的地方。

DC-compiler的warning message是要請您補足你的constrain不是要你每次用人工看message是對或是不對:

DC-compiler是依照一個複雜的演算法來幫忙計算timing的,當它無法用你給的條件來計算時,應該是你要補足constrain條件或是修正你的RTL code,而不是都用人工的方式來看待warning message。或許你會覺得修正你的RTL code是一件很誇張的事;但是,你知道嗎?在十年前,DC-compiler甚至看不懂「function」的verilog語法,所以數位工程師都被禁止使用「 function」這個語法。而現在它看懂了,所以你可以用「function」語法。換句話說,是你去適應它的能力,而不是它來適應你的能力。所以如果你的RTL coding style沒有辦法被看懂時,理應修正RTL code。

DC-compiler很笨:

有很多工程師認為DC-compiler很笨,常常把假錯(fault error)的 timing列出來。害工程師要多做一次檢查。是的,DC-compiler是很笨,但那是因為你給的constrain不足,所以它無法算出正確的timing給你,所以只好列出來給你看,以免你合出錯的 netlist。所以,是你讓它變笨。

Input delay和output delay都是別人家的delay:

在DC-compiler裏,set_input_delay和set_output_delay都是在說明別人使用多少delay。
例如:如果有一個clock是20ns為週期的,

set_input_delay –clock clk_20  15 portA;
set_output_delay –clock clk_20  15 portB;

portA在20ns週期的clk_20上,只能用到5ns(20ns-15ns)的時間。portB在20ns週期的clk_20上,只能用到5ns(20ns-15ns)的時間。以前有個工程師跟我爭論,set_input_delay這個指令是設別人的delay,set_output_delay是設自己的delay。現在我把這個重要的觀念再說一次,大家一定要清楚明白。set_input_delay和set_output_delay都是設定別人所用的delay;如果要知道自己可以使用多少時間,一定要自己計算( T – delay time)。這個算法,到目前為止(2014/04/21),DC-compiler都還是用這個方法。如果他們有改版,不用這個方法時,我再告訴大家新的計算方法是什麼,不然,它們就是這麼計算的。

對DC-compiler的正確態度是什麼?

1. create clock很重要(每個D-flip-flop的clock port都會連到的clock),告訴 DC-compiler 每個clock之間的關係,即使用同源的也宣告清楚。

2.每個input delay,output delay都要確實宣告。你不宣告,它一定是不會知道的。

3. 如果不需要檢查timing的,也要宣告訴清楚,因為它的演算法會幫你做更多事,幫你檢查更詳盡,而你可以更省力。

4. driving和loading要記得給,這對合出準確的 netlist是有幫助的。

5. 只要有warning message就想辦法消除,因為這對DC-compiler合成netlist是有幫助的。

6. 只要是DC-compiler有看不懂RTL code的疑慮,一定要改RTL code來適應它。

7. 數位工程師都是看balance tree的timing report。不balance tree的timing report也是屬於某段balance tree的timing report,所以如果有不balance tree的timing report需要檢查時,請把條件寫出來,然後再以balance tree的角度看待的timing report。

8. reset和clock同樣重要,要記得宣告。


DC-compiler是工具,不是一個AI程式,它不會知道你的想法。你必須把設計時的所有條件以及你想要遮罩的條件,一一寫入DC script檔案中。DC才能照你的想法合成 netlist。所有的coding style都是為了讓 DC看懂你的程式,進而合出你的 netlist。

2014年5月4日 星期日

從 IC流程中探索數位工程師的風格--III

在上述的 IC流程中,還有其他工程師也是參與其中;而你是數位工程師,你對其他工程師的責任是什麼你有清楚嗎?

案例分享:
在這個 IC流程中,數位工程師會需要類比工程師的幫忙部份,絕大部份是在synthesis LIB的參考和simulation時的模型建立。曾經遇過類比工程師需要數位工程師幫忙驗證他們建立的LIB是否正確?在這個IC流程中,確實可以幫類比工程師驗證LIB。但是當初在規劃行程時,有把這個時間算進去嗎?而且整個design在進入synthesis階段時,在很多的synthesis條件都沒有穩定的情況下,拿去幫類比工程師驗證 LIB是否是正確的選擇?所得到的結果是否會是正確?不正確的話,又需要多少時間收斂?所以類比工程師的LIB 驗證,應該是要在他自己的環境下去完成,而不應該在整合的環境中去做驗證。

IC流程裏,它不是幫類比工程師驗證LIB,它是依據類比工程師提供正確的LIB來做合成的工作。所以在synthesis之前,數位工程師就應要求類比工程師提供正確的LIB,不然就無法合出最合適的netlist。

為什麼synthesis時,要有正確的LIB?
DC-compiler依據LIB上的資訊,利用它的演算法,計算出哪一個gate是最合適的,計算出所有path的timing,告訴你哪一個是很緊的。依據這種概念,合出來的netlist才會是最接近真實的情況。

以下是案例的分享: 
類比工程師進度落後,告訴數位工程師,你用設delay方法來收斂 timing,類比工程師會按規格要求,處理好 interface timing,之後就可以tape-out。LIB部份,類比工程師會用手動的方式建立,讓整個 synthesis 流程順暢。 結果晶片回來後,在某些頻率下,會容易出錯。問題查了很多,原因是data出錯;所以數位工程師不可避免的成為主要的負責人。從design到synthesis,然後再到primetime check,之後還check floor-plan。結果發現,是類比工程師在設計介面時,使用推力不足的cell,所以在頻率快的情形下,setup-time violation。但這完全查不出來,因為LIB是非常完美的LIB,它不是擷取類比電路所計算出來的。它是人工的,所以在這個流程中,數位工程師當然查不到setup-time violation的報告。

合成時為什麼需要LIB?當然是想要在最接近真實的情況下,合出適合的netlist。因為LIB太過理想,所以合出來的netlist當然也是太過理想。

為什麼國外大廠的晶片穩定度高?技術好是一個原因。另外一個是他們嚴格要求IC流程的模擬要符合真實情況。所以他們一定用軟體來擷取類比電路,計算出正確timing後,才會公佈 LIB給數位工程師使用。儘量讓所有的數據都是最接近真實情況。

說完IC流程後。我大約分類一下風格,大家或許就可以知道我所說的是什麼意思。希望藉由這些分類,可以更了解你的工程師伙伴在想什麼?

1. Front-end RTL level數位工程師:遇到問題時,想盡辦法在RTL-level解決,並在RTL-simulation確保function的正確性。其寫出來的RTL code都是synthesizable,了解RTL code限制,也知道如何在DC環境下,寫出適合的constrain,也知道怎麼看懂的所有的timing report。其程式風格像前面RTL code的解決方式一.

2.Front-end post-level數位工程師:程式的風格像前面的RTL code的解決方式二,需要CAD的工程師幫忙保證 timing,無法在RTL-level就保證其timing和正確性。

3.Front-end artificial數位工程師,程式的風格像前面的 RTL code的 interrupt machine的原始範例,用人腦推論;對於DC-compiler提出來的 timing violation時,人工確認是否為假錯( false-error )。

4. cell-base數位工程師:使用verilog語法並參照standard cell/customized cell,畫出電路,不是用寫程式的觀念來寫程式的。

5. Back-end數位工程師: 熟悉DC的指令、primetime指令。對做ATPG, IO scan非常清楚,但是對RTL-coding觀念比較薄弱,因為對DC和 primetime指令熟悉,所以較適合做IP整合工作。

其實還有其他種類的數位工程師,在此就不一 一敘述,我就針對以後我的分享風格做一個說明,讓大家知道我為什麼這樣做,我的原因有在哪裏?我的要求在哪裏?

做為一個數位工程師,你會遇到的問題和困難一定會很多,有時候你無法保證一定可以在RTL level就把它解決,這其中包括 timing。 而 timing的部份,你可能需要別人的協助,才能把問題解決。但是我希望所有的問題盡量在RTL-level就解決完,除非不能解決時,才會請CAD幫忙保證 timing。之後如果我有分享程式時,你會看到我程式都會在RTL-level解決問題。每個程式也都一定會知道怎麼寫 timing constrain和看它的 timing report。 







2014年4月27日 星期日

從 IC流程中探索數位工程師的風格--II

就Back-end而言:
就Back-end的工作內容,主要的負責單位是CAD部們,數位工程師只是輔助的角色。如果是輔助的角色,那麼應該要注意哪些細節呢?

1. 建立primetime環境來驗證CAD做完APR後的netlist是否是符合自己的需求。

2. 請CAD給一套和他工作環境相同的primetime環境,做為最後驗證timing的path的依據。

3. 任何因為timing不符合時,需要修改netlist時,請CAD重做一份,數位工程師不代勞。

4.任何因為bug問題,需要修改netlist時,數位工程師要做,但是再請CAD工程依修改的netlist做出一份新的post netlist及timing model。不用數位工程師修改的版本來做primetime check。要用CAD的版本做primetime check。

5. 數位工程師要跑post-level simulation,驗證post-netlist是否是正確的?

6. 如果都驗證無誤時,要用CAD部門的版本當成是對外要tapeout的版本。

或許你會覺得有些地方是多餘的,像是第一點和第二點,就是要一套primetime來做timing check,誰建的還不都一樣。曾經遇到CAD拿到錯的timing constrain,結果CAD報一大堆timing violation,我用CAD的primetime環境查半天才發覺。所以當CAD報有timing無法收斂時,第一個要先確認是不是環境設定問題。畢竟你給出去netlist時,在DC都是timing收斂。很少有機會到primetime時,發散,除非 margin留得不夠,不然前後應該是一致的。所以為了確保CAD的環境的同步,就只好自己先建一個primetime,兩邊同步在相同的認知上,再開始工作。
另外,對於為什麼要堅持CAD部門提供tapeout的netlist?以及發現timing violation時,數位工程師為什麼不能自己修改?我舉一個案例分享。

有人曾經遇到,project leader發現bug和timing violation時,而為了趕上當初承諾的行程,project leader自己修正bug和timing後,自己用primetime check static timing以及formal check比對RTL和netlist。發現都沒有問題後,就直接tapeout。晶片回來後,發現有部份的設計,有hold-time violation的疑慮,project leader不敢說自己有修正netlist,直說是CAD的版本有問題,CAD部門查了半天,都查不出來。重做第二版時,就用新的RTL code合成,也真的是用CAD部門的netlist tapeout,結果第二版的晶片出現和第一版本的錯誤完全不同。總經理就疑惑,「不是沒有改RTL code為什麼會這樣子?」工程師在第一顆晶片查到的有些問題,都無法在第二顆晶片上得到解釋。Project leader也無法在第一顆和第二顆晶片實驗中,得到他完滿的解釋。最後是誰背黑鍋,還是CAD。因為hold-time violation沒有再出現,但是新的問題又出現,而從頭到尾第一顆晶片和第二顆晶片的RTL都是一樣的,只是第一顆的RTL是在tapeout前才底定。

Back-end這個階段,數位工程師只是輔助的角色,那就做好輔助的工作,一切都是CAD說了算,project leader也沒有能力去修正netlist,數位工程師的本份就是盡力幫CAD版本的netlist做最大的驗證;發現任何問題,就是要讓大家都知道,然後再跑一次流程。每個計劃中,有很多的成員加入,尊重每個領域的專業,並讓他確實的負責,這樣子才會讓加入的工程師有參與感和使命感,才能留住工程師的心。

token的轉移和劃分的概念,不光是用在design上,還可以用在IC的流程上,實際上,它很多其他的地方。整個project的規劃也可以用這個概念,只不過當方法和規則建立後,你願意嚴格遵守並確實的執行嗎?

有的數位工程師會嚴格遵守並確實執行,有的不會。我們都知道,事實上是很難,因為project leader有schedule(行程)壓力,project leader怕別人知道做錯的壓力等等,總是可以找到合理解釋,來縮減IC流程中的步驟。運氣好的話,沒事,運氣不好的呢?

工程師是做科學驗證的工作,希望能嚴格遵守並確實執行,提昇晶片的穩定度及品質。或許有著各式各樣的壓力,但是能堅持下去,就是知行合一實踐。不然光說不練,對於管理上也是一種很大的傷害。


2014年4月24日 星期四

程式中邏輯內涵的用意? ( 用If-else和case的舉例 )

程式中邏輯內涵的用意? ( 用If-else和case的舉例 )
程式應該要有邏輯的內涵,並非是表面所寫的面貌的。有邏輯內涵的程式可以讓程式便於看懂,對於後來接手的工程師而言,他可以藉由這些邏輯內涵和以前的工程師神交,瞭解前人的邏輯維思。

今天以if-else和case為例,來說明邏輯內涵是什麼?
我們都知道,if-else的寫法是和優先順序有相關的,而case是沒有優先順序關係的。但是,這是否是絕對的定律。我們來看一下下面的程式。
always@(*)
begin
    if(value==2’b00)
       A = 2’b00;
    else if(value==2’b01)
        A = 2’b01;
    else if(value==2’b10)
        A = 2’b10;
else
        A = 2’b11;
    end
end

以下是case的例子
case(value)
2’b00:   A= 2’b00;
2’b01:   A= 2’b01;
2’b10:   A= 2’b10;
default:  A= 2’b11;
endcase

在if-else的程式中,我們看到value=2’b00時的優先權最高,再來是value=2’b01 -> value=2’b10 -> value=2’b11。但我們想想value=00的最高優先權有意義嗎?value=00和value11會同時發生嗎?不會。那麼用下面的case來取代,是否是可行的?答案我想大家都是知道的。當一個數位工程師,我們要知道數位的內涵,而不是就表面的東西來解釋,然後就講一些沒有錯的道理來爭論。為什麼這麼說?就上面if-else的程式而言,這位工程師希望value=00的優先順序是最高的,然後依次是01 -> 10 -> 11,但是當每個值都不會同時發生時,那麼你排優先順序有什麼意義嗎?電路上的邏輯不會有任何錯誤,但是卻會造成你在合成電路時,電路實際上的latency以及gate count有所不同。

每個程式的寫法、意義,都是在代表你對事物的邏輯思考。而工程師本身必須對邏輯思考要精準到位,用你的程式來告訴別人你的思考邏輯是什麼?而不是只是結果是對的。因為當你的結果和別人一樣,但是推理過程和別人完全不同時,那麼在討論的過程中,如何培養默契?如何讓別人知道你的邏輯思緒是清晰?

因為邏輯只有0(錯)和1(對),當他的結果是對的,但內涵卻是不同時,你會怎麼做?舉例來說:如果有家長想抱孫子,而父母雙方有某種程度上不容易受孕,這時長家不管雙方父母,就是一定要抱孫子,此時,應該怎麼做?有人領養、有人做人工。但是如果有人是強抱別人家的小孩,你會怎麼想?當然會覺得是錯的。就算你是當事者的家長,應該也不會鼓勵這種行為。還是說,很好,有孫子抱就好,就算是犯法也不管。(PS: 或許例子舉得不是那麼好,希望能多多見諒 ! )

結果很重要,但是邏輯的內涵也同樣重要。因為這些都是代表邏輯思緒上的合理性。這種合理性是給後來的工程師去了解程式的一種方法。如果程式沒有合理性,就算結果是對的,對後來接手的工程師而言,無異是一場災難的開始。

一個全方位的數位工程師在寫程式時,不應只是考慮 latency和 gate count,你還要考慮它的邏輯內涵;讓別的工程師在看你的程式時,有前後一貫性,知道你的邏輯思維。當他看不懂你的程式碼時,他才能有所依據,按照你的邏輯思維來推演你的程式碼,慢慢地讀懂你的程式。
希望下次當你在寫 verilog 程式時,不是只是把它當成是電路來做,而是把它當成「程式」來看待,畢竟它的名稱還是叫做 verilog code,而不是叫做 verilog circuit。



2014年4月20日 星期日

從 IC流程中探索數位工程師的風格--I

今天想跟大家提一下IC 流程。因為我未來的分享也是和它有關。先溝通認知的部份,才能繼續下去。

我認為數位工程師的風格有很多,就像軟體工程師的風格也有很多種類。數位工程師的風格的分類,我是依據 IC流程來做分類的。每位數位工程師專精的地方有所不同,所以解決問題的思維也就不同。了解清楚 IC流程的權則劃分後,我會舉一些案例,讓大家去思考流程中的關鍵是什麼?初學者藉由這樣子的思索,探索想成為什麼樣子風格的數位工程師。


Fig: IC design flow
簡單說明一下流程。流程的開始是從規格的制定開始。確定規格後,開始規劃晶片的架構及功能。分配完工作後,就開始RTL coding。一邊coding一邊跑RT-level模擬。如果有錯誤,就回去修改RTL. 驗證所有的Design後,就去FPGA平台驗證,確認無誤後就可以合成netlist。Netlist和RTL做比對,確認兩者是相等的,就跑Gate-level 模擬。如果結果不是自己想要話,就是回到DC重新合成或是到修改RTL。都沒有錯,就給後段工程師APR. APR後,就跑Post-level 模擬。如果有錯,回到gate-level修正,或是RTL-level修正。如果都沒有錯,CAD工程師把後段的所有工作檢查完。然後就tape-out. 每個步驟都代表階段工作已驗證完畢後,才可以往下一個階段進行。

從Fig圖,我們看到,IC流程被分為front-end和back-end兩個階段。
先說Front-end: 
我相信每位數位工程師都知道front-end的工作內容,在此就不贅述。數位工程師是否知道front-end階段中,他應該注意哪些細節,才會產出高品質的netlist。我提出幾點來供大家參考,如果你還有更好的想法,歡迎你也提出來分享!

1.RTL code都要是synthesizable(可被合成的),而且知道自己每個constrain的條件以及interface的timing要符合60/40原則。(60/40原則: 留給別人60%的timing margin。自己只用40%, 也有人說是40-20-40比例,40%自己用,40%是別的工程師用, 最後20%是留給CAD工程師做APR使用。)

2. RTL-level simulation coverage 要到90%以上。

3. FPGA驗證到錯誤時,必須把這個錯誤的情況重新複製到RTL-level simulation,建立完整的驗證資料庫,下一位工程師在改程式時,就不用在FPGA驗證時,才發現舊問題。混淆FPGA工程師驗證的流程。

4.合成時,確認每個D-flip-flop都有timing report可讀;每個path都有timing constrain;interface的delay都很完整。Clock的宣告都是符合你的設計想法。

5.做好clock tree和reset tree的說明,讓CAD工程師了解你的設計想法。

6.確認給CAD工程師的tcl檔案是對的,而且和你的DC tcl檔案是相符合的。

7.確認合成出來的netlist是對的後,才交給CAD工程師。

以上七點,相信大家都是認同的,但是有嚴格要求做到嗎?


舉例來說。相信大家一定看過 Interrupt的機制。如果沒有看過也沒有關係,下面是常見的Interrupt的機制。

原始範例:
always@(posedge clki or negedge rstni)
begin
    if(~rstni)
        IRR00 <=0;
    else if(B==1) //error happend
        IRR00 <=1;
    else
        IRR00<=0;
end

assign IR_EN00 = IRR00 & (REG_IRR_EN[0]);
assign IR_RST00 = (clr_id==4'h0);

  always @(posedge IR_EN00 or negedge IR_RST00)
  if(~ IR_RST00)
      IRR_00_Z1    <= 0;
  else
      IRR_00_Z1    <= 1'b1;
  else
      IRR_00_Z1    <= IRR_00_Z1;


就IRR_00_Z1這個D-flip-flop而言,合成時,你有特別宣告IR_EN00為clock嗎?IR_RST00位於reset tree上,在做ATPG時,DRC不會過,DC-compiler會幫你修正,但是你怎麼知道它會幫你做?它做的修正是你想要的嗎?是對的嗎?
或許你想反駁,這些的 timing不是很重要,所以不用管。ATPG會幫你修正reset或是clock時,tool不會錯。這樣子的想法和上述哪幾點相衝突?
第一點 timing constrain不曉得要怎麼寫?
第四點 沒有每個D-flip-flop都有timing report,因為 clock無法宣告。
第七點 無法確認合成出來的所有 timing是對的,因為timing report無法全部產生。

如果程式改成下面的情況時,是不是就做到我們的要求?

解決方式一:
always@(posedge clki or negedge rstni)
begin
    if(~rstni)
        IRR00 <=0;
    else if(B==1 & REG_IRR_EN[0]) //error happend
        IRR00 <=1;
    else
        IRR00<=0;
end

always@(posedge clki or negedge rstni)
begin
    if(~rstni)
        IRR00_sync <=0;
    else if(IRR00==1) //error happend
        IRR00_sync <=~IRR00_sync;
    else
        IRR00_sync<=IRR00_sync;
end
     
always@(posedge nosleep_clki or negedge rstni)
begin
    if(~rstni)
    begin
        IRR_00_Z1_pre_sync1 <=0;
        IRR_00_Z1_pre_sync2 <=0;
    end
    else
    begin
        IRR_00_Z1_pre_sync1 <=IRR00_sync;
        IRR_00_Z1_pre_sync2 <=IRR_00_Z1_pre_sync1;
        IRR_00_Z1_pre_sync3 <=IRR_00_Z1_pre_sync2;
    end
end

assign IRR_00_Z1_pre_sync4 = IRR_00_Z1_pre_sync2 ^ IRR_00_Z1_pre_sync3;
     
always@(posedge nosleep_clki or negedge rstni)
begin
    if(~rstni)
    begin
        IRR_00_Z1 <= 0;
    end
    else if(IRR_00_Z1_pre_sync4)
    begin
        IRR_00_Z1 <= 1;
    end
    else if(clr_id==4'h0)
        IRR_00_Z1 <= 0;
    else
        IRR_00_Z1 <= IRR_00_Z1;
End

clki和 nosleep_clki是我們一定會宣告。跨clock domain設false-path。IRR_00_Z1的 timing是不是就可以報告出來。

那原來的那段程式,是不是就不要再用?當然不是,我們是要符合七點的要求,design沒有做錯,為什麼要放棄?只要做些修正,重新合成,還是可以用。

解決方式二:
module interrupt_machine (
input clki
,input rstni
,input B
,input [3:0] clr_id
,input scan_mode
,output IRR_00_Z1
)
reg IRR00;
wire IR_EN00;
wire IR_RST00;
reg IRR_00_Z1;
always@(posedge clki or negedge rstni)
begin
    if(~rstni)
        IRR00 <=0;
    else if(B==1) //error happend
        IRR00 <=1;
    else
        IRR00<=0;
end

assign IR_EN00 = IRR00 & (REG_IRR_EN[0]);
assign IR_RST00 =scan_mode?rstni : (clr_id==4'h0);

  always @(posedge IR_EN00 or negedge IR_RST00)
  if(~ IR_RST00)
      IRR_00_Z1    <= 0;
  else
      IRR_00_Z1    <= 1'b1;
  else
      IRR_00_Z1    <= IRR_00_Z1;
     
endmodule

將 Interrupt_machine單獨合成,請CAD工程師幫忙做成 Macro,確保 timing都是你想要的,以call macro方式來合成全部的電路;而 IR_RST00部份,你也修正到適合ATPG情況。當你在跑模擬或是 formal check時,都可以確保你的 reset沒有做錯。

這兩種做法都可以達到你的要求,但是它的差別是什麼你知道嗎?

第一種解決的情況是工程師自己可以解決,可以在RD團隊中解決問題。

第二種是需要CAD工程師幫忙保證你的 interrupt timing,這需要跨部門的合作。

這就是我所說的數位工程師的風格。你是要成為只相信tool的工程師;或是每個module都需要別人幫忙的工程師;亦或是自己可以處理每個bug,並想辦法驗證它的正確性以及 timing constrain的工程師。但是不管是哪一種,都希望你都能符合上述的七個要求。