H1　FPGAと論理合成ツールと論理回路

実験結果の共有について

班内で実験の結果を共有してよいかどうかについては、各自の実験がどのような実験をしたかによります。各自が実験の内容を振り返って判断してください。何をしたのかによって、共有してもよいのか否か、共有すべきか否かが決まります。また、教員が許可すべきことではありません。やったことを正直に報告書にすることが大切です。

例えば、1つの回路を使って4人が動作を確認したのであれば、その実験の報告は1つの回路に対しての報告になるはずです。各自が実験回路を書き起こすのがスジだとは思いますが、Quartusで描いたのですから、それを共有するは、よしとしましょう。で、その実験方法で良かったのでしょうか？

【しかし！！】その書き方が問題になります。今回のレポートは各自が記述して提出します。ここで注意しなければならないのは、「人（他人）の仕事を、自分がやった仕事かようなレポートを記載してはならない」です。自分ではやっていないにもかかわらず、自分がやった仕事かのように記載しては虚偽の記述になってしまいます。個人のレポートは、特に断らない場合には、提出者（筆者）がやった仕事を書きますので、何も断らなければ、自分の仕事になってします。ここは注意して欲しいところです。

報告書（レポート）の書き方に対する注意事項

  • 実験結果はどの信号をどの観測器を使って観察・観測した結果なのか、観測した信号は入力だったのか出力だったのかがわかる表の記載をすること。
    信号線名のみ、観測器名のみの表で結果を提示されているが表だけをみてわかるよう記載する。本文中に書いてあるから良しではなく、報告書本体を隅から隅まで読んで記載を探せというのは不親切。
  • 導出の過程が飛ばないように。
    仕様→設計→カルノー図→最適化→回路の一連の流れ、論理的な流れが飛躍しないように注意すること。
  • 「動作検証」と「動作確認」の違いをはっきりさせること。違いは皆さんで考えてください。

注意事項

H1の実験の目的と報告書との関係

今回の実験の目的は次の通りである。

  1. 組み合わせ回路、順序回路の設計を実践し理解を深める
  2. 特に論理の最適化・最小化について実践し理解を深める
  3. 開発ツールについて学習する（設計から実機動作までの一連の工程を各自が確認・習得する）
  4. 実験ボードとのつなぎを体験し理解する
  5. 実験レポートを各自が執筆し、報告書の構成、書き方、重要な要素について理解を深める
  • 今回の設計する回路は正論理で設計すること。
    正論理は１に意味をもたせた回路であり、水位計の入力１がはいってきたらそこまで水が達しているという解釈である。また７セグメントへの出力も正論理であれば、１が出力された時にLEDが点灯することを期待しているということである。
  • 実験ボードとの論理の変換回路は別の回路図として書くこと。
    水位計や７セグメントデコーダの責任分界点は正論理の領域とするため、そのまま実験ボードに乗せても、論理の正／負が異なっていてそのまま使うことができない。水位計や７セグメントデコーダ回路をシンボル化し、その外側で論理の正負を調整する回路図を書く。こうすることで、責任分界点がはっきりとし、論理の正負が明確に成り、回路の再利用などがしやすくなる。
    ７セグメントデコーダはこれからの、表示装置として使用されるため、再利用しやすく、間違いのない回路にしておく必要がある。レポートにはそのような工夫を施しているのであれば、明記すること。

H1の実験報告書の構成について

H1の実験は大きく（１）設計しなさい、（２）回路を動かして動作を観測しなさい、（３）動作検証をしなさい、というのが実験の内容です。実験結果として提示すべきことは（１）設計をしたことと（２）観測結果を述べなければなりません。 （３）の動作検証は実験結果に基づき考察すべきことで、考察か検討事項のところで述べてあれば、実験結果（事実の提示）のところになくても良いと思います。

実験結果として提示すべきこと

実験結果として提示すべきことは次の内容ではないかと思います。

  • 曖昧な仕様から作るべき回路の厳密な仕様を記した真理値表や拡大入力要求表
  • 論理関数・論理式
  • 実験に用いた最適化された論理回路図
  • 動作確認をした観測結果

（そういう結果の提示を期待しています。）ですから、検討事項にカルノー図や式変形の過程が提示されないのでそこを補うように検討事項が示されているわけです。また、それを実験結果に記してしまうと、結果が間延びしてしまって、結果の本質がわかりにくくなるので、検討事項にする指示がされているわけです。

実験結果の提示として、観測デバイスの状態を示すだけではダメ

「何を観測しましたか」という問いに「LEDの何番」ですという回答はおかしいと思いませんか？「LEDの何番」は観測デバイスであり、直接の観測対象物ではありませんよね。「何を観測しましたか」という問いは「観測対象は何でしたか」と読み替えてみても良いでしょう。実験として観測対象は何（どの信号）であり、それをどのような観測手段・観測デバイスを使って観測したのかを示してほしい。また、実験の結果は観測デバイスの表示がどうだったかを示すのではなく、観測対象（信号）がどうだったのかを示して下さい。

例えば、表1のような表だと実験結果として何が示されているのかわかりませんよね。本文に対応があったとしても、表の体裁としてはダメダメな表ということになります。表の中で全てがわかるように記載しなければなりません。

表1. 実験結果

LEDR4 LEDR3 LEDR2 LEDR1
0 H T 点灯
1 H F 消灯
1 L T 点灯

0/1, H/L, 点灯/消灯の表記がありますが、実験結果としてふさわしい表現はどれだと思いますか？

ふさわしい表現は実験の目的／趣旨によって変わると思います。信号のON／OFFを示すのであれば、0/1やH/Lで示したほうが良いと思います。LEDの点灯／消灯の結果が実験結果として必要なのであれば、点灯／消灯で記載しなければなりませんが、そのときLEDへの電圧はHだったのかLだったのかはわかりません。論理関数の真偽を確認することが目的であればT/Fまたは真/偽で示すことがふさわしいと思います。皆さんの実験はどれを目指して実験をしていたのでしょうか？考えてみてください。実験の目的に合わせて、表記は統一されている方が良いと思います。

さらに、上記のような表があったとすると、次のような疑問が出てきます。

  • そもそも何の実験結果の表なんですか？ キャプションには適切な説明を付けましょう。
  • それぞれのLEDはどの信号を観測したものか？（本文を読んで探さなければならないのではダメでしょ？）
  • その信号は入力信号／出力信号のどちらを観測したものですか？
    「物差しは3.4cmでした」とか「テスタでは2.5Vでした」と表現しているのと同じだと思いませんか？何を測定したんでしょうか？

例えば、下記のような表にしたほうが理解しやすいと思いませんか？どうしても観測デバイス名を書きたければ記載する方法を考えれば良いと思います。この実験結果の記載において観測デバイス名は必要でしょうか？必要なら記載する、必要でないなら書かない。それらの判断は班の中で行ってください。

表2. 回路Aの動作結果

入力信号 出力信号
A B X Z
LEDR1 LEDR0 LEDG1 LEDG0
0 0 1 1
0 1 0 0
1 0 1 1
1 1 1 0

「動作検証をしなさい」というのは、何をすれば良いのかを考えてください。動作確認と動作検証は同じものではありません。また、動作の説明をすることでもありません（「意図したとおりに動いた⇒正しく動いた」ではダメですよね。なぜなら、意図した動作として設計者の誤った理解や解釈に基づいて作られたものの動作、すなわち誤った動作の説明と一致したからといって正しい設計・動作であったことの証明にはなりません）。

補足説明

なぜ観測結果から、加法標準形が得られるのかをレポートに解説すること。

今回の実験は設計・導出を理解・習得すべき知識なので、真理値表がこうだから、加法標準形はこうなる的な導出はダメ（導出の仕組みや原理が示されていないので）。真理値表と加法標準形の関係は何も説明されていない。もしそのような書き方をするのであれば、実験原理などの項目において事前に説明が必要である。

それぞれの論理変数が０か１か決まった時には、結果は０か１に一意に定まる。しかし、論理変数の０か１かが、なぜ加法標準形のような論理式の形に変形できるのか？その根拠や原理を説明してください。ヒント：シャノンの展開定理

検討事項（4）の方は、なぜLEDがつくのか、スイッチはどちらが０か等を聞いている設問ではありません。実験ではFPGAの内部しか設計図に記していないにもかかわらず、LEDやスイッチと連結される仕組みについて問うています。SWを操作してその信号がFPGA内部に連結・伝達される仕組み、入力のSWや出力のLEDを変更するにはどうすれば良いのか、なぜそうすれば、だれがそれを変更してくれるのかなど深い考察を期待しています。

今回の目的は、頭を使って論理の最適化・最小化を行うこと。最適・最小と思われる理由もレポートには記載すべきである。もっとも出してはならない理由は「理解しやすさ」である。わかり易さと論理の最小化はトレード・オフの関係にあり、一番わかり易い（デバッグしやすい）というのは、論理の最適化・最小化をしない（加法標準型）の形になるであろうことは容易に予測できる。しかし、今回の実験の目的は最適化・最小化であり、これに「わかり易さを考慮して」などの理由が混在することは最適化・最小化を諦める・放棄する理由でしかない。

中途半端に、最適化とわかり易さを混在させてはどちらも中途半端になり、どちらの用途にも利用できないことにほかならない。したがって、このような記述のレポートでは評価も下がることに注意して欲しい。

今回の実験は別の例で例えるなら、コンパイラのコード生成において、コード最適化に関する知識とスキルを習得するため、最適化の技法を駆使して、コンパクトで高速なコード生成をしなさいというお題に対して、コードの最適化に関する努力をしないで、「最適化はさておき、コードのデバッグのしやすさを目指してコード生成した」という感じ。なんだかもやもやする。理由は、お題は「コンパクトで高速なコード生成を目指したコード最適化」に対して、要求を理解せずに、別の基準を持ちだして「これでいいんだ」と主張している所だと思う。

最適化は実際、コンパイラの裏側でひっそり・こっそり行われているわけだが、絶大な効果をもたらされている。CSプログラムの学生として最適化の技法くらいは知っておいて欲しい。論理回路の最適化手法も同様である。論理最小に関する技法について、いろいろ考え、実践してみて欲しいというのが今回の実験の目的である。

レポート記載に関する注意事項

提出の前に必ず班員全員が下記のチェックリストをチェックして事前に全て修正して提出すること。自分のレポートのチェックは甘くなるので、他人のレポートをチェックして、相互チェックすると良いでしょう。

  • セグメントLEDの出力イメージ
    実験結果に「”A”のイメージを出力した」などという記述が散見されるが、「Aのイメージ」とはなんですか？文章の内容にも気を配って分かる内容を記載してください。
    7セグメントLEDのフォントの例
    https://www.keshikan.net/fonts.html
    他にも「デジタル数字 フォント」などで検索することでフォントを探すことができます。利用条件に注意して利用してください。
  • 今回の実験の７の表記について
    実験の指導書では下記の図の右側の７を示すよう指示されている。実験報告書に左側の７の表記が記載されていたとしよう。左側の７のように見えていたとしたら、指示された仕様どおりに設計されていないということを意味し、右側のように見えていたにも関わらず左側のように見えたと表記するのはミス（わかっていて放置されているのは改ざんに近い）か？さらに、信号の0/1の表記と表示が一致していないのは、誰がみてもわかるミスであり、放置していて良いだろうか？

君たちが使った７はどっちだったか？

フォントによって、７の数字がどちらで表現されているかは異なる。対応しているフォントを使うか、別の文字に割り当てられている同じ形のフォントを使うこと。７以外の数字・文字についても同様。

受理できないレポートの条件

例年のレポートを受理できない基準は以下の５点です。

（１）実験の内容が指導書に記載されている内容と異なるもの

  • 実験の趣旨を取り違えていたりして、実験指導書に指示された仕様を満たしていない実験データが記載されているもの
    例えば、H1の実験では、７セグメントデコーダ回路において指示された表示と異なる表示をするよう設計されているような例が該当する。その他、「論理の最適化」が課題になっている課題に対して、「読みやすさ」「改変のしやすさ」として「論理の最適化」を実施していない実験結果などが該当すると思われる。
  • 実験指導書とは異なる実験方法にて実験を行って得られたデータが記載されているものや実験データが足りないもの
    例えば、「入力の電圧の振幅を計測しなさい」という指示があるのに実験結果として「入力電圧の振幅」が計測されていないものなどが該当する。

（２）実験レポート中に矛盾・不一致があるもの

  • 実験方法に記載された「こうする」と実験データに記載される「こうした」が一致しないもの
    例えば、設計した論理と実験に使用した回路の論理が異なるものなどが該当する。実験では、設計し、実装し、動作を観測する、ことがセットになっているはずで、設計したものと、実装したものと、観測データがそれぞれ異なったものになっているような場合、実験の意図がわからなくなる。
  • レポート本文と図や表の内容に食い違いがあるもの
    例えば、グラフでは上昇を示しているにもかかわらず、レポート本文では「下降している」というような記述になっているもの。データは明らかに異常を示しているにもかかわらず、レポート本文では「正常に動作した」というような記述になっているもの。このようなレポートは悪質なものだとレポート本文を輸入して、データだけ差し替えて、本文を吟味せずに提出していることが疑われる。このようなことがないように厳しくチェックする。

（３）実験結果・実験データにミスがあるもの

  • 実験結果や実験データに明らかに誤りだと思われるデータが存在するもの
    このような場合には実験データの記録の提出を求めることがある。実験データと照合して部分的な転記のミスが確認できるのであれば受理するが、実験ノートとの照合ができない場合については実験レポートを受け取ることができない（ことがある）。

（４）実験レポートのデータの改竄・コピーが行われているもの

  • タイトル通り改竄やレポートのコピーが行われているもの
    班の内外のレポートだけでなく過去のレポートからコピペが行われている場合（コピーや改竄の決定的な確証がある場合）には受領しない。実験からやり直して来ること。バレなきゃラッキ－と思わないでほしい。悪質な改竄やコビーが見つかった場合には、レポートの「強制受領」（受領したこととする）とし、評価はそれレポートはO点とする厳しい対処をすることがある。Microsoft wordなどを使って、報告書を書く訓練なのでコピーなどをせずに個人でレポートが作成できるよう修行を積んで、卒業論文・修士論文を書く際にそのスキルを生かしてほしい。

（５）実験レポートの体裁が整っていないもの

  • チェックリストをチェックしていない、レポートの体裁が整っていないもの
    最低限…以下の３点は守ってください。チェックしてチェック漏れがあるのはミスとして認めますが、あまりに杜撰なチェック（チェックしようとしていない）であれば受領できません。

    • 章節の番号付けやタイトル付けが適切にできていないもの
    • 図表番号やキャプション（図表の説明）がついていないもの
    • 本文から図表の参照のないもの
      チェックリストをチェックしようとしていないものについては論外だと思いますが…いかがでしょうか？

レポート（報告書）のチェックシート

実験レポートは、以下の項目を含む必要がある。皆さんは下の例のように 1.〜, 2.〜 …と書いてください。また、必要に応じて2.1 ◎◎,2.2 ××のように節を設けて記載してください。

1. 実験の目的
2. 実験原理
    2.1 実験方法
    2.2 実験装置及び実験機器
3. 実験結果
4. 実験結果の検討・考察
5. 参考文献

共通項目

チェックリストのフォームへ

  • □ 章や節の構成を意識して、文章を構成する。
  • □ 段落を意識して文章を構成すること。１文が１段落のような文章は良くない。
  • □ 段落のはじめは１文字字下げする （Wordでは空白を入れなくてもスタイルで調整することができる）。
  • □ コピーを使用していないこと。回路図を書く練習を目的にしているので、 指導書等の図のイメージを取り込んで張り付けるのもダメ。
  • □ 実験結果を一目で理解できるように観測データを整理し実験した証として提示する。
  • □ 観測データを見やすいように、表やグラフとして提示する。
  • □ 図表には全体の通し番号と説明文(キャプション)を付ける（図２ ｘｘｘｘ，表１ ～～～ のように）。
  • □ キャプション（図のタイトル・説明文）は、図の場合は図の下側、表の場合は表の上側に付ける。
  • □ 図表は必ず本文から参照し、本文では簡単な説明を書く。「～の実験結果を図●に示す。図●は～」のように本文から参照すること。
  • □ 一つの図表はページをまたがらないように配置する。
  • □ 論理回路図の書き方に従い、定められた記号を用いて正しい回路図を記載する。
  • □ 論理式も標準的な書き方/記法に従い正しい論理式を記載する。
  • □ 用紙の周囲に1インチ(2.5cm)程度の余白を設ける。
  • □ 作成した回路の回路図にはピン番号やIC番号が正確に記されているか?
  • □ 使用した論理素子や測定機器等の実験装置は正確に記載されているか?
  • □ 実験データは入力・出力が正しく分かりやすく示されていること。