設計編」の第2回目です。ブリッジを介してパソコンに繋いでみました。今回の内容は以下の通りです。使ってみるをやってみたいと思います。リンクを書いてしまいます。blog-20200130)なお、今後も少しずつ改良を重ねていきたいと思いますので、コミットのタグに御注意ください。コードを見ると、次のような冗長なカウンタ設計が気になります。{これを一つにまとめて、回路規模が小さくなるかどうか見てみましょう。カウンタ回路を一つに集約します。}続いて、状態遷移回路の各状態を次のように修正します。ログ出力を比較してみましょう。いうことで、やはり、カウンタはちゃんと集約したほうが良さそうです。アップカウンタとダウンカウンタの比較ところで、ソフト屋として(ソフト屋でなくても?)一つ気になることがあります。それは、このようなカウンタをアップカウンタとして実装するのと、ダウンカウンタとして実装するのでは、合成後の回路規模が違ったりするのでしょうか。ソフトウェアの設計の場合は、コンパイル後の命令数や所要クロック数が異なることがありますね。(ま、それほど大きな違いではないので、通常のソフトウェア設計(よほど性能がクリティカルでない場合)では、コードの可読性を優先することになると思います。設計ではどうなるのか、ちょっと試してみました。}となってますが、これを次のように変更しました。いう名前は不適切ですが、そのままにしています。出力の回路規模は全く同一でした。現実には、実装しようとしている設計や論理合成ツールで結果が異なるかも知れませんので一概には言えませんが、アップカウンタとダウンカウンタについては、どちらを使えば良いかと、それほど気にしなくても良いようです。ソフトと同様、設計の可読性を優先したほうが良さそうです。標準ライブラリを紹介しますが、そのドキュメントを見ると、アップカウンタを採用していてダウンカウンタは提供されていませんので、ただ数を数え上げるだけであれば性能は気にしなくて良さそうです。ライブラリを使ったほうが良さそうだということも言えそうです。)インスタンス化パラメタの追加タイトルが分かりづらいですが、ソフト屋の皆さんには「クラスをインスタンス化する際のパラメタ」と言えばお分かりになるかと思います。屋さんには、こんなやつのことだと言えば御理解頂けるかと思います。「インスタンス化のためのパラメタ」と呼ぶことにしましょう。