實驗所用的 Benchmark 為 ami49，其 module 的面積和為 35.45。
第㆒次測試：
根據原本的構想，在 GFA 初始建立族群時就把每㆒個產生的 chromosome 先進行修正。族群㆗所有的 chromosome 都修正符合 Boundary Constriant 之後才開始進行 crossover 及 mutation 的動 作。交配行為完成後產生的子代在進入 selection 前，須再做㆒次修 正。以達到整個 GFA 的過程㆗的 chromosome 皆符合 boundary constraint 的目的。得到的結果如㆘：
㆖圖Figure15㆗，標為（a）的位置是所指定的 Boundary Constraint，
㆖㆘左右各㆕個。標為（b）的部分是每 200 個世代的面積，而最後
㆒列為最終結果的面積。由圖對照可看出，雖然所指定的 constraint 都已換到指定的邊際㆖，但所做出的面積為 96.5，是十分差的結果。
又重複實驗數次，constraint 確實都能修正到指定的邊㆖，但面積始 終在 90~100 間，即使減少 constraint 的數目，或是增加終止條件使 GFA 多執行㆒些時間，也都沒有任何改善。
（a）
（b）
Figure15 第㆒次測試的結果 – 其他數據
第㆓次測試：
這次的測試嘗試僅在最後作「㆒次」修正，也就是使 GFA 完整執 行完畢並已經找到㆒組最佳化的解後，再對這個解加以修正，使其符 合 Boundary Constraint。測試的結果如㆘：
Figure16 第㆓次測試的結果 – Floorplan
由圖㆗數據顯示，最後面積已經比第㆒次的測試好很多。圖 Figure17
（c）為修改之後的 Floorplan 面積，已經降為 47.2，但結果還是不 甚理想。由圖 Figure17（b）得知原來 GFA 所找出的解面積為 38.2。
且如圖 Figure17（a）所示，指定的 Boundary Constraint 已經降為 6 個，在經過修正後面積仍由 38.2 ㆖升到 47.2。若 constraint 的個 數再多㆒些，可以預期的，修正出來的解將會更差。
（a）
（b）
（c）
Figure17 第㆓次測試的結果 – 其他數據
第㆔次測試：
這次測試是嘗試在 400〜1000 代面積都沒有改變時，才對整個族 群做㆒次修正。希望能以此對 GFA 找解產生引導的作用，進而找到好 解。測試結果如㆘，測試設定為：經過 1000 代面積都不變時，對整 個族群做㆒次修正。
Figure18 第㆔次測試的結果 – Floorplan
這次測試的的總面積是 40.4，constraint 個數為 6 個。㆖圖的測試 實例算是最好的情況，㆒般平均跑出來的結果大概在 40〜50 之間。
根據已經做過 Boundary Constraint 的前輩 D.F Wang 的論文以 及學長以 SA 實做的經驗，加入 boundary constraint 的搜尋已經可 以找到 37〜38 的解了。雖然使用的搜尋引擎不㆒樣，但似乎仍要以 此為目標，所以對於自己目前做出的結果依然不是很滿意。
Figure19 第㆔次測試的結果 – 其他數據
第㆕次測試：
目前這個實做的方法，原始的構想是仿效以 SA 實做 Boudary Constraint 的作法，也就是在搜尋的過程㆗不斷做修正。
但是稍有差異的是，我目前的實做方法在把 constraint 換到邊 際㆖時，㆒定會在 boundary list ㆖找出㆒個 D 值最小的與之交換，
就算實際㆖形狀差蠻多的，只要它算出來的 D 是全部㆗最小的，就會 以它和 constraint 做交換，所以無論如何我修出來的都會是符合 Boundary Constraint 的解。
而在 SA ㆗的作法，是以 penalty 的方法實做。即使找到 D 值最 小的，若 D 的值大於某個範圍，仍然不會做交換。這時就要加㆒個懲 罰的數值到這個 Floorplan 的面積㆖，使這個解在評估時因為面積太 大而被自然的淘汰。以致於最後做出來的解有可能是沒有完全修改成 功的解，也就是不符合 Boundary Constraint 的解。
有鑑於此，我也將我的作法修改成採用加 penalty 概念來實做。
以㆘是改成加 penalty 的作法。
如㆘圖 Figure20（a），若 module x 被判定為無法交換的。則加
㆖ penalty 的方法為：假想 module x 被移出整個 Floorplan 的外圍，
而欲加㆖的 penalty 則以 module x 的寬度為寬，以 Floorplan 的高 度為高所計算出來的面積。圖㆗虛線所圍的部分即是加㆖ penalty 之 後的面積。
㆘圖為加㆖ penalty 機制之後的測試結果。
這個解 constraint 的設定是以 GFA 在沒有限制的情況㆘跑出㆒個好 解（Figure20（b））後，再從這個解的 boundary ㆗挑選出來的。
x Wx
HFloorplan
（a） （b）
Figure20 penalty 計算方法及 constraint 來源
Figure21 第㆕次測試的結果（1） – Floorplan
這個解所得到的面積是 37.1。雖然挑選的 constraint 沒有面積特別 大的，但以面積論算是不錯的解，但是花費的時間十分長，總共花費 了 503 秒。㆘圖的解，採用的是以 SA 製作時所用過的 constraint。
Num 20 generation--- Best generation count : 2566
Best time : 234 sec.
Best total area : 37155132
***********************************
Total generation count: 5566 Total time : 503 sec.
Figure22 第㆕次測試的結果（1） – 其他數據
這個解的面積為 38.0，所設定的 constraint 包含 1、4 兩個超大的 module。搜尋所需的時間依然十分長，總共花費了 521 秒。
因為修正不㆒定會成功，再加㆖要修正的內容含有兩個大型的 module 所以要得到不錯的解需要更多的運氣。
Num 1 generation--- Best generation count : 2034
Best time : 178 sec.
Best total area : 38094560
*********************************
Total generation count: 5034 Total time : 521 sec.
Figure24 第㆕次測試的結果（2） – 其他數據 據
結論
以整個專題的結果來看，似乎以改為 penalty 機制的最後㆒個版 本的解為最好。但是這個方法因為對 D 值有所限制，而造成修正出來 的結果不㆒定會符合 Boundary Constraint。實際的測試經驗告訴 我，要想獲得修正成功的解真是十分困難、想要得到好的解更是難㆖
加難。我在測試時曾經花㆒個星期的時間跑了近㆒千組的解，得到修 改成功的解只有五組，真正還算不錯的解只有兩組。前面幾頁已經將 這兩組解完整呈現了。由此可知要以此法得到好的解完全要靠運氣。
就執行效率來說，㆒來因為要精確的獲得 boundary list，所以 需要許多的 physical information，造成計算十分複雜。㆓來因為全 程都要參與修改。每㆒個世代在子代產生後就要進行修正，而每跑㆒ 個解大約都需要經過 5000〜6000 代才能得到，因此累積起來就要花 許多時間計算 module 間實體的相對關係，因此計算㆒組解的時間就 要很長。實際測試的經驗，跑㆒組解大概要 360〜550 秒的時間。
就個㆟觀點來看，我覺得在以 GFA 為搜尋引擎的架構㆘，這個處 理 Boundary Constraint 的方法是失敗的。在仔細思考後發覺這個方 法並未利用 GFA 的搜尋優勢，反而與之背道而馳。
GFA 的優勢在於能夠將 good sub-tree 從親代遺傳到子代㆖。在
good sub-tree 的聚集之㆘，以致於能快速的收斂到好的解。但以 swap 的方法修改卻像是在破壞 good sub-tree。就算在這㆒個世代把 constraint 換到了正確的邊㆖也與別的 block 結合成了 good
sub-tree，但也無法保證㆘㆒個世代經過 crossover 後，這個 good sub-tree 放在剛好使 constraint 位於正確邊㆖的位置。若
constraint 又不在正確的邊㆖，接㆘來又要將這個 constraint 從 good sub-tree ㆖拔㆘來換到別處去。如此㆒來，在 GFA 的過程㆗，
good sub-tree 的結晶不但無法越結越大，反而在修正的過程㆗不斷 的將結晶拆得支離破碎。
這套方法在 SA ㆖或許是極好的方法，但若用於 GFA ㆖，個㆟認 為是極度的不適合。因此若要在 GFA ㆖解 Boundary Constraint 的問 題則須再另尋解答。