最新のCPU（ARMなど）を使用したサイクルカウント

多くのアプリケーションでは、命令実行が予想される入力刺激と既知のタイミング関係にあるCPUは、関係が不明である場合にはるかに高速なCPUを必要とするタスクを処理できます。たとえば、PSOCを使用してビデオを生成したプロジェクトでは、コードを使用して16 CPUクロックごとに1バイトのビデオデータを出力しました。SPIデバイスの準備ができており、分岐していない場合、IIRCは13クロックかかり、出力データへのロードとストアには11時間がかかるため、バイト間のデバイスの準備をテストする方法はありませんでした。代わりに、最初のバイトの後、各バイトに対して正確に16サイクルのコードをプロセッサに実行させるように単純に調整しました（実際のインデックス付きロード、ダミーインデックス付きロード、およびストアを使用したと思います）。ビデオの開始前に各行の最初のSPI書き込みが行われたため、後続の書き込みごとに、バッファオーバーランまたはアンダーランなしで書き込みが発生する可能性のある16サイクルのウィンドウがありました。分岐ループは不確実性の13サイクルウィンドウを生成しましたが、予測可能な16サイクルの実行により、後続のすべてのバイトの不確実性が同じ13サイクルウィンドウに収まることを意味しました（書き込みが許容できる16サイクルウィンドウ内に収まります）起こる）。

古いCPUの場合、命令のタイミング情報は明確で、利用可能で、明確でした。新しいARMの場合、タイミング情報ははるかに曖昧に見えます。コードがフラッシュから実行されている場合、キャッシュ動作により物事を予測するのがはるかに難しくなるため、サイクルカウントされたコードはすべてRAMから実行されると予想されます。ただし、RAMからコードを実行する場合でも、仕様は少しあいまいに見えます。サイクルカウントされたコードの使用はまだ良い考えですか？もしそうなら、それを確実に動作させるための最良のテクニックは何ですか？チップベンダーが、特定の場合に特定の命令の実行サイクルを削る「新しく改善された」チップを静かにすり抜けることはないと、どの程度安全に想定できますか？

次のループが単語の境界で開始すると仮定すると、仕様に基づいて正確にどれくらい時間がかかるかをどのように決定しますか？

マイループ：
  mov r0、r0; より多くの命令をプリフェッチできるようにする短い単純な命令
  mov r0、r0; より多くの命令をプリフェッチできるようにする短い単純な命令
  mov r0、r0; より多くの命令をプリフェッチできるようにする短い単純な命令
  mov r0、r0; より多くの命令をプリフェッチできるようにする短い単純な命令
  mov r0、r0; より多くの命令をプリフェッチできるようにする短い単純な命令
  mov r0、r0; より多くの命令をプリフェッチできるようにする短い単純な命令
  r2、r1、＃0x12000000を追加します。2ワード命令
  ; 異なるオペランドを使用して、以下を繰り返します
  ; キャリーが発生するまで値を追加し続けます
  itcc
  addedcc r2、r2、＃0x12000000; 2ワード命令、およびitccの追加の「ワード」
  itcc
  addedcc r2、r2、＃0x12000000; 2ワード命令、およびitccの追加の「ワード」
  itcc
  addedcc r2、r2、＃0x12000000; 2ワード命令、およびitccの追加の「ワード」
  itcc
  addedcc r2、r2、＃0x12000000; 2ワード命令、およびitccの追加の「ワード」
; ... etc、より条件付きの2ワード命令
  サブr8、r8、＃1
  bpl myloop

最初の6つの命令の実行中に、コアは6ワードをフェッチする時間があり、そのうち3ワードが実行されるため、最大3つのプリフェッチが可能です。次の命令はそれぞれ3ワードすべてであるため、コアが命令を実行中の速度でフェッチすることはできません。一部の「it」命令にはサイクルがかかると予想されますが、どの命令を予測するかはわかりません。

「it」命令のタイミングが決定的となる特定の条件をARMが指定できると便利です（たとえば、待機状態やコードバスの競合がなく、前の2つの命令が16ビットのレジスタ命令などである場合）。しかし、私はそのような仕様を見ていません。

サンプルアプリケーション

Atari 2600のドーターボードを設計して、480Pでコンポーネントビデオ出力を生成しようとしているとします。2600には、3.579MHzピクセルクロックと1.19MHz CPUクロック（ドットクロック/ 3）があります。480Pコンポーネントビデオの場合、各ラインを2回出力する必要があります。これは、7.158MHzドットクロック出力を意味します。Atariのビデオチップ（TIA）は、3ビットの輝度信号と約18nsの解像度の位相信号を使用して128色のいずれかを出力するため、出力を見るだけで正確に色を決定することは困難です。より良い方法は、カラーレジスタへの書き込みをインターセプトし、書き込まれた値を観察し、レジスタ番号に対応するTIA輝度値で各レジスタにフィードすることです。

これはすべてFPGAで実行できますが、一部の非常に高速なARMデバイスは、必要なバッファリングを処理するのに十分なRAMを備えたFPGAよりもはるかに安価である可能性があります（はい、ボリュームについてはそのようなものが生成される可能性があることを知っていますt実際の要因）。ただし、ARMが着信クロック信号を監視する必要がある場合、必要なCPU速度が大幅に向上します。予測可能なサイクルカウントにより、物事がよりきれいになります。

比較的簡単な設計アプローチは、CPLDにCPUとTIAを監視させ、13ビットRGB + sync信号を生成し、ARM DMAが1つのポートから16ビット値を取得し、適切なタイミングで別のポートに書き込むことです。ただし、安価なARMがすべてを実行できるかどうかを確認することは、興味深い設計上の課題になります。DMAは、CPUサイクルカウントへの影響を予測できる場合（特に、メモリバスがアイドル状態のサイクルでDMAサイクルが発生する可能性がある場合）にオールインワンアプローチの有用な側面になる可能性がありますが、プロセスのある時点でARMは、テーブル検索とバス監視機能を実行する必要があります。色レジスタがブランキング期間中に書き込まれる多くのビデオアーキテクチャとは異なり、Atari 2600はフレームの表示部分の間に色レジスタに頻繁に書き込むことに注意してください。

おそらく最良のアプローチは、2つのディスクリートロジックチップを使用してカラー書き込みを識別し、カラーレジスタの下位ビットを適切な値に強制し、次に2つのDMAチャネルを使用して着信CPUバスとTIA出力データをサンプリングすることです。出力データを生成する3番目のDMAチャネル。CPUは、各スキャンラインの両方のソースからのすべてのデータを自由に処理し、必要な変換を実行し、出力用にバッファリングします。「リアルタイム」で発生しなければならないアダプタの義務の唯一の側面は、COLUxxに書き込まれたデータのオーバーライドであり、2つの一般的なロジックチップを使用して処理できます。

DMAに投票します。Cortex-M3以降では非常に柔軟です。また、CPUサイクルを一切消費せずに、ある場所からデータを自動的に取得し、指定されたレートまたはイベントで別の場所に出力するなど、あらゆる種類のクレイジーなことができます。DMAははるかに信頼性があります。

しかし、詳細に理解するのはかなり難しいかもしれません。

別のオプションは、これらのタイトなもののハードウェア実装を備えたFPGA上のソフトコアです。

タイミング情報は利用できますが、指摘したように、あいまいなことがあります。たとえば、Cortex-M3 のテクニカルリファレンスマニュアルのセクション18.2と表18.1には、多くのタイミング情報があります（ここのpdf）。ここからの抜粋：

最大タイミングの条件のリストを提供します。多くの命令のタイミングは外部要因に依存しますが、その中には曖昧なものもあります。そのセクションからの次の抜粋で見つけたそれぞれのあいまいさを強調しました。

[1]分岐は、命令に1サイクルかかり、ターゲット命令のパイプラインにリロードします。行われていない分岐は合計1サイクルです。すぐに分岐する場合、通常は 1サイクルのパイプラインリロード（合計2サイクル）です。レジスタオペランドを使用して分岐した場合、通常は 2サイクルのパイプラインリロード（合計3サイクル）です。低速メモリへのアクセスに加えて、アライメントされていない32ビット命令に分岐する場合、パイプラインのリロードはより長くなります。より遅いシステム [どのくらい遅い？]をプリロードできるようにするブランチヒントがコードバスに発行されます。これにより、 [これはオプションですか？] 遅いメモリに対するブランチターゲットのペナルティを[いくらですか？] 削減できますが、ここに示されているよりも小さくなることはありません。

[2] 一般に、ロードストア命令は、最初のアクセスに2サイクル、追加のアクセスごとに1サイクルかかります。即時オフセットを持つストアは1サイクルかかります。

[3] UMULL / SMULL / UMLAL / SMLALは、ソース値のサイズに応じて早期終了を使用します [サイズは？]。これらは割り込み可能（破棄/再起動）であり、最悪の場合のレイテンシは1サイクルです。MLALバージョンが取る4〜7サイクルとMULLバージョンは取る3〜5サイクルを。MLALの場合、署名されたバージョンは、署名されていないバージョンよりも1サイクル長くなります。

[4] IT指示は折りたたむことができます。[いつ？コメントを参照してください。]

[5] DIVのタイミングは、配当と除数に依存します。[MULと同じ問題] DIVは割り込み可能（破棄/再起動）であり、最悪の場合のレイテンシは1サイクルです。配当と除数のサイズが似ている場合 [どのように似ていますか？]、除算はすぐに終了します。最小時間は、除数が被除数より大きく、除数がゼロの場合です。ゼロの除数はゼロ（フォールトではない）を返しますが、このケースをキャッチするためにデバッグトラップを使用できます。[MULに与えられた範囲は？]

[6]スリープは、命令の1サイクルに加えて、必要なだけのスリープサイクルです。WFEは、イベントが経過したときに1サイクルのみを使用します。WFIに入るときに割り込みが発生しない限り、WFIは通常1サイクル以上です。

[7] ISBは1サイクルかかります（ブランチとして機能します）。データが書き込みバッファまたはLSUで保留されていない限り、DMBとDSBは1サイクルかかります。バリア中に割り込みが入ると、中断/再開されます。

すべてのユースケースで、「この命令は1サイクル、この命令は2サイクル、これは1サイクル...」よりも複雑で、より単純で低速な古いプロセッサでカウントできます。一部のユースケースでは、あいまいさは発生しません。あいまいさが発生した場合は、次をお勧めします。

1. ベンダーに連絡して、ユースケースの指示のタイミングを尋ねてください。
2. あいまいな動作を指定するテスト
3. 特にベンダーの変更を行っている場合は、プロセッサのリビジョンを再テストします。

これらの要件はおそらく、「いいえ、直面する困難がコストに見合うものでない限り、良いアイデアではありません」というあなたの質問に対する答えになります-しかし、あなたはすでにそれを知っています。

この問題を回避する1つの方法は、Parallax PropellerやXMOSチップなど、確定的または予測可能なタイミングのデバイスを使用することです。

http://www.parallaxsemiconductor.com/multicoreconcept

http://www.xmos.com/

サイクルカウントはPropeller（アセンブリ言語を使用する必要があります）で非常にうまく機能しますが、XMOSデバイスにはXCプログラミング言語で書かれたアプリケーションで動作する非常に強力なソフトウェアユーティリティXMOS Timing Analyzerがあります。

https://www.xmos.com/download/public/XMOS-Timing-Analyzer-Whitepaper%281%29.pdf

サイクルカウントは、低レベルのマイクロコントローラーからより汎用的なコンピューティングプロセッサーに移行するにつれて、より問題が大きくなります。1つ目は通常、指示のタイミングが適切に指定されていますが、これは一部はサイトの理由によるものです。また、アーキテクチャが非常にシンプルであるため、命令時間が固定されており、わかりやすいためです。

これの良い例は、ほとんどのMicrochip PICです。10、12、16、および18シリーズには、非常によく文書化された予測可能な命令タイミングがあります。これは、これらのチップが対象としている種類の小さな制御アプリケーションで役立つ機能です。

超低コストから逃れるため、設計者がよりエキゾチックなアーキテクチャからより高い速度を得るためにより多くのチップ面積を費やすことができるようになると、予測可能性からも逃れます。この極端な例として、最新のx86バリアントをご覧ください。いくつかのレベルのキャッシュ、メモリの仮想化、先読みフェッチ、パイプライン化などがあり、命令サイクルのカウントをほぼ不可能にします。ただし、このアプリケーションでは、顧客は命令タイミングの予測可能性ではなく高速に関心があるため、問題ではありません。

この効果は、より高いマイクロチップモデルでも機能します。24ビットコア（24、30、および33シリーズ）は、レジスタバスの競合が発生するいくつかの例外を除き、ほとんど予測可能な命令タイミングを持っています。たとえば、次の命令が、前の命令で値が変更されたいくつかの間接アドレス指定モードのレジスタを使用する場合、マシンはストールを挿入する場合があります。この種のストールはdsPICでは珍しく、ほとんどの場合それを無視できますが、設計者がより高速でより高性能なプロセッサを提供しようとしているために、これらのものがどのように忍び込むかを示しています。

基本的な答えは、プロセッサを選択したときのトレードオフの一部です。小規模な制御アプリケーションの場合は、小さく、安価で、低電力で、予測可能な命令タイミングを備えたものを選択できます。より多くの処理能力が必要になると、アーキテクチャが変化するため、予測可能な命令タイミングを放棄する必要があります。幸いなことに、より多くの計算を必要とする汎用アプリケーションを使用する場合、それは問題ではないので、トレードオフは合理的にうまく機能すると思います。

はい、ARM上でも可能です。ARMでの最大の問題は、ARMがチップではなくコアを販売し、コアタイミングがわかっていることですが、チップベンダーがラップするものはベンダーごとに異なり、場合によってはチップファミリごとにベンダー内で異なります。そのため、特定のベンダーの特定のチップは、非常に確定的（たとえば、キャッシュを使用しない場合）ですが、移植が難しくなります。ここで5つのクロックと11つのクロックをタイマーで使用する場合、タイマーをサンプリングしてタイムアウトが切れたかどうかを判断するために必要な命令の数が問題となるため、問題があります。過去のプログラミング経験の音から、おそらく私と同じようにオシロスコープでデバッグすることをお勧めしますので、クロックレートでチップ上のタイトなループを試して、spiまたはi2cまたは任意の波形を見てくださいまたは、nopsを削除します。ループの回数を変更し、基本的に調整します。他のプラットフォームと同様に、割り込みを使用しないことは、命令実行の決定論的な性質に大きく役立ちます。

いいえ、それはPICほど単純ではありませんが、特に遅延/タイミングがプロセッサのクロックレートに近づいた場合でも、かなり実行可能です。多くのARMベースのベンダーでは、クロックレートを乗算して8 MHzのリファレンスから60MHzを取得できるため、4命令ごとに何かを行う代わりに2MHzのインターフェイスが必要な場合は、クロックをブーストできます（パワーバジェット）を使用し、タイマーを使用して、他の操作を実行するためのクロックを多く与えます。