こんにちは。

大学時代の履修登録の段階で C 言語を除外した 無知無知くん です。

これまで色々と学びながら 製作実習の ステップ 3. ソフトウェア設計までやってきました。

 

 

今回は いよいよ最終章!

ステップ 2 で設計した回路を、今度は インテル® の Nios® II ソフトコア・プロセッサーを用いて "ソフトウェア言語" で設計します。

さて、再現なるか?

※ 第一段<仕様書・基板作成編>第二段<ハードウェア設計編> も併せてご覧ください。

目次

ハードウェアデザインに Nios® II を組み込む

C 言語で設計

Nios® II のブートプログラムをコンフィグレーションデータに入れる

知らなくてヤバかったこと

こうしときゃぁ良かったなポイント

終わりに

ハードウェアデザインに Nios® II を組み込む

C 言語で書いたプログラムを FPGA で実行するためには、Nios® II ソフトコア・プロセッサー (以下 Nios® II) を組み込みます。

※ Nios® II に関する情報は、こちらのコンテンツをご覧ください。

 

Quartus® Prime から Platform Designer を起動し、Nios II プロセッサーと 必要なモジュール、PIO などのペリフェラルを構築しました。

ハードウエアデザインのイメージ
Platform Designer (一部)

目次へ戻る

C 言語で設計

1万 μs ごとに flag を +1
100万 μs (1s) になると、次のループへ

Verilog HDL (ハードウエア言語) で設計した動作と 全く同じ動きを、Nios® II に再現させるための C 言語を設計します。

そこで 無知無知くんは、今までの技術研修で使用した資料を漁りまくりました。

 

そして、usleep() 関数を使えば 簡単に時計が作れそうだとわかりました。

 

while 文と usleep() 関数を使い、1秒を作りました。

Verilog HDL ではクロックをベースに作りましたが、C 言語では 1秒、1μ秒 単位で動作を停止することができる関数があるとは、こりゃ便利~!

 

これを 23:59:59 まで続け、1秒後には 0:00:00 に戻るという仕組みにしました。

目次へ戻る

Nios® II のブートプログラムをコンフィグレーションデータに入れる

Quartus® Prime の Nios® II Software Build Tools for Eclipse (以下 Nios® II SBT) の Run Configuration 機能を使用し、

作成した C プログラムを Nios® II に実行させ、完成したつもりでいた無知無知くん。

ここで先輩が一言。

 

「あ、そうそう。

Nios® II のブートプログラムは、FPGA のオンチップメモリーに入れておいてさー、

んで、FPGA の起動時に Nios® II が実行できるようにしておいてね。」

 

この後 自分がやっていた作業は "単なるデバッグ" だったことを知りました。

つまり、ハードウェアを FPGA に書き込んだ後に 一時的にオンチップ・メモリーに Nios® II のプログラムを転送し、

初期動作の確認をしていただけだったのです。

さらに 先輩はこう続け 去って行きました。

 

「あ、それ Web 記事に出てるからね~」

 

おぉ、助け舟!

早速 先輩が教えてくれた記事を検索し インテル FPGA の Nios II で はじめての L チカ! Part 2 を参考に。

結果、FPGA に電源を供給するだけで Nios II が無知無知くんの書いたプログラムを実行してくれ、拡張基板上の 7セグメント LED やドットマトリクス LED を動作させることができるようになりました☆

これで、"いちいち ハードウェアのプログラムを書いた後に ソフトウェアのプログラムをダウンロードする" 手間が省けました。

(確かに、いちいちそんなことをしなきゃいけないんじゃ 製品にならないもんね、と納得。)

目次へ戻る

 

そんなこんなで、ステップ 3 の課題を終えました。

振り返ってみると...

知らなくてヤバかったこと

知らヤバ 1. ハードウェアへの Nios® II の組み込み方

Nios® II が実行するプログラムの内容は正しいはずなのに、Nios® II SBT 上でデバッグしても "反応が何もない" という事態が発生。

コードの内容をシンプルに変更しても 変化が見られず、無知無知くん プチパニーーーック!!

 

要因は、単なる 無知無知くんの操作ミス。

Platform Designer で作成した Nios® II システム・デザインと、Verikog HDL に組み込んがシステムのモジュール名が "一致していない" からでした。

通常は、このような不一致は Quartus® Prime のコンパイルでエラーになります。

今回は、「サンプルデザインを参考に、そこから応用するぞ!」という意気込んでいたため、

完成されたサンプルのプロジェクトをそのまま流用し 編集しながら構築したせいで、このような事態になってしまいました。

しかも、Nios® II SBT で作成するソフトウェアプロジェクトは、Verilog HDL に組み込まなかった無知無知くん製の .sopcinfo で作成していたため、Quartus® Prime の使い方があやふやな状況も相まって、余計に原因究明に時間を費やしてしまいました。

サンプルのプロジェクトをそのまま使わずに、"参考に見るだけ" にすれば良かったです。

 

また、ハードウェア・デザインとソフトウェアの一致性は、System ID Peripheral Intel FPGA IP を使用することで、解消できたそうです。

(System ID Peripheral Intel FPGA IP の概要は、こちらをご覧ください。)

 

あとで先輩に教わりました。

先輩…、早く知りたかったっす。

知らヤバ 2. Verilog HDL と C 言語 の処理の違い

逐次処理と並列処理 のブログを書いた ぽき 先輩とは逆に、Verilog HDL に慣れてきて並列処理の感覚がわかり始めた無知無知くん。

Verilog HDL のノンブロッキング代入だと並列処理なので、順番をあまり気にせずに記述できることと比べ、

C 言語は逐次処理なので、{ } の中でループ、外に出たときの動作を記述する際など、記述順序が非常に重要で、

そのルールに慣れることに 時間がかかりました。

 

例えば

ハードウェア言語で時計を設計する場合、

左下図のように <秒>の値に応じて<分>がカウントアップし、<分>の値に応じて<時>がカウントアップさせていて、

それらの動作(処理)を同時におこないます。

一方で  C 言語では、

右下図のようにひとつずつ順番に処理をおこないます。

ブツブツつぶやく無知無知くん

記述量が圧倒的に少ないのは C 言語ですが、最初はかなり戸惑いました。

「あぁ 上から順番に処理されるんだよね…そっか」って この頃は ひとり言を何度もつぶやいていた気がします。

知らヤバ 3. Interval Timer Intel FPGA IP

Interval Timer Intel FPGA IP は、

Platform Designer に用意されている Nios® II processor の HAL API Driver に対応した IP です。

(この存在を 製作実習終了後に知りました。)

 

このライブラリーには、alt_ticks_per_second()​ という関数があるみたいです。

1 秒あたりに経過するシステムクロック・ティックの数を返す関数らしく

応用することで時計が作れそうでした。

 

他にも alt_alarm_start()alt_alarm_stop() 関数を使えば

複雑な記述無しに 時計にアラーム機能まで搭載することができちゃう!(かも?)

時計を作る際には、便利そうな関数です。

  

実際の設計で使用した usleep() 関数では、

作動している間、すべての処理が指定の時間 停止するので

並行した処理をさせるコード作るのが 無知無知くんには難しく、

ドットマトリクス LED に複雑な表示をさせることを断念。

しかし、これらの関数を使えば

時計を動かしながら、ドットマトリクス LED に また違ったアニメーションを投影することも可能だったかもしれません。

悔いが残ります。

 

知らないって、損だな。 

目次へ戻る

こうしときゃぁ良かったなポイント

ソフトウェア設計 (ステップ 3) では、今までの ステップ 1ステップ 2 の反省点を肝に銘じたため、とんでもない失敗はありませんでした。

が、やはり「こうしときゃ良かった」と実感したことが、いくつかありました。

 

 作業全体の流れを把握して、やるべきことを明確化してから進めれば良かった

   各種ペリフェラルの設定を確認したり、コードにどんな関数が使えそうか、などのリサーチ不足でした

 

 事前に感覚をつかめるコンテンツ (演習問題など) があるのだから、先に試せば良かった

   あれれ?このセリフ、ステップ 2 でも言ったような…

 

IP のパラメーター設定や Nios® II 開発の環境構築は、ステップ 2 の作業中に慎重におこなうことが大切だと理解していましたが、
ここ ステップ 3 でも 改めて学びました。

空中配線による不具合発生!

★ 写真をクリックすると
動画が再生されます

製作実習発表会の数日前、

プッシュボタンや その周辺に軽く手で触れるだけで 7セグメント LEDが反応してしまう事態が発生!

これは 空中配線 が要因です。はい。

 

基板の角度やボタンの触り方によっては 正常に動作するので、

とてつもなく不安定な配線でした。

 

「発表会までは 生きててくれよ!」と、無知無知くんの祈りが通じたのか 何とか発表はできましたが

もし来年の新入社員くんに「先輩の拡張基板、動作させてるの見せてください」とか言われると

その時に基板が生きているか自信がありません。ごめんなさい!

 

目次へ戻る

終わりに

製作実習の社内発表会も無事に終わり、無知無知くんも ほっと一息。

この実習で培ったことが、今の OJT に役立っています。

実習中はワケモワカラズでしたが、今思うと 無駄な苦労はない!

 

 

製作実習前 先輩に質問したことがありました。

「仕事をマルチタスクでこなすには、どうしたらいいですか?」

 

「マルチタスクなんて実は無い。同時にこなしているように見えて 同時じゃない

1個ずつに集中して取り組んだり、隙間時間を利用したり。細かいスケジュール管理のおかげで そう見えているだけなんだ」

と先輩。

おっしゃるとおりです!

 

そのことを今ふと思い出し、

なんだか、ダイナミック点灯みたいだな、と思ったと同時に

"マルチタスク" という言葉の響きだけで、ざっくりな質問をしてしまった過去の自分の甘さを恥じました。

以上で、2022年度 新卒社員 無知無知くんの奮闘記 は完結です。

気づけば、あと数か月で後輩が入社してくるんですね。

 

頼られる 無知無知パイセン になれるよう、これからも頑張ります!

 

目次へ戻る