オンラインツールでの演習支援環境を用意しています．リモートワーク力を高めましょう．
- Webページ：資料やFAQの掲載．つまり本ページ．
- Slack：チャットベースでの質問対応や技術指導
- 実験実施時間中はSlackにスタッフが常駐しています．計算機科学コースWSの #実験3hw のチャンネルで気軽に質問を投げてください．学生さん同士で助け合うこともありえるでしょう．
- 実験時間外にもなるべく適宜で対応します．教員・TAに先取りして答えて助け合いするのも大歓迎です．
- #実験3hw_random も作りました．進捗や情報を交換し合ったり単に雑談するのに使うのもよいでしょう．
- SlackのコースWSおよび実験3HWチャンネルの登録方法が分からない場合はスタッフにメールを投げてください．
- 教員やTAにDMで個別に質問をすることは避けてください．自分のお困りごとと解決策は次の誰かにとっても役立つので，どんどん共有していきましょう．どうしても恥ずかしければスタッフにグループDMまたはメールで対応します．個別のDMには対応しません．
- 当面は無料プランで運用しています．直近のメッセージへのアクセス件数，1対1で音声通話のみ（画面共有は不可）の制約があります．用法用量を守って賢く使い分けていきましょう．
- GitHub Classroom：
- レポート課題の提出に使用します．
- もちろん，設計データの日々の差分管理にも有効活用してください．
本実験では，FPGAと呼ばれるプログラマブルなLSIを用いて，
マイクロコンピュータを作成します．
マイクロコンピュータは，PowerMedusaボードを使用して作成します．
また，論理設計には論理CADツールQuartus Prime 20.1を使用します．
PowerMedusaボード上のFPGAをプロセッサとしてプログラムすることによって，
ボード全体を1つのマイクロコンピュータとして動作させることができるわけです．
実装するプロセッサのアーキテクチャは，SIMPLEアーキテクチャに準拠するものとします．本実験では，このプロセッサの方式設計から論理設計までを行います．
実験の達成目標は，与えられた仕様と方針に沿って設計するだけではなく，独自の改良や拡張を施すことです．また，プロセッサアーキテクチャに関する種々の拡張方式や最適化技術がもたらす有効性などを定量的に評価し，これを考察します．
レポートは計３回提出してもらいます．7SEG LED駆動回路とカウンタの設計の導入課題，プロセッサ設計演習の中間報告と最終報告です．最終報告ではデモンストレーションとセールストークも課します．
実験は少人数のグループ制で行います．グループ内での設計データの共有とバージョン管理にはGitを用います．
レポート課題の設計データの提出にはGitHub Classroomを利用します．デバッグ相談の際にも活用します．
最後に，最終デモにて完成したマイクロコンピュータ上で，なんらかの応用プログラムを実際に動作させます．
ソート速度コンテストを開催していて，作成したプロセッサの性能を競います．任意ですが是非参加して下さい．
- 2024/4/5
- 2023/4/13
- Gitの使い方にGitHubのリポジトリにsshでアクセスする方法を追記
- よくある質問に演習室のPCからSSHで学外(GitHub等)に接続する方法を追加
- 2023/4/10
- 2022/4/14
- 導入課題でMU500-RK上の7SEG LEDを使う (ただし2022年度に限りMU500-7SEG上の7SEG LEDも認める) ことを追記
- 導入課題の課題2で「1クロックで1ずつカウントアップする回路」を「一定の間隔で1ずつカウントアップする回路」に修正
- 2022/4/8
- ボードの各モジュール動作を確認するためのSOFファイルのリンク先を修正
過去の更新履歴
以下のページ，資料をよく読んで受講してください．
レポート提出期限および進度は，目安として示しています．
おおよそ中間レポート提出時点で，なんらかの命令が動作するレベルのものが設計できており，SIMPLEの基本的な仕様と方針に沿ったプロセッサがだいたい出来ていることが望ましいです．
| 実験日 | 常駐TA | イベント | 進度の目安
|
|---|
| 4/11(木)午後 | 松本 | 導入講義1
(CAD, HDL)
| CAD・HDLの習熟を兼ねた導入課題の実施
方式設計，機能設計
作業分担の決定，設計期間のスケジューリング
|
| 4/12(金)午前 | 斎藤・赤川 |
|
| 4/12(金)午後 | 浦川・迫田 |
|
| 4/18(木)午後 | 松本・上田・迫田 | 導入講義2
(SIMPLE)
| 各機能ブロックの論理設計
|
| 4/19(金)午前 | 斎藤・赤川・浦川 | 導入レポート
|
| 4/19(金)午後 | 浦川・迫田 |
|
| 4/25(木)午後 | 松本・上田・迫田 |
| プロセッサ全体の論理設計，デバッグ
|
| 4/26(金)午前 | 斎藤・赤川・浦川 |
|
| 4/26(金)午後 | 浦川・迫田 |
|
| 5/9(木)午後 | 松本・上田・迫田 | | 中間デモの準備（命令の実行，表示方法の検討）
＋拡張したアーキテクチャの機能設計
|
| 5/10(金)午前 | 斎藤・赤川・浦川 |
|
| 5/10(金)午後 | 浦川・迫田 | 中間デモ
中間レポート
|
| 5/16(木)午後 | 松本・上田・迫田 | | 拡張したアーキテクチャの論理設計，デバッグ
|
| 5/17(金)午前 | 斎藤・赤川・浦川 |
|
| 5/17(金)午後 | 浦川・迫田 |
| 応用プログラムの作成，デバッグ
|
| 5/23(木)午後 | 松本・上田・迫田 |
|
| 5/24(金)午前 | 斎藤・赤川・浦川 |
|
| 5/24(金)午後 | 浦川・迫田 |
| 最終デモの準備（応用プログラムの作成）
＋デバッグ，性能評価
|
| 5/30(木)午後 | 松本・上田・迫田 |
|
| 5/31(金)午前 | 斎藤・赤川・浦川 |
|
| 5/31(金)午後 | 浦川・迫田 | 最終デモ
|
| 6/7(金) | | 最終レポート
|
|
- E-mail連絡先（担当者全員に配信）：le3hw@kuis.kyoto-u.ac.jp
- デバッグ相談：
- 時間内は対面/Slack，時間外はSlackで受け付けます．恥ずかしい場合はメールでも構いません．
- お困りの設計データをGitHubにbranch切って共有すると捗りやすいです．また，どのようにお困りなのかちゃんと伝わるように説明も加えてください．(Issue運用もありかもしれません，お互いにやりやすい方法で進めていきましょう)
教員
| | 役職 | 居室 | 内線 | GitHub |
|---|
| 川原 純
| 准教授 | 総合研究7号館230号室 | 5382
| junkawahara
|
| 安戸 僚汰
| 助教 | 総合研究7号館335号室 | 5383
| r-ricdeau
|
| 下西 慶
| 助教 | 総合研究5号館306号室 | 7480
| smnimo
|
| 加藤 和成
| 技術職員 | 総合研究7号館335号室 | 5397
| kazunarikato
|
TA
| | 学年 | 所属 | GitHub | コアタイム |
|---|
| 松本 直樹 |
D2 |
岡部研 |
naoki9911 |
木午後 |
| 齊藤 一希 |
M2 |
湊研 |
ceblab |
金午前 |
| 赤川 雄紀 |
M2 |
湊研 |
YukiAkagawa23 |
金午前 |
| 浦川 樹 |
M2 |
湊研 |
itscreek |
金午前・金午後 |
| 上田 結大 |
M1 |
湊研 |
ueffy |
木午後 |
| 迫田 祥司 |
M1 |
岩下研 |
nzqatd |
木午後・金午後 |
レポート課題／デモンストレーションは，導入課題，中間報告，最終報告の3回ある．
導入課題はレポートのみ，中間報告と最終報告は，レポートの提出とデモンストレーションからなる．
それぞれの提出期限は目安として示している．間に合わなくても十分にサポートするので，自身の演習環境とペースに合わせて進めていくと良い（ただし，レポートを書くのは面倒だから後回しにして，先に実装を進めてしまおうというのは良くない）．
レポートおよび設計データは，GitHub Classroomによって提出する．
初期設定についてはPandAお知らせ「HW：GitHub Classroomの登録方法」を参照のこと．
GitとGitHubを初めて使う方は，下記資料を一読されたい．概要および基本的な使い方について解説している．
Gitの使い方
なお，GitHubのリポジトリをpublicにすることやCollaboratorを追加すること等（つまり作成した設計データやレポート文書を他者に公開すること）は，カンニング等の不正防止の観点から固く禁ずる．
- 内容・レポート：
-
個人単位で7SEG LED駆動回路およびカウンタの設計を行い，その内容をレポートで提出する．
試験の答案ではなく実験レポートであることに注意すること．
- 提出期限：
- 4/19(金) 13:15
- 提出方法：
- GitHub Classroomの 2024-intro-<アカウント名> のリモートリポジトリに，下記の提出内容に示すレポートと設計データを配置して，submitというタグ名(Tag version)のリリースを作成して提出する．
リリースの作成をもって提出されたと見なされる．
再提出したい場合は submit-1 などの接尾番号を付けて改めてリリースを作成すること．
- 提出内容：
- リモートリポジトリのトップディレクトリに intro.pdf のファイル名でレポート文書（形式はPDFのみ）を配置する．
文書には表紙を付けること．表紙には，文書名，学籍番号と氏名，提出日などを記す．
- 設計データも本リポジトリに含めて上げること．
- 導入課題の終了後，本題のプロセッサ設計演習に入る．
- SIMPLE アーキテクチャをベースとして，各グループで独自のプロセッサを開発する．
- プロセッサを機能コンポーネントに分割し，グループのメンバーで設計を分担する．
- GitHub Classroomの 2024-simple-team<チーム番号> のリモートリポジトリにおいて，各自の設計とレポート作成を進めていく．本リポジトリのリリースがレポートと設計データの提出先となる．
- 中間レポートの時点で，最終的に設計するプロセッサの仕様を確定し文書化する．
- 中間デモでは，FPGAボード上でプロセッサの部分的な動作を実証する．
- 最終デモ，最終レポートでは，完成したプロセッサ上でアプリケーションプログラムを動作させ，また，プロセッサを利用するうえで必要となる文書を作成する．
- デモンストレーション [プロトタイプの動作実証]
- 日時： 5/10(金) 13:15-16:30
- PowerMedusaボード上に設計したプロセッサをダウンロードしたうえ，何らかの命令が動作していることを示す．
示し方は各自で工夫すること．
- レポート [最終的に設計するプロセッサの仕様]
- 提出期限：5/10(金) 18:15
- 提出方法：GitHub Classroomの 2024-simple-team<チーム番号> のリモートリポジトリに，middleというタグ名(Tag version)のリリースを作成して提出する．
リリースの作成をもって提出されたと見なす．再提出したい場合は middle-1 などの接尾番号を付けて改めてリリースを作成すること．
- 提出物：下記に示すレポートと中間報告時点の設計データ
- レポートの内容：最終的に設計するプロセッサに関して，以下の内容をまとめる．各文書には表紙を付けること．表紙には，文書名，学籍番号と氏名，提出日などを記す．
リモートリポジトリのトップに report_middle のディレクトリを作成し，ここに以下に指定する青字のファイル名で各レポート文書（形式はPDFのみ）を配置すること．
- [グループ毎に1部] アーキテクチャ検討報告書 (ファイル名：architecture_study_report.pdf)
「何を目指すか」
- 要求仕様，設計目標，設計方針，特長
- 高速化/並列処理の方式
- 拡張命令，動作周波数，パイプライン化，並列化，など
- 性能/コストの予測
- SIMPLE/Bに比べて性能やハードウェア量が何倍程度か，それは妥当な見積もりか
- ソート速度コンテストでの計算時間，サイクル数の予測，など
- 考察等
- [グループ毎に1部] 方式設計仕様書 (ファイル名：system_design_spec.pdf)
「どのように実現するか」
- [個人毎に1部] 機能設計仕様書 (ファイル名：function_design_spec-[学籍番号].pdf)
「具体的な実現方法」
- 全体をどのようにコンポーネントに分割したか (方式設計仕様書のブロック図を再掲して説明)
- 設計を担当するコンポーネントの外部仕様
- 実装を担当するコンポーネントの内部仕様
- [グループ毎に1部] 実施状況報告書 (ファイル名：status_report.pdf)
- 分担状況：プロセッサを構成する各ブロックの設計を，各グループ構成員がどのように分担していく計画か
- 最終目標に対する現在の進捗状況，今後の進捗計画
- [提出前にチェック]
- 全体
- 各レポートに表紙はありますか？
題目，グループ番号，構成員または提出者の氏名が記されていますか？
- 章，節の構成を整理してありますか？
章番号，章タイトルを付けてありますか？
- 全ての図表に図表タイトルを付け，本文から「…を図1.1 に示す．」などのように参照していますか？
- リポジトリ名とファイル名は指定されたものとなっていますか？
- アーキテクチャ検討報告書
- 各班独自の設計方針を，文章と図表で説明してありますか？
- 各班独自の改良方式とその性能予測等を説明してありますか？
- 考察等では，どう考えて上記のような仕様 (設計方針，改良方式) にしたか，他の方式との比較検討，等，何でも書いて下さい．
- 方式設計仕様書
- 誰が機能設計を行っても同等のものが設計できるよう必要十分に記述されていますか？
- 機能設計仕様書
- 全体をどのようにコンポーネントに分割したか，説明してありますか？
- 各コンポーネントの外部仕様は明確ですか？
信号線名，各信号線のビット数，外部から見た動作を記述してありますか？
- 各コンポーネントの内部仕様は明確ですか？
信号線名，各信号線のビット数，内部構造，処理方式を記述してありますか？
- 実施状況報告書
- デモンストレーション [完成したプロセッサの動作実証]
- 日時： 5/31(金) 13:15-16:30
- 製作したコンピュータの特長などについて発表(セールストーク)を行い，完成したコンピュータ上で応用プログラムを実行するデモンストレーションを行う．
-
デモはグループ構成員全員が出席した状態で行うこと．
-
各グループ構成員は，必ずデモの一部を担当すること．
- レポート [完成したプロセッサに関するドキュメント]
- 提出期限： 6/7(金) 13:15
- 提出方法：GitHub Classroomの 2024-simple-team<チーム番号> のリモートリポジトリに，finalというタグ名(Tag version)のリリースを作成して提出する．
リリースの作成をもって提出されたと見なす．再提出したい場合は final-1 などの接尾番号を付けて改めてリリースを作成すること．
- 提出物：下記に示すレポートと完成したプロセッサの設計データ (合成に必要な全てのプロジェクト・ファイルをGitHub管理下に含めること)
- レポートの内容：完成したプロセッサに関して，以下の内容をまとめる．各文書には表紙を付けること．表紙には，文書名，学籍番号と氏名，提出日などを記す．
リモートリポジトリのトップに report_final のディレクトリを作成し，ここに以下に指定する青字のファイル名で各レポート文書（形式はPDFのみ）を配置すること．
- [グループ毎に1部] 最終成果物のユーザーズマニュアル (ファイル名：user_manual.pdf)
- 説明書，リファレンスマニュアル，あるいはデータブックのことを指す
- IPコア(ソフトコアプロセッサ)として提供することを想定し，プロセッサを使用するうえで必要十分な情報を記載すること
- 概要，性能と特長，命令セットアーキテクチャ，構造と動作，など
- (SIMPLE/Bを参照せず) これだけで完結した資料とすること
- [グループ毎に1部] アーキテクチャ拡張仕様書 (ファイル名：extended_spec.pdf)
- SIMPLE/B基本アーキテクチャからの拡張仕様の説明
- どのような拡張を行ったか
- 本文書のみで拡張した仕様や機能が分かるように説明する
- その拡張を行うとどのように嬉しいかを説明
- どのようなことが新たにできるようになるか？(サンプルコード等を交えて説明するのもよい)
- [グループ毎に1部] 性能評価報告書 (ファイル名：evaluation_report.pdf)
- それぞれの性能指標について，本演習の最終成果物のプロセッサを評価して報告する．実現した拡張仕様によって各指標がどう変わったか(どのくらい改善されたか)についても報告する．
- 回路面積：ゲート数(LUT数，全体／コンポーネント毎)
- クロック周波数(実動作／CADでの予測値)，クリティカルパス
- 応用プログラムの性能：プログラムの命令数／実行命令数／実行サイクル数
- 評価結果に対して考察を与える．中間報告時点でのアーキテクチャ検討について設定した設計目標に対する達成度合，性能やコストの予測に対する達成度合，さらなる改善指針などについて議論する．
- [個人毎に1部] 機能設計仕様書 (ファイル名：function_status-[学籍番号].pdf)
- 設計を担当したコンポーネントの機能設計仕様 (中間レポートからの追加分がある場合)
- 設計を担当したコンポーネントのうち主要なものの，単体での性能評価 (LUT数，遅延時間(CADでの予測値)，クリティカルパス，など)
- 考察および感想
- 設計全体に関する考察，ならびに，特に自分が担当した部分に関する詳細な考察を行う．
- 本実験を通して得られた知見や実験の感想などを記す．
- [グループ毎に1部] 実施報告書 (ファイル名：implementation_report.pdf)
- 中間報告時点で検討したアーキテクチャ設計の目標に対して，どこまで達成できたか．目標と計画を変更した場合は，その経緯や意図など．
- 分担状況：プロセッサを構成する各ブロックの設計を，各グループ構成員がどのように分担したか．
- 最終的な設計データのGitHub Classroom上の2024-simple-team<チーム番号> のリポジトリのタグ名を記載すること。
- [提出前にチェック] TA用最終報告チェックポイント一覧 (txt形式，UTF-8)
- 「設計データ提出時の注意点」も確認すること．◎の項目が満たされていない場合は再提出を指示することがある（特によくあるのが，タイミング制約が設定されていなかったり，タイミング違反を起こしている場合）