H7　SEPの論理設計 – 静岡大学情報科学実験C 情報サイト

H7の実験終了の定義

以下の４点をクリアすること

SEPデータ転送制御一覧表を作成しスタッフ・TAに確認してもらうこと
H7のSEPの実機動作チェックをスタッフ・TAに確認してもらうこと（※以下の説明参照）
実験報告書を提出すること
最終発表・口頭試問を行うこと

1. SEPデータ転送制御一覧表のチェック

作成するSEPの使用ならびに動作を定めた「SEPデータ転送制御一覧表」が記載されているかどうかのチェックを行う。

2. 実機動作チェック

実機動作チェックではテストプログラムおよび自分たちのプログラムをメモリに転送して動作させて、確認を行う。

テストプログラムではADCやMULなどの追加命令に対応していない。つぎのように自分でバイナリを指定することで動作させてみること。

     .org    0x100
     mov     #0x1c73, r0
     mov     #0x0a3d, r2
     .word   0x9002      ; 1001 0000 0000 0010 つまり MUL R0, R2 に対応
     mov     #0xffe0,r1
     mov     r3,(r1)    ; 結果の表示（上位16bit）
     mov     (r1),r0    ; 入力待ち
     mov     r2,(r1)    ; 結果の表示（下位16bit）
     mov     (r1),r0    ; 入力待ち 
     hlt

なお、実機動作チェックはなるべく実験H7の最後の回までに済ませてください。
最終発表当日にも可能な限りチェックはしますが、チェックできる人員・時間が限られています。

（※）実装は完了しているものの実機動作がうまくいかず最終発表までに動作させるのが難しい状況である場合は、チェックを行う代わりにうまくいかない原因についての検討・考察を行ってください。

実機動作チェックリスト

テストプログラムのページにあるサンプルプログラム1〜5が正常に動作することを確認する。
追加命令(ADC, SBC, RLC, RRC, MUL, DIV)の動作をチェックできるプログラムをメモリに書き込み、正常に動作することを確認する
割り込み制御が正常に動作することを確認する。SEPインターフェース回路使用マニュアル p.16 にあるタイマ割り込み使用例のプログラムをメモリに書き込み、正常に動作することを確認する。
（オプション）情報科学実験Bの独自プログラミング言語で記述したプログラムをコンパイル、アセンブル、機械語に変換した上でSEPボード上で正常に動作することを確認する。

// テストの例：フィボナッチ数列の第n項を求めるプログラム
int fib(int n) {
    if (n >= 2)
        return fib(n - 1) + fib(n - 2);
    else
        return n;
}
int x;
int a;
x = 10;           // 入力値はトグルスイッチにしてもよい
a = fib(x);
printLED(a);      // printLED()は結果をLEDで表示するようなアセンブリを出力する

3. 実験報告書の提出

今一度、実験レポートの書き方を参照して、実験報告書の記載には注意をしてほしい。特にH7の実験では分量が多くなる傾向にある一方で、ほとんど同じものをいくつも設計していたりする。実験レポートは分量ではない。似たような設計（例えばR0-R7レジスタのような）共通な特性、それぞれ個別の特性を明確に分けて説明・設計するなど、コピペをせずに、同じところは（必要であれば以前の実験の報告書を引用したうえで）「〜と同様とする」とし、異なるところがわかるように記載されることが望ましい。

また、分量が多くなればなるほど矛盾や不一致、不整合が起こる可能性が高くなる。論理式や真理値表，入力要求表など設計のもとになるものを複数コピペせずに正本となるものを１つだけ記載し、本文からは図表番号により参照するなどの工夫をすれば、不一致・不整合などは削減できると思われる。下手に再掲などするから手直しをする際に不一致や矛盾の原因となる。

H7の論理設計と関係のない記載は控えたほうが良い。例えば、ADC,SBC機能を持ったALUやRRC,RLC機能をもつシフタの制御信号とその演算結果が求まる理由などは、それぞれの実験の中で行われているはず。その結論のみを参照すれば足りるはず。今回はその結論を使ってH7の演算器を設計しているはずであるから、その一段上位に抽象化した記述（結果の動作だけ）を使って設計している。そのへんの記述の抽象化レベルを書き手がきちんとコントロールできるよう注意してください。

さらに説明を求められた時（検討事項など）には、文章だけで説明するのではなく、図や表・数式等を使って簡潔に示した後、その説明や解説を文章で補うほうがわかりやすいことが非常に多い（H7の検討事項ではほとんどの場合、それで解決しそうである）。図表数式を活用して簡潔に説明ができるよう工夫してほしい。

4. 最終発表・口頭試問について

最終発表では以下の項目を含めること。なお、最終発表で問われる検討事項は報告書の検討事項の項目の一部である。ただし、6.5以降の各命令の動作説明は報告書のものと異なるので注意。

目的・目標
班で定めた仕様（実装命令一覧など）
アーキテクチャと役割分担
設計・実装上の工夫 +成果・結果
反省点
できなかった事柄を挙げて「次はがんばります」「次回気をつけます」ではきっと次回に活かせない。実験を振り返ってみて下記の項目のようなことを考察し、その要因を分析し、その要因を具体的に解決する手段・手法について提案してもらいたい。
- この実験を通して達成・実現できた価値のあることは何か
- 逆に達成・実現に至らなかったこと、チャレンジしたけど失敗したことは何か
- 達成・実現に至らない，失敗にはどんな要因（思い込み，決めつけ，恐れ，価値基準等）などがあったか
- その要因をどのようにして取り除けばよいか
検討事項　※1
- 6.1 (4)&(16) ※2
- 6.2 (6)&(7)　※3
- 6.3 (9)&(13)　※4
- 6.4 (14)&(15)　※5
- 6.5 RLC D0:I3 (RLC (R3)) の動作を状態遷移に従って説明せよ。ただし、R3=0xFFE0の場合とR3=0x0200の場合の両方について説明せよ。
- 6.6 RIT MI6:D7 (RIT) の動作を状態遷移に従って説明せよ。
- 6.7 BRN IP7:D7 (BRN label) の動作を状態遷移に従って説明せよ。
- 6.8 CMP IP7:D0 (CMP #imm, R0) の動作を状態遷移に従って説明せよ。
- 6.9 MUL D0:D2 (MUL R0, R2) または DIV D0:D2 (DIV R0, R2) の動作を状態遷移に従って説明せよ（実装した方の命令について解説すること）。

※1 6.1〜6.4については、2つの項目をまとめて説明してもよいが、問われていることに答える説明にすること

※2 いつ、どこで、何が起こっているかを、正しいタイミングで説明できること。特にクロックとの関係についてみます。自分たちが実際に実現した実装方法を示してください。ただし、全てをクロックサイクルで説明しろといっているわけではない。説明に適切な抽象度を用いて説明すること。

※3 なぜMREQ,IORQがあるのにMIRQを使う必要があるのか？メモリマップドIOでない（アイソレートIOまたはIOマップドIO）と比較してどちらは、どんなことに優れ、どんなところに劣っているのか？

※4 「不変とすべき理由」を説明するはずなのに「変えなくても良い」とか「変える必要がない」というニュアンスの文章を並べるのは論点がずれている。「変えてしまっても、同じ命令をもう一回実行すればいいじゃん。どうせコンパイラがコードを自動生成するんだし、ユーザーが面倒なことはないもないじゃん」というよくあるコメントがあるが、それに対する反論はないか？

※5 「ほぼ同時に」との記載があるが、「同時」と解釈される時間に差がある。2つの信号の差がどこまでであれば、「同時」とみなされるだろうかということについても言及して欲しい。

発表時間は15分＋質疑応答・口頭試問20分（理解不十分な（口頭試問に答えられない）場合、延長または後回しあり）とする。最大60分/班を目安とする。

検討事項の部分は口頭試問形式で個別に回答してもらう。1人につき6.1〜6.9の9つの項目からその場でランダムに選ばれた1つを回答することになるので、誰もが説明できるようにしておくこと。怪しい時にはより深いツッコミがある。

連絡事項

プログラマ電卓

Windowsの「電卓」を起動し，”標準”と表示されている部分の左側メニューボタンから「プログラマー」を選択．

HEXを選択すると16進数での演算ができます．

詳しく知りたい場合は自分で調べて下さい．

また、ブラウザのアドレスバーで 0x1f * 0x4a などと入力しても答えが出ます。

逆アセンブラ

逆アセンブラが欲しいという多少の声にお応えして作成しました．

Teams上の「一般」＞「クラスの資料」＞ src ＞ disasm.exe
にあります。

コマンドプロンプトから

> disasm.exe hogehoge.mif

の様に使って下さい．

不具合などが起きた場合は対応できませんので，自己責任でご利用下さい．

SEPデータ転送制御一覧表

SEPプロセッサの設計もH7の加減乗除算器と同様にデータパス部と制御部に分けることができる。制御部の設計において下記のSEPデータ転送制御一覧表を埋める必要がある。

それぞれのステージや命令でデータパスのコンポーネントに出力される信号線を縦方向に埋める。それぞれの信号線がどのタイミングで1/0なのかを読むには、表を横にたどればよい。横にたどって信号が1になる条件を作り出して、制御信号の生成を行う。

実験ボードと回路のインターフェース

インターフェース回路は

\\fs.inf.in.shizuoka.ac.jp\share\class\情報科学実験C\src\sep5_Interface_w_ext
Teams上の「一般」＞「クラスの資料」＞ src ＞ sep5_Interface_w_ext

に置いてある。sep5_Interface_w_extフォルダーを各自のワークフォルダにコピーして、

Quartusのライブラリに追加して利用する。

sep5_top.qpfのプロジェクトファイルを開くと、トップレベルエンティティがreg16_pc_interface.bdfとして回路図を開くことができると思う。

トップレベルエンティティは、 reg16_pc_interface.bdfの回路を別名に保存してトップにするとよい。ピンの割り当ては sep5_top.qsf を用いること。従来の DE2_115_Default.qsf と同じものです。必ず、ピンの割り当てを行うこと。

インターフェース回路…割り込みに使用するタイマー割り込み信号名をEITからTIT0に変更しました。信号名EITと紛らわしいのをTIT0にして解決を図りました。

LCD出力ポートのSCのポートを [11..0]から[15..0]にしました。使わないSCの信号には0を入力するよう接続してください。このアップデートによりSCの表示ポートにも16ビットの信号を入力して16ビットのデータを観測できるようになります。

インターフェース回路の使用に際して注意事項

インターフェース回路への入力となる未使用の端子を開放（なにもしないまま）にしておくとエラーがでてコンパイルが失敗するので、コンパイルを通すためにcap xx_valueモジュールを繋いで値を入力している。別の入力を入れる場合には、cap xx_valueモジュールを削除して、オリジナルの入力を入れること。

削除しないまま入力を接続した場合には、信号が衝突している旨のエラーメッセージが出てコンパイルが失敗する。

割り込み発生回路・走行制御用回路の補足

\\fs.inf.in.shizuoka.ac.jp\share\class\情報科学実験C\src\itf_run
Teams上の「一般」＞「クラスの資料」＞ src ＞ itf_run

に置いてある。itf_runフォルダーを各自のワークフォルダにコピーして、Quartusのライブラリに追加して利用する。

割り込み発生回路

割り込み発生回路は itf_runフォルダーのitf.bdfがその回路図である。

（シンボルファイルではない）

ITA発生回路

上記の割り込み発生回路をそのまま使う。

以下、補足説明

計算機アーキテクチャII教科書のp.66にあるように、ITA発生回路をつくる必要がある。

ITA信号生成回路

ここで、＜外部パソコン信号＞と表記されている信号は、SEP5では、タイマー割り込みを使用する。タイマー回路からの内部信号なので、「整形・微分回路」を通す必要はない。この信号は、sep5_pc_interface のTIT0の信号を入力する。SEP5のプログラムからタイマーをイネーブル（使用可能）にすることで、定期的な割り込み信号を得ることができる。

また、＜SEPボードスイッチ信号＞もsep5_pc_interface の BIT_N 端子からの信号を微分回路に通した信号を入力すればよい。BIT_N信号はKEY[3]入力を波形整形して取り出した負論理の信号である。微分回路は、p.91の図15.3中のRS1,RS2,ANDで構成される回路で、1クロック分の短いパルスを発生させることができる回路である。微分回路を通した信号を＜SEPボードスイッチ信号＞に入力すること。KEY[3]を押すことで外部からの割り込みを発生させることができる。

上から2番めの※１のANDの入力信号EIT信号は、その右側にあるJK−FF（EIT）のQ出力を入力する。同様に※２の入力信号EIT_NはEITのFFの否定出力を接続する。またOIT入力はOITのFFの出力を接続する。

走行制御用回路

走行制御用回路は itf_runフォルダーのrun.bdfがその回路図である。

以下、補足説明

インターフェース回路から走行制御用回路に接続する信号は以下のとおり。

スタートS信号←コンピュータアーキテクチャIIの指導書を参考に作成する(正論理であることに注意)
クロックステップ信号←CLKSTEP信号
RUN2← 走行制御用JK-FFのRUN2出力
命令ステップ信号←INSTSTEP信号
IF0のD入力(IF0D)←ステータスカウンタ(SC)のIF0のDフリップフロップへの入力
通常走行モード←NORMAL信号
HLT← 命令デコードのHLT信号
EX0←SCのEX0
ストップスイッチ(AUXI6)←STOP信号＝（インタフェース回路の出力の）AUXI6信号
リセットRESET←RESET信号(正論理であることに注意)
SEPオリジナルクロック←（インターフェース回路の出力の）CLK信号

走行制御用回路の出力信号「CPU CK」（回路上ではCK）はそれぞれのSEPの構成要素（MARやMDRなどのレジスタやステータスカウンタなど）のクロック信号に接続する。さらに、走行制御用回路の出力信号「CPU CK」（回路上ではCK）はインターフェース回路の入力信号「CPUCK」にも接続する。

図15.1はそれぞれANDを取って配線されているが、ひとつのANDから配線して良い。複数書かれているのは、ANDゲートの駆動能力を分散するように記載されているものであり、Quartusでは駆動能力を自動で分配するので、1箇所のANDから配線してよい。

注意事項

実験レポートを書くにあたって

目次の例を以下に示す。必ずしも、この項目に従う必要はないが、読み手にとって順を追って情報を提示され、トップダウンに全体構造を理解できる書き方が望ましい。

実験の目的
SEPの論理設計を通して何を学ぶのか？なにを理解するのか？
実験の原理、方法、使用装置および機器
この章の最後までには、このレポートで使用するすべての用語の説明・解説は終了しておく必要がある（データパス部、ステータスカウンタ、デコーダ、割り込みの対処方、命令演算の仕様や動作、FFの動作タイミングなどなど）。
1. 四則演算の仕組み
  実現するSEPのアーキテクチャ（ブロック図）について説明し、そのアーキテクチャの上で、命令や割込みの処理を行う仕組みなどを解説する必要があるでしょう。
2. 実験の実施方法
  今回の実験５日間ありますが、それぞれ誰が何をしましたか?どのようなスケジュールで実施するつもりでしたか?→実際にどのように実施したかは実験結果（または考察）。具体的にどのような実験を実施しましたか？
3. 使用装置および機器
  いつものとおり？
4. (必要であれば用語の定義等）
  上記の解説で、用語の定義が不十分であると感じたら「用語の定義」などの節を設けて、レポートを読む準備としての用語の定義，用語の意味，用語の解説などは済ませておく方がよい。
実験結果
今回の実験は何が実験結果として必要なのかを、まず考えて欲しい回路の設計は実験なのかどうか、実験に入らないとすれば、この実験結果の提示までに何を読者に示しておく必要があるのか？実験に入るとするとどのような順で説明をされるとわかりやすいか？を考えて記述する内容を構成してほしい。
実験回路の設計
全体から詳細に説明が進むようにまずは、全体から説明。そこで、どのような部分に分解することができるのか、等を解説。要はなぜそうするのかが重要・必要である。実装の方法は色々と考えられるはず、その数多くの選択肢のうちでその実現方法を選択した理由を述べること。
1. 実験回路の要求分析，機能仕様
  実験として、何を目的に、何を実現するのか、実現しなければならない機能は何かを明確にする。つまり、これができてなければ実験として失敗でしょ。これができていればOKでしょ、と言うものを明らかにしておき、実験結果中にそれらがちゃんとできあがっていますよね、ということをアピール・証明・提示しながらレポートを書き進めていけばよいわけ。
2. 設計方針，設計思想
  なにを考えて、実験回路を設計するの?早いもの？簡単な（ゲート数が少ない）もの？使いやすいもの?正確な（正確とは?）もの？なにを基準に回路を設計しようと考えたのか。実現方法が複数ある場合に、選択の基準になる考え方・ポリシーは何か?
3. 実験回路のアーキテクチャ
  いろいろと試行錯誤を繰り返して、最終的な実験回路にたどり着いたとは思うが、レポートでは試行錯誤は検討事項・考察にし、最終的な実験回路・アーキテクチャにした理由等を交えて回路のアーキテクチャについて解説する。
4. 実験回路の設計部分
  全体の動作や解説が終わったところで、だんだんと詳細な内容に移っていく。皆さんのレポートは、いきなりなんの予備知識もなく詳細な回路の説明や解説になってしまっている。
  - データパス部：データパス部の主な動作，主な構成要素，主な機能などの解説，実回路図の提示
  - 制御部（ステータスカウンタ＋命令デコード＋信号生成ロジック）：制御部の役割、位置づけ，設計方針の解説などを記載するとともに実回路図を提示する
  - インターフェース：演算スイッチ，CLR,CLKなどの人とのインターフェース、ALUやシフトレジスタの制御信号等のインターフェースにかかわる信号の意味や動作にかかわる解説などを行う
  - 可能であれば動作テストの結果：　何がどう動いているのかそれを確認するテストデータと観測したデータを記載。
実験の検討・考察
1. 回路の設計方針・過程について
  主要な回路の設計については、実験結果のところで述べてあるはず。ここでは、実験結果中に書けなかった、設計の過程や試行錯誤などについて、主要な過程や考察・検討した内容などについて記載することになる。設計の過程で、迷ったこと、つまづいたこと、やってみて理解できたこと、想定と異なっていて実装中に軌道修正や訂正をしなければならなかったことについて経緯を報告する。「ああした，こうした」的な事実だけの報告ではなく、なぜそうしなければならなかったのか、そうした理由は何かを明らかにすること。そこが重要！！。
2. 検討事項について
  (1)から(20)の書く検討事項に対して、全て検討してレポートにする。
  - よくあるまずい解答例 (^^;;
    - (1) …直結してはならない理由：　「壊れるから」「コンパイルエラーになるから」ではダメ。仮定としてどんな回路がデバイスに採用されていて、それの出力が直結されるとなぜ壊れるのかを述べること。直結しても壊れないデバイスもある。なぜコンパイルエラーにしなければならない（システムが厳密にチェックして排除しなければならない）のか。を検討すること。
    - (6) メモリマップドIOの長所と短所：比較の対象を「IOマップドIO(アイソレートIOともいう)」とし、比較をして『「IOマップドIO」はIO命令を発行してそのあと他のことができるが、「メモリマップドIO」はできない』はウソ！。（例えば、IN命令，MOV命令…と続く命令列を考えたとき、IN命令で入力を行っていて入力が終わる前に(IN命令が終了していないのに)次のMOV命令を実行することができるならば、命令を追い越していることになる） IOマップドIOはIN命令やOUT命令が存在し、メモリマップドIOはMOV命令でIOを実現するとする。IN／OUT命令を発行して、実デバイスにIN/OUTが完了しなければ命令が終わらない（IFステージに戻ってこない）(ブロック型の命令)とすると、IN/OUTが完了しなければ命令処理がそこで停止してしまう（他のことはできない）。もし、実デバイスにIOが完了しなくてもIN/OUT命令が終了できる（ノンブロック型の命令）とするとMOV命令でもIOが完了しなくても処理は継続できる。つまり上記の考察は同じ土俵で比較していないことによる結論であり、間違っている。どんなプロセッサなのか前提条件により変わってくるものかもしれないのに、前提条件を明らかにしないまま議論を進めてはダメ。
    - (9) PSWを不変とすべき理由：　「PSWが変更されると困るから」ではダメ。例えばBIT命令後にフラグを見て分岐する命令BRZを使い、不成立の場合その後別のフラグを使う命令があるとき、変更されると困るというロジックのようだが、成立／不成立の場合、改めてフラグをセットし直すことで所定の処理は可能である。「困る」という説明もなんだかなぁって感じ。「どう困るのか」、「なぜ困るのか」、「どんなところに問題が生じるのか」という説明はない。なぜ不変とすべきなのかを論理的・合理的に説明してほしい。変更しなければどんな効果が期待できるのだろうか？他にも(10)なども同様。PSWを絶対に不変としなければならない場合と必ずしも不変にしなくても代替手段があるので良い場合がある。これらすべてをひっくるめてPSWを不変にしなければならないという論旨はちょっと乱暴すぎる。なぜ代替手段ではダメなの？明確な理由を示すこと。
    - (20.a) …MARにもMDRにも格納している理由：　「操作の共通化」だけではダメ。「どういうこととどういうことを操作を共通にしていて、その効果はこういうところにある。」など共通化することの利点や効果について考察すること。「MARとMDR両方に入れることで正しく動作するように設計されているため、両方に入れないとうまく動かない」これもダメ。本来設計はみなさんがやるべきこと。別に両方に入れなくてもその都度判断して適切な方に入れて全体を動作させることはできそうである。なぜ、そんな回路にしなくて、両方に入れる設計にしたのか、設計の思想としてなにを目指して、どうしたからこうなったのかを検討すること。他にも(13)の問なども同様。

設計方針について

設計方針とは、設計をする際に何を目指すのかということ。ハードウェアの場合には、主に以下の３つにまとめられると思う。もちろんこれ以外の基準や指標があるかもしれない。○○家のキャッチコピーではないが、言い当てているので使わせてもらう。

旨い「旨い」は製品の質、実験ではプロセッサの処理速度のこと。プロセッサの性能は、動作終了までの実時間や、同じクロック周波数で動作することを仮定して１命令を処理するにあたりかかるクロック数などで評価される。平均命令サイクル数が小さいほど単位時間あたりに処理される命令数が少なくなるため、高速であるといえる。
同じ機能を実現する2つのプログラムを同じプロセッサ上で実行したとすると、実行完了までにかかる命令数やサイクル数が小さいプログラムの方が実行を終了するまでの時間は短い（コンパイラのコード生成が優秀である）。
ユーザにとっては、実行が終了するまでの実経過時間が体感速度となる。体感速度が早いプロセッサが高性能なプロセッサとなる。
安い「安い」は製品の製造コスト。実験ではゲート数・配線数に相当するだろう。コストを十分にかけて早く作ったり、高速なものを作るのは可能であるが、高い製品を買ってもらえるだろうか？かけたコストに見合っただけ性能が高くなっているか？
メモリの使用量が少なくて済むのも低コスト化につながる。同じメモリ使えるならより多くの命令が搭載できる方がお得。
早い「早い」は製品ができあがるまでの時間、完成までにかかる時間。開発期間のこと。以下のゲート数が少なくて、高性能なプロセッサが設計できても、実機チェックに間に合わない／完動しない、開発期間が足りないのではダメでしょ(標準命令の実装にかかる時間は取ってある)？ただし、設計者が手を抜くためにことを考えていてはだめ（それは、「開発者の能力が低いため納期に間に合わせるために、成果の品質を犠牲にしました」ということを述べていることに他ならない）。

どれかを選んでそれだけに注力するのでは良い製品は得られなくて、それぞれのバランスが大切である。皆さんが設計をするとき／設計結果で「よし」としたとき、どれを優先して考えていましたか？それに回答を持っていてほしい。口頭試問も上記の基準のどれに該当するかを考えてほしい。

プレゼンをするにあたって

話を聞く人の興味がどこにあるのかを忖度しながら説明すること。
下に抽象度の例を示す。毎度毎度、命令レベル/RTLレベルの抽象度で説明されても、何をしているのかという説明になっていない。説明の量が増え、機能の説明にはならず、時間のムダ。何を示すべきかを判断して、適切な抽象度で説明するように心がけてほしい。

	ソフトウェア：命令レベル/ハードウェア：RTLレベル (Register Transfer Level)	動作レベル	機能レベル
ソフトウェア	XOR R0,R0 MOV R0,S	S=0;	変数Sを０クリアする
SEPの説明	IF0: R7→Abus (Abus,0)→ALU(a+b)→Sbus Sbus→MAR, MDR IF1: 1→MREQ_N R7→Abus (Abus,0)→ALU(a+b+1)→Sbus Sbus→R7 MBus→ISR	R7→MAR,MDR 1→MREQ_N MBus→ISR R7+1→R7	命令フェッチする（PCが指すメモリ番地から命令を読み出し、ISRに取得すると同時にPCを更新する）