マイクロコントローラープログラマー向けのVerilog言語を選ぶ理由

何回か私はこの記事を書き始め、それを投げました。 彼がそれを投げたのは、私にはその話題が幾分物議を醸しているようだからです。 私が発明した自転車は、一部の人にとってとんでもない、とんでもないように見え、一般的には完全に正しいとは限りません。 しかし...

一般に、電子デバイスの開発の分野には、いわばわずかに重なり合った世界がいくつかあるように思えます。 たとえば、マイクロコントローラに基づいたデバイスの開発があり、並行して、FPGAに基づいたデバイスの開発があります。 これらの超小型回路の動作原理は根本的に異なり、原理と開発方法、使用されるプログラミングおよびデバッグ言語はまったく同じです。 もちろん、元素ベースの選択はタスクに大きく依存します。 ただし、これらの世界、マイクロコントローラーの世界、およびFPGAの世界がほとんど重複しないことは既に明らかです。 テクノロジーの接点に何かあるのでしょうか？

一般的に、私自身はFPGAを好み、FPGAブログにも参加していますが、最近、当社はSTM32マイクロコントローラーに基づいたデバイスの開発を始めました。 実際、私たちが出会った主な問題は完全に技術的なものではなく、組織的なものでした。

事実、デバイスの開発に関する契約が締結されているにもかかわらず、デバイスの技術仕様が多少調整されているにもかかわらず、顧客が毎週新しいアイデア、要件、考え、希望を思いついたことがあります。 もちろん、私たちは彼らを地獄に送ることはできましたが、私たちは我慢して、プロジェクトを実行することに決めました。

主な組織上の問題-コントローラー制御アルゴリズムを変更するための要求が多くあり、それらはしばしば非常に矛盾していました。 さらに、顧客自身がそれがどのように機能するかが分からず、どのようにすべてをチェックするかも理解していませんでした。 そう言う方が正確です。 ユニットに特定のコントローラーを持ちたいマネージャーがいます。 コントローラーとユニットに必要な特定の機能、マネージャー自身は正確に知らず、要件はデバイスの操作性をチェックすることになっている1人のエンジニアが策定しなければなりませんでした。 電子デバイスの経験がないため、エンジニアにはコントローラの操作性を確認する独自の方法がありません。

以下に例を示します。 スタンバイモードでは、コントローラーが単に[スタート]ボタンが押されるのを待つ場合、コントローラーは1日に1回、10秒間液体をポンピングするポンプをオンにする必要があります。 これは、ポンプ腺の腐食に対する一種の保護です。 私が尋ねるとき; 「この機能をどのようにチェックしますか」-彼らは「ノーウェイ」と答えます。 個人的に、私はショックを受けています。 もちろん、「エラーなしで」プログラムを作成しようとしますが、受信側は何らかの形で責任を共有し、テストを実施する必要があると思います。

次に、問題の技術面に進みます。

何らかの種類のマイクロコントローラーソフトウェアテストが必要であると判断しました。

通常、ソフトウェアの世界では、単体テストという概念があります。 そして原則として、この手法はマイクロコントローラープログラムにある程度適しています。 現在、マイクロコントローラー用のプログラムは通常のC言語で書かれていることが多いため、単体テスト全般に問題はないはずです。 しかし...すべてがマイクロコントローラーの単体テストで簡単にチェックできるわけではありません。

タイマー、DMAチャネル、シリアルポート、割り込みなど、内部ハードウェアデバイスのプログラミングに関連するすべてのもの-これには問題があります。 ここで、デバッグのために、オシロスコープを使用して、入力と出力で受信されるマイクロコントローラーの信号を確認します。 一般に、割り込み処理にかかる時間を測定することは不要なタスクではありません。 そして、そうです。

単体テストにはもう1つ微妙な違いがあります。 ソフトウェアの従来の単体テストはデータ指向であるように思えます。 つまり、通常、単体テストプログラムは、チェック対象の関数の入力にさまざまな予想データを配信し、処理された出力データが要件を満たしているかどうかをチェックします。 それだけです

入力信号プロセッサとして機能する電子デバイスの場合、「時間の流れ」の概念は基本的に重要です。 つまり、通常、要件は次のとおりです。緊急事態が発生し、アラームセンサーAがトリガーされた場合、アクチュエーターB 、 CをN1秒間隔で順番にオフにし、 N2秒以内でN3秒以内にDデバイスをオフにします。

ソフトウェア制御アルゴリズムをテストするには、時間の経過を考慮して何らかの信号シミュレーターを使用するのが良いことは明らかです。 そして、そのようなツールは、FPGAシステム開発者にとっての武器です。

FPGAベースの電子デバイスの開発者は通常、VerilogまたはVHDLハードウェア記述言語を使用します。 同時に、FPGAのコードに加えて、いわゆるテストベンチが作成されます。これは、通常のCプログラマの単体テストのようなものです。

Verilog HDLを使用しています。
テストベンチプログラムはプログラマー自身が作成し、同時にFPGAチップで考えられるすべての入力効果をシミュレートしようとします。 出力信号はテストベンチ自体で分析され、予想されるものに従ってチェックされます。
同時に、Verilogシミュレーター自体がシステム内の時間の経過を監視します。

FPGAプログラマーが行うことの簡単で完全に抽象的な例を考えてみましょう。
たとえば、非同期リセット（sample.v）を使用した単純なバイナリカウンターを記述するモジュールは次のとおりです。

module sample( input wire reset, input wire clk, output reg [3:0]cnt ); always @(posedge clk or posedge reset) if(reset) cnt <= 0; else cnt <= cnt + 1; endmodule 

このようなコードは、Verilog HDL言語を知らないプログラマーでも理解できると思います。 resetとclkの 2つの入力があります。 また、出力4ビット信号[3：0] cntがあります。 常にクロック信号のエッジで、カウンタの値が増加します。 そして常に、ユニットがリセット時に表示されると、カウンターはゼロにリセットされます。

このモジュールは合成されています。つまり、コンパイルしてFPGAに縫い込む予定です。

現在、たとえば、プログラマーは自分のモジュールの機能をテストしたいと考えています。 彼は、テスト回路であるVerilogで、マイクロ回路（testbench.v）の入力信号をシミュレートするプログラムを作成します。

 `timescale 1ms / 1 ms module testbench(); reg tb_rst, tb_clk; wire [3:0]value; always #5 tb_clk = ~tb_clk; initial begin $dumpfile("waves.vcd"); $dumpvars(0,testbench); $display("starting testbench!!!!"); tb_rst = 1; tb_clk = 0; #10; tb_rst = 0; #73; tb_rst = 1; #11; tb_rst = 0; #134; tb_rst = 1; #57; tb_rst = 0; #200; $display("finished OK!"); $finish; end sample my_sample_inst( .reset(tb_rst), .clk(tb_clk), .cnt( value ) ); wire fail; assign fail = (tb_rst & value!=0 ); endmodule 

このモジュールは合成されず、コンパイルしてFPGAに縫い付けることはできませんが、プロジェクトをシミュレートするために必要です。 行に注意してください

 sample my_sample_inst( .reset(tb_rst), .clk(tb_clk), .cnt( value ) ); 

これは、テストベンチに挿入されたサンプルモジュールのテストインスタンスです。 次のようになります。



プロジェクトの効率性の基準がある可能性は非常に高いです。 リセット信号の間、カウンタ出力信号は常にゼロである必要があります。 つまり、テストベンチでエラー信号を特定できます。

 wire fail; assign fail = (tb_rst & value!=0 ); 

この信号は、プログラムで監視することも、出力タイムチャートで目で見ることもできます。

私はよくシンプルな無料のVerilogHDL IcarusVerilogシミュレーターを使用します。 インストールと操作が簡単です。 シミュレーターをコンパイルして実行します。



私のテストベンチはプログラムの行に感謝します$ dumpfile（ "waves.vcd"）; および$ dumpvars（0、テストベンチ）; wave.vcdタイミングチャートファイルを作成します。 また、これらのタイミングチャートは、別の優れた無料のGtkWaveツールで表示できます。



したがって、FPGAプログラマーができる最も単純な方法は、テストベンチをテスト済みモジュールに書き込み、結果のタイムダイアグラムのファイルを生成し、FPGAから正しい応答が返されるかどうかを調べることです。

次に、同様のテスト技術をマイクロコントローラーに適用する方法を説明します。

Verilogテストベンチに再度注意を払うと、$ディスプレイ（..）などのシステム機能がいくつかあります。

だからここに。 Verilog HDLシミュレーターでは、必要なシステム関数をC言語で自分で追加できることがわかりました。 そして、C言語の場所があると、テストベンチのVerilogコードがマイクロコントローラーのSyshコードと対話できる場所が表示されます。

一般に、C言語へのVerilogシミュレータインターフェイスは、Verilog手続き型インターフェイス（VPI）と呼ばれます。 あなたは彼について長い間話すことができます、これは大きな別のトピックです。 詳細については、たとえばこちらをご覧ください 。

これがどのように使用されるかを模式的に説明したいだけです。
マイクロコントローラのプロジェクトは、多くのファイルで構成できます。 私たちのタスクは、特定のマイクロコントローラーのハードウェア機能から制御アルゴリズム自体を分離することです。

マイクロコントローラーのプロジェクトがファイルで構成されていると仮定します。

 Main.c Dma.c Serial.c Interrupts.c …. Algorithm.c 

マイクロコントローラー入力ラインからの割り込みハンドラーは、Interrupts.cファイルに記述されています。 これらは次のようなものです。

 void EXTI9_5_IRQHandler(void) { Int val; disableGlobalInterrupts(); EXTI_ClearITPendingBit(EXTI_Line6); val = GPIO_ReadInputDataBit(MY_PORT, MY_SIGNAL); Algo_set_value( val ); enableGlobalInterrupts(); } 

マイクロコントローラーの入力ライン上の信号が変化すると、割り込みが発生し、ライン上の値を読み取り、この値がAlgo_set_val（）関数によって処理アルゴリズムに送信されます。 制御アルゴリズム全体は、Algorithm.cファイルに記述されています。

Algorithm.cファイルは、マイクロコントローラーのプロジェクトとVerilog VPIモジュールのプロジェクトに同時に関与しています。



したがって、「制御アルゴリズム」を開発する場合、主にVerilogシミュレータ用のAlgorithm.cとともにVPIモジュールをコンパイルします。 Verilogテストベンチで特定の新しいシステム関数$ int（）を呼び出すことにより、ある時点でのマイクロコントローラー割り込みの発生をシミュレートします。 同様に、アルゴリズムの内部変数を読み取り、Verilogテストベンチに渡すことができます。これには、新しい$ getpin（..）システム関数を使用します。 Verilogテストベンチは、マイクロコントローラー制御アルゴリズムの入力の影響と時間の流れをシミュレートできることがわかりました。

入力効果と応答のタイムチャートを自由に使用できることは注目に値します。 それらは、慣れるために顧客に見せることができます-GtkWaveプログラムはそれらを表示するために使用されます。 顧客は、さまざまなセンサーからの入力の影響が自分の制御アルゴリズムでどのように応答するかを自分の目で見ることができます。 顧客は、入力信号からの影響の考えられるすべての組み合わせと、マイクロコントローラーと呼ばれる「ブラックボックス」のすべての応答を確認する必要があります。

少なくとも時間図では、毎日10秒間ポンプが事実上どのようにオンになるかを見ることができます...

最後のステップは、VerilogシミュレーターのVPIモジュールのコンパイルを停止し（紫色のブロック）、マイクロコントローラープロジェクトのコンパイルを開始します（オレンジ色のブロック）。

これで、アルゴリズムの機能は、Verilogシミュレータの仮想効果からではなく、入力ラインとタイマーからの物理的な中断から呼び出されます。

念のため、Verilogテストベンチを使用しても、DMAやタイマー、GPIOなどの周辺機器のレジスターのプログラミングの正確性を確認しないことを改めて確認します。 「制御アルゴリズム」のみをテストします。 私の意見では、これは非常に重要です。

まあ、そのようなもの。