AMBAバス

GrlibのAMBAバスマスターエミュレータ２つとAHBメモリ２つとAHBコントローラをつなげて、write, read, burst write, burst read を実行させるRTLシミュレーションをmodelsim上で実行しました。
AMBAの基本的なプロトコルは以下のようなものです。

http://www.geocities.co.jp/leon_processor/AMBA-ov.html

基本は簡単。
マスターがバス使用の要求を出して認可されるのを待ちます。
認可されたら、アドレス信号とコントロール信号を出します。
次のクロックでデータが送受信されます（ライトならマスターから、リードならスレーブから）。
もし、次のクロックでスレーブが応答できないなら、HREADY信号をアサートしてデータのフェーズを後ろにずらします。
基本的にはこれだけです。

ただ、仕様書に、数学的に厳密な記述がないので、細部があやふやな理解になってしまいます。。。。
結局マスターとスレーブのモジュールそれぞれ何か一つ選んで、VHDLをちゃんと解読したほうがはやそうです。

SPLITとRETRYは結構めんどうくさそうですが（まだちゃんと理解してない）、LEONシステムでは使用しないようにコンフィグレーションができたと思いますので、今後はこれは使用しないで全体が問題なさそうであれば、使用しないように設定するつもりです。

AMBAバスは、すべてが組み合わせ回路で、トライステートのゲートを使用した双方向パスがありません（コントローラ中にはレジスタは必要）。ARMプロセッサは組み込み市場で圧倒的な力を持つにいたったのですが、その理由の一つに合成可能なRTLマクロとして使用できるように提供されたということがあると私は思っています。
（もちろん、低消費電力とかコードが小さいとか、ほかにもいろいろあると思います。）
組み込みにおいては、プロジェクト毎にASICに追加するペリフェラルが変わります。そこでRTLベースのソフトマクロで、ASICの設計フローに組み込みやすければ非常にありがたいです。
AMBAのように組み合わせ回路で作られたバスであれば、バスそのものやコントローラもRTLで簡単に記述できます。これが、AMBAの構造を決めた大きな理由ではないかと私は推測しています。

その代わり、AHBは、ある信号の次にかならず、ある信号が流れるという時間的な制約がかかっています。例えば、スレーブにアクセスがあった後に応答延長のHREADYは必ず次のクロックでマスターに伝えなければなりません。プロトコルがパイプライン化して対応できるようになっているのかもしれませんがよく知りません。
これは、微細化が進むとASICでは厳しくなります。クロックはGHｚ級になり、nsec級の回路設計が必須になってきています。しかし、配線の抵抗Rは微細化のスケーリング則にのらないので、チップの端から端まで信号を伝えるのがどんなにうまく設計してもnsec単位かかるようになってきます。
もうひとつ、問題になるのかもと思うことは、AHBでは接続モジュールがN個あった場合に、バスやコントローラの回路規模がNの指数関数的な増加になることです（多分）。将来モジュールの個数がある程度を超えると極端にAHBのバス回路そのものが負担になると思います。

ここらへんの問題があるので、次世代バス（OPC等）は、この手の制約を緩めたプロトコルになっているはずです。通信的なプロトコルになっているはず。
ARMも多分OPCのようなバスであるAXiを発表していました。けど、あまり適用例をみたことが無かったのですが（一回だけTI関連の記事をみた）、昨年発表された、qualcommのsnapdragonという鳴り物入りのモバイルチップで適用されていました。ASIC主流のバスがそろそろ変わるのかという印象を持ちました。