🤨 👩🏼‍🍳 👨‍👩‍👦 Reddコンプレックスに基づくUSBバスアナライザーのヘッドの作成 ⛹🏼 👩🏼‍⚕️ 🚶🏼

最後の2つの記事では、Reddコンプレックスの「ファームウェア」の例を見て、そのFPGA部分を一般的な使用のためのロジックアナライザーにしました。それから私は次のステップに進み、それをUSBバスアナライザーに変えたいと思っていました。実際、このタイプの独自のアナライザーは非常に高価であり、同じUSBが機能する理由を確認する必要があります。マシンに接続すると機能し、すべてがコネクターに接続されているときにマシンの電源を入れると機能しません。つまり、ソフトウェアアナライザーはここでは対応できません。私が書いていたとき、私はどういうわけか夢中になって、5つの記事のブロックを書きました。これで、アナライザ自体だけでなく、「ヘイスト」モードでの作成の典型的なプロセスも表示されていると言えます。この記事では、Reddだけでなく既製のブレッドボードにも基づいて、そのようなアナライザーを作成する方法を示します。Ali Expressで購入できます。

シリーズの以前の記事

おそらく、今日、私は伝統を打ち破り、Reddコンプレックスではなく、通常のレイアウトでプロジェクトをデバッグします。まず、圧倒的多数の読者はそのような複合施設にアクセスできないが、Ali Expressにはアクセスできることを知っている。それから、2つ目は、USBデバイスとホストのペアが接続された庭をフェンスで囲んだり、新たに発生する干渉に対処したりするのが面倒だからです。

2017年に、私はネットワーク上で既成のソリューションを探していて、そのような素晴らしいもの、つまりその祖先を見つけました。今では、すべてが専用のボード上にありますが、どこにもザイリンクスのシンプルなブレッドボードの写真があり、そこにWaveShareのボードが接続されていました（詳しくはこちらをご覧ください）。このボードの写真を見てみましょう。

同時に2つのUSBコネクタがあります。さらに、図はそれらが並列化されていることを示しています。 USBデバイスをタイプAソケットに接続し、ケーブルをミニUSBコネクタに接続します。これをホストに接続します。そして、OpenVizslaプロジェクトの説明は、この方法が機能すると述べています。唯一の残念なことは、プロジェクト自体が読みにくいことです。あなたはそれをgithubで取ることができますが、ページに示されているアカウントへのリンクを与えません、とにかく誰もがそれを見つけますが、それはMiGenのためにやり直されましたが、2017年に見つけたバージョン：http：// github。 com / ultraembedded / cores、クリーンなVerilog上にあり、usb_snifferブランチがあります。そこでは、すべてが直接ULPIを経由するのではなく、ULPIからUTMIへのコンバーターを経由します（これらの卑劣な単語は、高速USB 2.0チャネルをプロセッサとFPGAが理解できるバスと一致させる物理レベルの超小型回路です）。その後、このUTMIでのみ機能します。そこですべてがどのように機能するか、私は理解していません。そのため、すべてが困難ではなく恐ろしいことがすぐにわかるので、一から開発することを選択しました。

どのハードウェアで作業できますか

タイトルからの質問への答えは簡単です。FPGAと外部メモリを持っている人なら誰でもです。もちろん、このシリーズではアルテラFPGA（Intel）のみを取り上げます。ただし、ULPIマイクロ回路（そのハンカチにある）からのデータは60 MHzで実行されることに注意してください。長いワイヤーはここでは受け入れられません。 CLKラインをGCKグループからのFPGA入力に接続することも重要です。そうしないと、すべてが機能して失敗します。それを危険にさらさない方が良い。プログラムで転送することはお勧めしません。私は試した。すべてはGCKグループから脚へのワイヤーで終わりました。

今日の実験のために、私のリクエストで、友人が私にこのようなシステムをはんだ付けしました：

FPGAとSDRAMを備えたマイクロモジュール（FPGA AC608というフレーズでALI Expressでそれを探してください））およびWaveShareの同じULPIボード。これは、モジュールが売り手の1人からの写真でどのように見えるかです。ケースからネジを外すのが面倒なので、

ちなみに、私のケースの写真のように、通気孔は非常に興味深いものです。モデルで、ソリッドレイヤーを描画し、スライサーで塗りつぶし（たとえば、40％）を設定して、下と上からゼロのソリッドレイヤーを作成する必要があることを伝えます。その結果、3Dプリンター自体がこの換気を引き込みます。とても快適。

一般に、ハードウェアを見つける方法は明確です。次に、アナライザーの設計を開始します。むしろ、私たちは過去2つの記事（ここではハードウェアで作業し、ここではそれにアクセスできます）でアナライザー自体を作成しました。次に、ULPIマイクロ回路からのデータをキャッチする問題指向のヘッドを設計します。

頭ができること

ロジックアナライザーの場合、すべてが簡単でシンプルでした。データがあります。それらに接続して梱包を開始し、AVALON_STバスに送信しました。ここではすべてがより複雑です。 ULPI仕様はここにあります。退屈なテキストの93枚のシート。個人的に、これは私を落胆に駆り立てます。 WaveShareボードにインストールされているUSB3300チップの説明は、少し単純に見えます。ここから入手できます。その2017年12月以来、まだ勇気を溜めていましたが、うつ病のアプローチを感じたので、時々ドキュメントを読んですぐにそれを閉じました。

説明から、ULPIには一連のレジスタがあり、作業を開始する前に入力する必要があることが明らかです。これは主にプルアップ抵抗と終端抵抗によるものです。ポイントを説明する写真はここにあります：

役割（ホストまたはデバイス）と選択した速度に応じて、異なる抵抗を含める必要があります。しかし、私たちはホストでもデバイスでもありません！バス上のメインデバイスに干渉しないように、すべての抵抗を切断する必要があります。これは、レジスタに書き込むことによって行われます。

さて、そしてスピード。作動速度を選択する必要があります。これを行うには、レジスタに書き込む必要もあります。

すべてを構成したら、データのフェッチを開始できます。しかし、ULPIの名前では、文字「LP」は「ローピン」を意味します。そして、脚の数が非常に減ったため、このような猛烈なプロトコルが発生しました。プロトコルを詳しく見てみましょう。

ULPIプロトコル

ULPIプロトコルは、一般の人にとっては少し変わっています。しかし、ドキュメントに座って瞑想すると、多かれ少なかれ理解できる機能が現れ始めます。開発者が使用する連絡先の数を本当に減らすためにあらゆる努力をしたことが明らかになりつつあります。

ここでは完全なドキュメントを再入力することはしません。自分を最も重要なことに制限しましょう。これらの中で最も重要なのは信号の方向です。それを思い出すことは不可能

です。毎回写真を見るのが良いです。ULPILINKはFPGAです。

データ受信のタイミング図

静止時には、IDLEコマンドに対応する定数0x00をデータバスに発行する必要があります。データがUSBバスからのものである場合、交換プロトコルは次のようになります

。サイクルは、DIR信号が1に飛ぶことから始まります。まず、システムがデータバスの方向を切り替える時間があるように、1クロックサイクルあります。さらに-経済の奇跡が始まります。 NXT信号の名前を確認しますか？弊社から送信された場合は、次を意味します。そして、これは完全に異なる信号です。 DIRが1の場合、NXT C / Dを呼び出します。低レベル-チームがあります。高-データ。

つまり、常に高DIRで9ビット（DATAバスとNXT信号）を修正するか（最初のクロックをソフトウェアでフィルタリングする）、またはDIRが離陸した後、2番目のクロックから開始する必要があります。DIRラインがゼロになると、データバスを切り替えて書き込み、IDLEコマンドのブロードキャストを再開します。

データ受信で-それは明らかです。次に、レジスタを使用して作業を分析します。

ULPIレジスタへの書き込みのタイミング図

レジスターに書き込むには、次の一時的な家が使用されます（私はGOST 2.105に向かっているように感じているので、意図的に専門用語に切り替えました、そしてこれは退屈なので、それから離れます）：

まず、状態DIR = 0を待つ必要があります。クロックT0で、データバスにTXD CMD定数を設定する必要があります。どういう意味ですか？すぐにはわかりませんが、ドキュメントを少し掘り下げると、目的の値がここにあることがわかります。

つまり、上位データビットは値 "10"（バイト全体の場合、マスクは0x80）に設定され、下位ビットはレジスタ番号です。

次に、NXT信号が出るのを待つ必要があります。この信号により、マイクロ回路はそれが私たちの声を聞いたことを確認します。上の図では、クロックT2でそれを待って、次のクロック（T3）でデータを設定しました。クロックT4で、ULPIはデータを受信し、NXTを削除します。そして、STPでユニット交換サイクルの終了をマークします。また、T5では、データは内部レジスタにラッチされます。プロセスは終了しました。これは、少数の結論に対する見返りです。ただし、データの書き込みは起動時にのみ行う必要があるため、当然、開発に苦労することになりますが、これは特に作業に影響を与えるわけではありません。

ULPIレジスタからの読み取りのタイミング図

正直なところ、実際のタスクでは、レジスターの読み取りはそれほど重要ではありませんが、それも見てみましょう。読み取りは、少なくともレコードが正しく実装されていることを確認するのに役立ちます。

私たちの前には、前の2つの仮設住宅からの爆発的な混合物があることがわかります。レジスタへの書き込みと同じようにアドレスを設定し、データの読み取り規則に従ってデータを取得します。

上手？これらすべてを形作るオートマトンの設計を始めましょう。

頭の構造図

上記の説明からわかるように、ヘッドは2つのバスに同時に接続する必要があります。レジスタにアクセスするためのAVALON_MMと、RAMに格納するデータを発行するためのAVALON_STです。頭の中の主なものは脳です。したがって、これは、以前に検討したタイムダイアグラムを生成するステートマシンである必要があります。

データを受信する機能から開発を始めましょう。ここでは、ULPIバスからのフローに影響を与えることはできないことに注意してください。そこからのデータは、それが行き始めたら、行きます。 AVALON_STバスの準備ができているかどうかは関係ありません。したがって、バスが利用できないことを単に無視します。実際の分析装置では、準備ができていないデータ出力の場合にアラーム表示を追加することが可能です。記事のフレームワーク内ではすべてが単純であるべきなので、将来のためにこれを覚えておきましょう。また、ロジックアナライザーのようにバスの可用性を確保するために、外部FIFOブロックがあります。全体として、データストリームを受信するためのオートマトンの遷移グラフは次のとおりです。

DIRが離陸-受け取り始めました。 wait1で1クロックを停止し、DIRが1の間にそれを受け入れます。ゼロに落ちました-クロックの後で（それが必要であるという事実ではありませんが、今のところはwait2状態を設定します）アイドルに戻りました。

これまでのところ、すべてが簡単です。 D0_D7ラインだけでなく、NXTラインもAVALON_STバスに接続する必要があることを忘れないでください。これにより、現在送信されているもの（コマンドまたはデータ）が決定されます。

レジスタ書き込みサイクルは、予測できない実行時間を持つ可能性があります。 AVALON_MMバスの観点からは、これはあまり良くありません。したがって、少しトリッキーにします。バッファレジスタを作成しましょう。データがそこに入ると、AVALON_MMバスがすぐに解放されます。開発中のオートマトンの観点からは、have_reg入力信号（レジスタ内のデータが受信され、送信する必要があります）とreg_served出力信号（レジスタ発行プロセスが完了したことを意味します）が表示されます。オートマトンの遷移グラフのレジスタに書き込むロジックを追加します。

DIR = 1の条件を赤で強調表示して、優先度が最も高いことを明確にしました。次に、オートマトンの新しいブランチでDIR信号のゼロ値の期待値を除外することができます。異なる値でブランチにログインすることは、単に不可能です。 SET_CMDw状態は、純粋に仮想である可能性が最も高いため、青色です。これらは実行するアクションです！誰もデータバス上で、移行中に対応する定数を設定することを気にしません！とりわけ、STPw状態では、reg_served信号を1クロックサイクルの間コッキングして、AVALON_MMバスのBSY信号をクリアし、新しい書き込みサイクルを可能にすることもできます。

さて、ULPIレジスタを読み取るための分岐を追加することは残ります。ここでは、正反対です。バスサービスマシンは要求を送信し、応答を待ちます。データが受信されると、彼はそれを処理できます。そしてそれはバスの一時停止やポーリングで動作します、これらはすでにそのマシンの問題です。今日、私は調査に取り組むことにしました。データの要求-BSYが登場しました。BSYが消えた方法-読み取りデータを受信できます。全体として、グラフは次の形式を取ります。

おそらく、開発の過程で、いくつかの調整が行われますが、ここでは、このグラフを使用します。結局のところ、これはレポートではなく、開発方法論に関する説明です。また、この手法では、最初に遷移グラフを描画する必要があります。次に、この図に従って、ポップアップの詳細に合わせて調整されたロジックを実行します。

AVALON_MM側からのオートマトン実装の機能

AVALON_MMバスを使用する場合、2つの方法があります。1つ目は、バスアクセス遅延を作成することです。このメカニズムについては以前の記事の1つで説明しましたが、問題があることを警告しました。2番目の方法はクラシックです。ステータスレジスタを入力します。トランザクションの開始時に、完了時にBSY信号を設定します-リセット。そして、すべての責任をバスマスターロジック（Nios IIプロセッサまたはJTAGブリッジ）に割り当てます。各オプションには、独自の長所と短所があります。バス遅延を使用したバリアントは既に実行しているので、変更のために、ステータスレジスタを使用して今日すべてを実行しましょう。

メインマシンを設計

最初に注目したいのは、私のお気に入りのRSトリガーです。2台のマシンがあります。1つ目はAVALON_MMバスに対応し、2つ目はULPIインターフェースに対応します。それらの間の接続がいくつかのフラグを通過することがわかりました。各フラグに書き込むことができるプロセスは1つだけです。各オートマトンは、独自のプロセスによって実装されます。どうやって？しばらくの間、RSトリガーの追加を開始しました。2ビットなので、2つのRSフリップフロップで生成する必要があります。はい、どうぞ：

//   
always_ff @(posedge ulpi_clk)
begin
      //    
      if  (reg_served)
           write_busy <= 0;
      else if (have_reg)
           write_busy <= 1;

      //    
      if  (read_finished)
           read_busy <= 0;
      else if (reg_request)
           read_busy <= 1;
end

1つのプロセスはreg_servedを呼び出し、2番目のプロセスはhave_regを呼び出します。そして、独自のプロセスのRSフリップフロップは、それらに基づいてwrite_busy信号を生成します。同様に、read_busyはread_finishedとreg_requestから形成されます。別の方法で行うこともできますが、クリエイティブパスのこの段階では、この方法が好きです。

これは、BSYフラグが設定される方法です。黄色は書き込みプロセス用、青色は読み取りプロセス用です。Verilogovプロセスには、非常に興味深い機能が1つあります。その中で、値を割り当てることができるのは1回ではなく、複数回です。したがって、信号を1クロックサイクルの間離陸させたい場合は、プロセスの最初にそれを無効にし（両方の信号がそこで無効になることがわかります）、1クロックサイクル中に実行される条件によって1に設定します。条件を入力すると、デフォルトが上書きされます。それ以外の場合はすべて機能します。したがって、データポートへの書き込みは、1クロックサイクルのhave_reg信号のテイクオフを開始し、制御ポートへのビット0の書き込みは、reg_request信号のテイクオフを開始します。

同じテキスト。

//  AVALON_MM  
always_ff @(posedge ulpi_clk)
begin
   //    ,    
   //      
   have_reg    <= 0;
   reg_request <= 0;

   if (write == 1) 
   begin
      case (address)
          0 : addr_to_ulpi <= writedata [5:0];
          //       
          1 : begin
                data_to_ulpi <= writedata [7:0];
                have_reg <= 1;
              end
          2 : begin
                //      
                reg_request <= writedata[0];
		force_reset = writedata [31];
              end
         3: begin end
      endcase
   end
end

上記で見たように、対応するRSフリップフロップを1に設定するには、1クロックサイクルで十分です。そして、この瞬間から、設定されたBSY信号がステータスレジスタから読み取られ始めます。

同じテキスト。

//  AVALON_MM  
always_comb 
begin
   case (address)
      //   (  )
      0 : readdata <= {26'b0, addr_to_ulpi};

      //  
      1 : readdata <= {23'b0, data_from_ulpi};

      // 2 -  ,   -   

      //  
      3 : readdata <= {30'b0, (reg_request | read_busy), (have_reg | write_busy)};
      default: readdata <= 0;
   endcase
end

実際、当然のことながら、AVALON_MMバスで機能するプロセスに精通しています。

ulpi_dataバスでの作業の原則についても思い出させてください。このバスは双方向です。したがって、標準の手法を使用して作業する必要があります。これは、対応するポートの宣言方法です。

   inout        [7:0]  ulpi_data,

このバスから読み取ることはできますが、直接書き込むことはできません。代わりに、レコードのコピーを作成します。

logic [7:0] ulpi_d = 0;

そして、このコピーを次のマルチプレクサを介してメインバスに接続します。

//      inout-
assign ulpi_data = (ulpi_dir == 0) ? ulpi_d : 8'hzz;

メインマシンのロジックについては、Verilogコード内でできるだけコメントするようにしました。遷移グラフの開発中に予想したように、実際の実装では、ロジックが多少変更されています。いくつかの州は捨てられました。それでも、グラフとソーステキストを比較して、そこで行われているすべてのことを理解していただければ幸いです。したがって、このマシンについては触れません。実用的な実験の結果に基づいて、変更前の時点でのモジュールの全文を参照用に参照することをお勧めします。

モジュールの全文。

module ULPIhead
(
   input               reset,
   output              clk66,

   // AVALON_MM
   input        [1:0]  address,
   input               write,
   input        [31:0] writedata,
   input               read,
   output logic [31:0] readdata = 0,

   // AVALON_ST
   input  logic        source_ready,
   output logic        source_valid = 0,
   output logic [15:0] source_data = 0,

   // ULPI
   inout        [7:0]  ulpi_data,
   output logic        ulpi_stp = 0,
   input               ulpi_nxt,
   input               ulpi_dir,
   input               ulpi_clk,
   output              ulpi_rst
);

logic      have_reg = 0;
logic      reg_served = 0;
logic      reg_request = 0;
logic      read_finished = 0;
logic [5:0] addr_to_ulpi;
logic [7:0] data_to_ulpi;
logic [7:0] data_from_ulpi;

logic      write_busy = 0;
logic      read_busy = 0;

logic [7:0] ulpi_d = 0;

logic force_reset = 0;

//   
always_ff @(posedge ulpi_clk)
begin
      //    
      if  (reg_served)
           write_busy <= 0;
      else if (have_reg)
           write_busy <= 1;

      //    
      if  (read_finished)
           read_busy <= 0;
      else if (reg_request)
           read_busy <= 1;
end

//  AVALON_MM  
always_comb 
begin
   case (address)
      //   (  )
      0 : readdata <= {26'b0, addr_to_ulpi};

      //  
      1 : readdata <= {23'b0, data_from_ulpi};

      // 2 -  ,   -   

      //  
      3 : readdata <= {30'b0, (reg_request | read_busy), (have_reg | write_busy)};
      default: readdata <= 0;
   endcase
end   

//  AVALON_MM  
always_ff @(posedge ulpi_clk)
begin
   //    ,    
   //      
   have_reg    <= 0;
   reg_request <= 0;

   if (write == 1) 
   begin
      case (address)
          0 : addr_to_ulpi <= writedata [5:0];
          //       
          1 : begin
                data_to_ulpi <= writedata [7:0];
                have_reg <= 1;
              end
          2 : begin
                //      
                reg_request <= writedata[0];
		force_reset = writedata [31];
              end
         3: begin end
      endcase
   end
end   

//   
enum {idle,
wait1,wr_st,
wait_nxt_w,hold_w,
wait_nxt_r,wait_dir1,latch,wait_dir0

} state = idle;
always_ff @ (posedge ulpi_clk)
begin
   if (reset)
   begin
       state <= idle;
   end else
   begin
      //    
      source_valid <= 0;
      reg_served  <= 0;
      ulpi_stp <= 0;
      read_finished <= 0;
      case (state)
      idle: begin
           if (ulpi_dir)
               state <= wait1;
           else if (have_reg) 
                begin
                  //      , 
                  //    ,   
                  // 
                  ulpi_d [7:6] <= 2'b10;
                  ulpi_d [5:0] <= addr_to_ulpi;
                  state <= wait_nxt_w;
                end
           else if (reg_request)
                begin
                  //  -   
                  ulpi_d [7:6] <= 2'b11;
                  ulpi_d [5:0] <= addr_to_ulpi;
                  state <= wait_nxt_r;
                end
         end
      //      TURN_AROUND
      wait1 : begin
            state <= wr_st;
            //    ,   
            source_valid <= 1; 
            source_data <= {7'h0,!ulpi_nxt,ulpi_data};
         end
      //     DIR -    AVALON_ST
      wr_st : begin
            if (ulpi_dir)
            begin
              //   ,    
               source_valid <= 1;
               source_data <= {7'h0,!ulpi_nxt,ulpi_data};
            end else
               //      wait2,
               //   ,   - . 
               state <= idle;
         end
      wait_nxt_w : begin
           if (ulpi_nxt)
           begin
              ulpi_d <= data_to_ulpi;
              state <= hold_w;
           end
         end
      hold_w: begin
           //   ,  ULPI 
           //     .   NXT
           //  ...
           if (ulpi_nxt) begin
              // ,  AVALON_MM    
              reg_served  <= 1;
              ulpi_d <= 0;    //   idle
              ulpi_stp <= 1;  //     STP
              state <= idle;  //   -    idle
           end
         end
       //   STPw   ...
       // ...
      //    . ,   NXT
      //    ,    
      wait_nxt_r : begin
           if (ulpi_nxt)
           begin
              ulpi_d <= 0;    //    
              state <= wait_dir1;
           end
         end
      // ,    
      wait_dir1: begin
          if (ulpi_dir)
             state <= latch;
        end
      //    
      //   -   
      latch: begin
          data_from_ulpi <= ulpi_data;
          state <= wait_dir0;
        end
      // ,     
      wait_dir0: begin
          if (!ulpi_dir)
          begin
             state <= idle;
             read_finished <= 1;
          end
        end
   
      default:	begin
         state <= idle;
         end
      endcase
    end
end
//      inout-
assign ulpi_data = (ulpi_dir == 0) ? ulpi_d : 8'hzz;

// reset   ,      
assign ulpi_rst = reset | force_reset;

assign clk66 = ulpi_clk;

endmodule

プログラマーガイド

ULPIレジスタアドレスポート（+0）

作業が行われるバスのULPIレジスタのアドレスは、オフセット+0でポートに配置する必要があります

ULPIレジスタデータポート（+4）

このポートに書き込む場合：レジスタアドレスのポートにアドレスが設定されたULPIレジスタへの書き込みプロセスが自動的に開始されます。前の書き込みのプロセスが完了するまで、このポートへの書き込みは禁止されています。

読み取り時：このポートは、ULPIレジスタから最後に読み取られた値を返します。

ULPI制御ポート（+8）

読み取り値は常にゼロです。書き込みのビット割り当ては次のとおりです。

ビット0-単一の値を書き込むとき、ULPIレジスタの読み取りプロセスを開始します。ULPIレジスタのアドレスは、ULPIレジスタのアドレスポートに設定されています。

ビット31-1を書き込むとき、RESET信号をULPIチップに送信する。

残りのビットは予約されています。

ステータスポート（+ 0x0C）

読み取り専用。

ビット0-WRITE_BUSY。1の場合、ULPIレジスタへの書き込みプロセスが進行中です。

ビット1-READ_BUSY。1の場合、ULPIレジスタからの読み取りプロセスが進行中です。

残りのビットは予約されています。

結論

USBアナライザーヘッドの物理的な編成方法について知り、ULPIマイクロ回路を操作するための基本的なオートマトンを設計し、このヘッドにSystemVerilogドラフトモジュールのドラフトを実装しました。次の記事では、モデリングプロセスを確認し、このモジュールをシミュレートしてから、実際にコードを完成させる結果に基づいて、実際の実験を行います。つまり、最後まで少なくとも4つの記事があります。

Reddコンプレックスに基づくUSBバスアナライザーのヘッドの作成