VHDL:アーキテクチャの命名と解釈


14

注:ザイリンクスのISEを使用しており、(スイッチやライトなどを使用して)動作するFPGAボードを使用しており、これまでにいくつかの簡単なプロジェクトをハッキングしました。同時に、私がやっていることの基礎を築くためのいくつかのチュートリアルを読んでいます。

私はこれまでに行ってきた参考資料で言及されているさまざまなエンティティとそのアーキテクチャを見てきましたが、ネーミングはしばしば混乱を招きます。多くの場合、「architecture rtl of ..」または「architecture Structural of ...」の代わりに、「architecture foo of ...」または「architecture arch of ...」も表示されます。

この問題を回避するために、より一貫性のある命名規則を使用できることを示唆するスタイルガイドがありますが、アーキテクチャ名はエンティティの命名と同じようにarbitrary意的であることを(偶然に)認識します。これはいくつかの質問に私を導きます:

  • エンティティを見て、アーキテクチャ名からのヒントなしで、使用されている実際のアーキテクチャモデルをどのように判断できますか?RTL、行動、構造...これらは私の学習者の目に非常に似ているように見えます(私が見た例が実際に正しく命名されていると仮定して)。ここでは、シンプルだが明らかな例が役立ちます(または、1つのポインター)。

  • 単一のエンティティに複数のアーキテクチャを指定する場合(これは可能です)、同じファイル内で異なる名前をアーキテクチャに付けるだけですか?

  • アーキテクチャ名は特定のエンティティに限定されていますか(つまり、複数のエンティティで同じアーキテクチャ名を使用することで「名前空間」に問題がありますか)。

編集:およびもう1つ:

  • RTLとビヘイビアの間に違いがあるように見えますが、上記のように、私が見た例では実際には見ていません(多くの場合、定義されているアーキテクチャは1つだけです)。あるアーキテクチャは他のアーキテクチャよりも一般的ですか?

私が探していたのは、ベストプラクティス(適切な命名、すべてが1つのファイルに詰め込まれているわけではないなど)を使用して記述された、包括的でシンプルなマルチコンポーネントプロジェクト(小さなコンポーネント)です。適切に作成されたサンプルプロジェクトは、基本原則とベストプラクティスを明らかにするのに非常に役立ちます。このようなサンプルプロジェクトをご存知の場合は、それへのポインタにも感謝します。(他に何もなければ、おそらく私がこれを理解したら、私は自分のものを共有することができます...)

回答:


6

エンティティを見て、アーキテクチャ名からのヒントなしで、使用されている実際のアーキテクチャモデルをどのように判断できますか?

できません- インスタンス化または構成されている場合、アーキテクチャを指定できます(複数選択できる場合)。または、デフォルトが選択されます。

単一のエンティティに複数のアーキテクチャを指定する場合(これは可能です)、同じファイル内で異なる名前をアーキテクチャに付けるだけですか?

それらに異なる名前を付けます。同じファイル内にある必要はありません(実際、VHDLは、どのファイルに何が入っているかを考えるよりもずっと気にしません)

アーキテクチャ名は特定のエンティティに限定されていますか(つまり、複数のエンティティで同じアーキテクチャ名を使用することで「名前空間」に問題がありますか)。

これらはエンティティに「アタッチ」されているため、再利用できます。

よく使う a1合成可能なすべてのアーキテクチャとしてします

  • rtl 私が書いているよりも低いレベル(多くの読者にとって)であることを意味します。
  • behavioural 多くの場合、合成できないことを意味します(一部の読者にとって)
  • synth モデルのシンセサイザーによって使用されます(そうでない場合は使用していました)

a1 これまで競合しておらず、混乱を引き起こしていません;)

実際に複数のアーキテクチャを使用している場合は、冗長な名前を付ける傾向があります(たとえばhard_multiplierslut_multipliersMUL18ブロックをインスタンス化する、またはインスタンス化しないフィルターの場合)。

非常に多くの場合、1つのアーキテクチャしか持っていないので、問題ではありません。適切なエンティティ名がはるかに重要です。

RTLとビヘイビアの間に違いがあるように見えますが、上記のように、私が見た例では実際には見ていません(多くの場合、定義されているアーキテクチャは1つだけです)。あるアーキテクチャは他のアーキテクチャよりも一般的ですか?

それは歴史的なものでした-「振る舞い」コード(かつては追加などが含まれていました!)を合成できなかったため、加算器などをインスタンス化したRTLバージョンを作成しました。(それは私が理解しているとおりです-1999年頃にVHDLを開始して以来、振る舞いの(そしてまだ合成可能な)コードを書いてきました!)


ポイントごとの回答に感謝します!
MartyMacGyver

私もほぼ同じです。すべてのアーキテクチャに名前を付け、arch代わりにエンティティに適切な名前を付けることに焦点を当てています。エンティティに複数のアーキテクチャがあることはめったにありませんが、他の名前を付けるだけです。ただし、私にとっては、behavioural不可能なコードや合成を意図していないコードを意味します。また、rtl抽象化レベルに関係なく、合成を目的としたすべてのHDLに適した名前であるという考えが常にありました。(私は、常にこれらのポイントのいずれかで間違っているかもしれませんが、それはそれらの言葉の使用についての私の理解でした。)
カール14

8

アーキテクチャタイプは次のとおりです。

行動:

一般的な注意事項:

  • 従来、階層はありません(1つのファイルのみ、インスタンス化されたコンポーネントはありません)。これはツールによって異なります。
  • シミュレーションが非常に迅速です。
  • 信号の動作が定義されています。
  • ビヘイビアがシミュレーションのみに使用される場合、合成不可能なコードが含まれる場合があります。合成を目的とする動作は、当然合成可能でなければなりません。

ザイリンクス固有の注意事項

  • 通常、コアジェネレーターモデルは合成前の.vhdファイルです

構造:

一般的な定義

  • コンポーネントをインスタンス化し、それらを一緒に配線します(階層的)。
  • 振る舞いよりもシミュレートするのが遅い。
  • 最上位には実際の信号動作の定義はありません。
  • 合成可能なコードのみ。

ザイリンクスxpecificの注意事項

  • コアジェネレーターモデルはタイミングを考慮しません。
  • 一般に、コアジェネレーターモデルは合成後のネットリストをインスタンス化します

上記は基本的に建築の伝統的な主な2つの動物です。非常に一般的には、両方のプロパティを含む「混合」定義が使用されます。

RTL:

一日の終わりにFPGAに実際に置かれるRTL。したがって、これはシステムの動作を定義する合成可能なコードであり、コード階層で構成されています。
最下層は合成可能な動作であり、信号動作の核心が定義され、上位レベルは構造的です。必要に応じて、振る舞いのコンポーネントを結び付けて、大きなトップレベルの「ブロック図」を作成します。

複数のアーキテクチャについて:

アーキテクチャはすべて1つのファイルまたは複数のファイルにすることができます。唯一重要なことは、エンティティが最初にコンパイルされ、使用されるアーキテクチャが指定されることです。

この本は非常に便利で、この種のことをかなり詳しく説明しています。

明確な行動モデルと構造モデルを持つこと、または単にそれらを混合することに関して、物事がどのように行われるべきかについての厳格なルールはありません。通常、巨大なファームウェア設計(またはコードを共有して再利用する大企業)では、2つを区別して問題を簡素化することが役立ちますが、結局のところ、それはあなたのために働くものになります。


答えと本のヒントをありがとう(ただし、入手しにくいアイテムであることは明らかです)。
-MartyMacGyver

@MartyMacGyver:ええ、私は通常google docsバージョンを読みます:P
stanri

私はそうするつもりですが、意図的にページが欠落しています
...-MartyMacGyver

1

まず第一に、現実世界のアーキテクチャ設計はそのように厳密に分類することはできません。なぜ自分を制限するのですか?他のエンティティをインスタンス化して「構造的に」接続しますが、プロセスまたは同時割り当てをあちこちに追加して「rtl」ロジックを追加し、おそらく「ビヘイビア」コーディングパターンを使用して、シンセサイザーが関心のない詳細(特に、エリア/パイプライン/パフォーマンスパラメーターを使用して加算器をインスタンス化せずに追加するなど)、すべて同じアーキテクチャ内。

さらに重要なことは、現在のasic / fpga技術で合成可能なものとそうでないものを理解する必要があり、これはアーキテクチャモデルに関係ないことです。

エンティティは複数の方法で実装でき、わずかに異なる動作を許可することもできるため、同じエンティティに対して複数のアーキテクチャを使用できます。さらに、シミュレーションのみ(通常は合成不可)のアーキテクチャがあり、「実際の」バージョンよりも速くシミュレートできます。これは、大きなデザイン全体をテストベンチするときに便利です。これらのアーキテクチャに名前を付けて、他のアーキテクチャとの違いを思い出せるようにします。また、現実世界のデザインのハイブリッドな性質を考えると、通常bhv / str / rtlでは不十分または正確ではありません。

特定の質問に関して、アーキテクチャ宣言はエンティティ名に関連付けられているため、異なるエンティティの同じ名前のアーキテクチャで名前空間の問題はありません。同じエンティティのアーキテクチャに異なる名前を使用するだけです。

アーキテクチャは異なるファイルに存在できますが、エンティティ宣言が最初にコンパイルされることを確認する必要があります。

エンティティをインスタンス化するとき、または構成ステートメントを使用するときに使用するアーキテクチャを選択できます。そうしないと、デフォルトは「通常」、コンパイラが特定のエンティティ宣言に対して見た最後のアーキテクチャになります。


1
ご回答有難うございます!共通のテーマは、デザインが一般に私が読んでいる建築の鳩の巣にきちんと収まらないということです。願わくば、この問題についての(やや退屈な)好奇心を満たすための標準的な例を見つけることができればいいのですが…もし、「理想」から逸脱するつもりなら、少なくとも理想の外観を知りたいです。
-MartyMacGyver
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.