BOOMと自作CPUの合成結果を比較して、ボトルネックになっている部分を調査したい。まずは面積から。
引き続きSTQの面積について調査している。FFの量は以下まで小さくなった。FDCxセルの量は273個まで減っている。
4 \FSM_sequential_r_entry_reg[state][] 5 \r_entry_reg[another_flush_cmt_id][] 5 \r_entry_reg[another_flush_grp_id][] 1 \r_entry_reg[another_flush_valid] 16 \r_entry_reg[br_mask][] 6 \r_entry_reg[cmt_id][] 4 \r_entry_reg[except_type][] 1 \r_entry_reg[except_valid] 5 \r_entry_reg[grp_id][] 1 \r_entry_reg[inst][oldest_valid] 1 \r_entry_reg[inst][rd_regs][][predict_ready] 2 \r_entry_reg[inst][rd_regs][][ready] 16 \r_entry_reg[inst][rd_regs][][rnid][] 2 \r_entry_reg[inst][rd_regs][][typ] 1 \r_entry_reg[inst][rd_regs][][valid] 1 \r_entry_reg[is_amo] 1 \r_entry_reg[is_committed] 1 \r_entry_reg[is_lr] 1 \r_entry_reg[is_rmw] 1 \r_entry_reg[is_rs_get] 1 \r_entry_reg[is_sc] 1 \r_entry_reg[is_uc] 1 \r_entry_reg[is_valid] 8 \r_entry_reg[missu_haz_index_oh][] 1 \r_entry_reg[oldest_ready] 33 \r_entry_reg[paddr][] 5 \r_entry_reg[paddr][]_rep 5 \r_entry_reg[paddr][]_rep__ 1 \r_entry_reg[paddr_valid] 5 \r_entry_reg[rmwop][] 64 \r_entry_reg[rs_data][] 1 \r_entry_reg[sc_success] 3 \r_entry_reg[size][] 33 \r_entry_reg[vaddr][] 10 \stq_snoop_if\.resp_s_be[]_i_ 8 \stq_snoop_if\.resp_s_data[]_i_
次にLUTの数だ。同様に計測した。やはりSnoop当たりの論理が大きいなあ...これはエントリ内で計算してはいけないものなのか?
grep -A2 LUT stq_entry2.sv | grep -v LUT | grep -v INIT | grep -v -- -- | sed 's/[0-9]//g' | sort | uniq -c
50 \FSM_sequential_r_entry[state][]_i___ 16 i____i_ 5 \o_stq_rs_resolve[index][]_i_ 3 \r_entry[another_flush_grp_id][]_i___ 16 \r_entry[br_mask][]_i___ 4 \r_entry[cmt_id][]_i___ 4 \r_entry[except_type][]_i___ 1 \r_entry[grp_id][]_i___ 7 \r_entry[hazard_index][]_i_ 5 \r_entry[hazard_index][]_i___ 1 \r_entry[inst][oldest_valid]_i___ 8 \r_entry[is_committed]_i___ 6 \r_entry[is_rmw]_i___ 2 \r_entry[is_uc]_i___ 3 \r_entry[is_valid]_i___ 10 \r_entry[missu_haz_index_oh][]_i___ 12 \r_entry[oldest_ready]_i___ 33 \r_entry[paddr][]_i___ 5 \r_entry[paddr][]_rep___i___ 5 \r_entry[paddr][]_rep_i___ 1 \r_entry[paddr_valid]_i___ 3 \r_entry_reg[inst][rds][][predict_ready]_i___ 4 \r_entry_reg[inst][rds][][ready]_i___ 10 \r_entry_reg[inst][rds][][valid]_i___ 5 \r_entry[rmwop][]_i___ 4 \r_entry[rs_data][]_i___ 1 \r_entry[sc_success]_i___ 3 \r_entry[size][]_i___ 33 \r_entry[vaddr][]_i___ 110 \r_ex_aligned_data[]_i_ 15 \r_ex_aligned_data[]_i___ 5 r_ex_mis_valid_i_ 22 r_ex_mis_valid_i___ 1 \r_return_dec[]_i_ 1 \r_uc_wr_paddr[]_i_ 192 \stq_snoop_if\.resp_s_be[]_i_ 687 \stq_snoop_if\.resp_s_data[]_i_ 2 \w_selected_array[]_i_
うーん、これはインタフェースがかなり大きいから、ということなんだろうか?
で、冷静に考えると本当にこのインタフェースは必要か?ということになる。 このSnoopインタフェースの目的は、外部コアからのデータの取得だ。コヒーレンス制御になるが、本当に取得できている必要があるならば、FENCEを打っておかなければならないはずだ。 これが使われる要素としては、SFENCE.VMAとかで、ページテーブルに書き込んだものがL1Dに確実に書き込まれて、かつL2に戻されて命令キャッシュから読めることを保証しなけべならないのだけれども、SFENCE.VMAが実行される時点でSTQからデータははけておかなければならないので、やはり不要ということになる。 そういう意味では、STQのSnoopインタフェースは不要かもしれない。とりあえず除去してリグレッションテストを走らせてみようかと思う。
このインタフェースを削除した結果、STQの面積は少し減ったがまだまだ大きい。まだ解析が必要だなあ。