首先，先跟各位提醒：因為這是很久以前的經驗。我僅憑印象來陳述當時的想法，可能會和當時的想法有很大的出入，敬請各位諒解。如果有任何內容上的問題也歡迎寄信給我請我更正！
另外，我依稀記得比賽是只比較面積，時間則不評分但有限制在一個很寬鬆的範圍內。比賽官網上的版本則是比較功耗與運行時間的乘積。我以下會以當下只評比面積的方式進行說明。
題目描述
本題會給定 10 個人對於 10 個不同工作分別需要的工作成本，總共會有 100 個數值。我們需要選出一組具有最小總工作成本的配置方式。一個符合規定的配置方式是：每個人都要有工作，而且每個工作都會被分配到。
題目規定使用的演算法為匈牙利演算法，主要有 5 個步驟 (由於這邊演算法比較複雜，建議可以到原題目處查看)：
- Row reduction：將每行的值減去該行最小的數值
- Column reduction：將每列的值減去該行最小的數值。前兩步驟結束會如下圖：
- Test for a optimal assignment：需要確認每個行列都有 0 存在，如果沒有需要進行步驟 4。不過本題不會有這種測資，可以直接跳到步驟 5。
- More zeros：本題目沒有介紹這步驟。
- Making the final assignment ：只要有一個列只有一個 0 存在，就把這個 task 指派給那個人，並把這個 task 和這個人刪去。重複步驟直到結束為止。
硬體架構圖
硬體介面描述
| 腳位 | 內容 |
|---|---|
| jam_in | 8 bit 的工作成本 |
| en | 當為 1 時，tb 會連續輸入 100 筆資料。輸入完後會維持 0。 |
| jam_out | 8 bit 的工作成本分配答案 |
| cost | 指派的總工作成本 |
| valid | 當 jam_out 值有效時為 1 |
硬體實作
對於前兩步驟，我們就搜尋過該列或行，找到最小值後再將全部的值都減去他即可(每一行、列都分開做)。
對於第五步而言，我們原先的做法是統計每一行總共有幾個 0 再進行排序，選擇 0 的數量最小者。完全是按照原本的步驟進行。但後來我們發現這樣的做法會造成不必要的浪費。
最簡單的做法就是，我們一樣掃過所有的數值，當我們發現該行只有一個 0 時，就直接 assign。要注意這邊我們不需要跳過，然後直接找下一個解。雖然這樣的做法在時間上會比較短，但是這題的目標是最小面積，所以只要我們利用掃描的規則，並且做最少的存取，就可以得到更小的硬體面積。對於刪除行列的部分，我們一樣是利用掃描的方式，只去判斷掃描到的時候是不是那個位置，如果是我們再進行操作。
競賽細節
在剛開始我們想了很多做法，想到可以預先存取最小值，最後再一次處理前兩個步驟等等。但我們很快的意識到這樣的方法是時間上占優，硬體面積卻不占優的做法。回顧，我們提到要優化硬體面積的關鍵就是規則化。任何需要預存和利用她進行跳過運算的做法，一般來說都不會是一個好的做法。
在最後的步驟五，我們也應該利用一樣的方式來處理。我們不需要進行多餘的處理。我認為一個好的想法是，我們有一個可以掃描過全部數值的硬體，現在我們只需要紀錄一些 flag 即可。這樣就可以避免要預存和跳過運算而造成多餘的硬體浪費。
競賽心得
在比賽中，我在前面 30% 的時間都在思考時間上可以跳過的一些方法。後來，我們才恍然大悟，發現一個更規則的演算法才能有更優化的硬體面積。當我們想到這個的時候才開始優化步驟一和二。這時候，我們以為已經得到了一個很優化的解，就開始進行後續的 APR 了。由於這是我們第一次比賽，對於 APR 也不是很熟悉，最後弄到大概剩下 10% 的時間。
在這個最後關頭，我們才發現步驟五也可以進行類似的優化。而且新的做法在設計上更為簡單，我們也很快的寫完了(當然，剛開始還是決定先至少有前一個版本可以提交。也不太知道最後的這個版本是否來得及在比賽結束前完成)。最後，我們又把面積優化了將近 2x。印象中最後設計的面積大約是 6000um 左右。