2016-03-25 9 views
5

Ho esperienza con Verilog/SystemVerilog ma sono nuovo di VHDL e sto cercando di capire quando utilizzare l'istanziazione dei componenti o l'istanza dell'entità. Per istanza del componente intendo il modo legacy di dichiarare componenti di un'entità prima di istanziarli. D'altra parte, l'istanza dell'entità, che è stata introdotta con VHDL-93, consente di dichiarare un'entità direttamente senza specificare il componente. Related ArticleIstanziazione componente vs Entità istanziata in VHDL

Mi sembra che Entity Instantiation sia sempre preferibile a meno che non si abbia ancora un'architettura implementata e si voglia solo definire una black box.

Questo è uno Related Question che ho trovato ma soddisfa pienamente i miei dubbi. Dal momento che è possibile definire sia la mappa generico e l'architettura per ciascun ente:

entity work.MyEntity_E(ARCH) generic map(
...) 
port map(
... 
); 

cosa è la flessibilità aggiuntiva di fare componente di un'istanza? Quale sarebbe l'esempio più semplice che mostra qualcosa che non può essere eseguito con l'istanza dell'entità ma può essere eseguito con l'istanza componente?

+2

Con l'istanza dell'entità, è necessario scrivere l'entità prima di poter compilare questo file ... Con un componente, è possibile posticiparlo finché non si collega (elabora) il progetto. –

+0

Giusto, questo è quello che intendevo con "Mi sembra che Entity Instantiation sia sempre preferibile a meno che tu non abbia ancora un'architettura implementata e tu voglia solo definire una scatola nera". Mi rendo conto ora che la frase non era molto chiara. Quali sono altri benefici però? Gli articoli che ho elencato affermano che l'approccio alla creazione di componenti è più flessibile e non riesco a capire perché. – igon

+0

IEEE Std 1076-2008 6.8 Dichiarazioni del componente "Una dichiarazione del componente dichiara un'interfaccia per un'entità di progettazione virtuale che può essere utilizzata in un'istruzione di creazione di istanze del componente Una configurazione del componente o una specifica di configurazione può essere utilizzata per associare un'istanza del componente con un'entità di progettazione che risiede in una biblioteca. " – user1155120

risposta

2

Mi piace pensare a un componente come un socket IC. È possibile prendere ulteriormente questa analogia paragonando la compilazione (analisi) per assemblare il PCB e paragonando l'elaborazione a mettere i chip nelle prese. Se si utilizzano prese IC, è possibile assemblare il PCB anche se non si sono ancora ordinati i chip; puoi differire mettendo i chip nella presa fino a tardi. Allo stesso modo se si usano componenti: è possibile compilare il progetto se anche le entità e le architetture corrispondenti ai componenti non esistono ancora; è possibile rinviare vincolante fino a data successiva, fino all'elaborazione.

Quindi, perché potrebbe essere? Perché potrebbero non esistere ancora?

i) È un grande progetto. Non tutti hanno ancora finito il loro blocco. Ma puoi ancora facilmente compilare le simulazioni di livello superiore ed eseguire su entrambi i bit del progetto. Puoi farlo commentando/modificando, ma l'utilizzo di componenti lo rende più semplice.

ii) Hai generato automaticamente alcuni IP. Questo ti ha dato un modello comportamentale per la simulazione, ma nessun modello sintetizzabile - l'idea è che tu combini una vista fisica generata automaticamente dell'IP successivamente nel flusso. Questo è OK per la simulazione, ma come puoi compilare il tuo progetto per la sintesi se c'è un po 'che manca - il tuo IP generato?

iii) Stai eseguendo un'istanza ricorsiva: stai istanziando un blocco al suo interno. Con istanza diretta, hai una situazione di pollo e uova indistruttibile (ovvero una dipendenza circolare ); con l'istanziazione diretta, non è possibile creare un'istanza di qualcosa che deve ancora essere compilata, ma non è possibile compilarla perché l'entità istanziata non è stata ancora compilata. L'istanza componente può interrompere questa dipendenza circolare.

iv) L'istanziazione dei componenti consente anche di istanziare entità diverse nello stesso punto del progetto (sotto il controllo di una configurazione ). @ user1155120 fornisce un esempio di quanto sopra: l'utilizzo dell'istanza del componente (e una configurazione) consente di creare blocchi identici con diversi sotto-blocchi.

Ecco un esempio di confronto dei due su EDA Playground - https://www.edaplayground.com/x/2QrS.

+0

Ri: iii, C'è una distinzione tra analisi (oggetti in una libreria - compilazione) ed elaborazione (collegamento e caricamento). Non è possibile elaborare fino alla riunione IEEE Std 1076-2008 13.5 Ordine di analisi "Un'unità primaria il cui nome è indicato all'interno di una data unità di progetto deve essere analizzata prima dell'analisi dell'unità di progetto indicata." Nel caso di un'indicazione di associazione predefinita, manca una dichiarazione di configurazione (7.3.3) in cui una dichiarazione di entità visibile non soddisfa l'ordine di analisi. Analogamente, una dichiarazione di configurazione (un'unità primaria) non riuscirà a elaborare. In analisi il problema è la visibilità. – user1155120

+0

@ user1155120 Non ho pensato allo scenario iii). Posso vedere come potrebbe essere usato per l'ordinamento di reti o simili. Sto leggendo sulle configurazioni, hanno qualche equivalente in Verilog? – igon

+0

@igon Verilog ha configurazioni: [http://www.eda.org/sv-bc/hm/att-2972/ADV01_Configs_51_55.pdf](http://www.eda.org/sv-bc/hm/ att-2972/ADV01_Configs_51_55.pdf) –

1

VHDL era in origine un linguaggio di documentazione hardware. Non una simulazione né una sintesi.

Sono d'accordo che l'istanziazione dei componenti è dolorosamente dettagliata, ma è più leggibile nel caso in cui l'entità non sia dichiarata sullo stesso file sorgente.

Inoltre, su progetti veramente grandi. Permette di separare la compilazione di ogni entità. Quindi cambiare un'entità non significa ricompilare l'intero progetto.

E consente di scambiare facilmente con gli archetti comportamentali per la simulazione. Cioè: una DRAM sarà solo una manciata di porte della tua fpga. Oppure puoi scaricare un modello di dram e verificare che il tuo codice funzioni come previsto. Non è necessario tornare indietro e modificare l'istanziazione ogni volta che si simula qualcosa.

+0

Capisco i vantaggi _supposed_ in termini di leggibilità e beneficio della compilazione.Quello che mi inciampa è che gli [articoli] (http://www.fpga-dev.com/leaner-vhdl-with-entity-instantiation/) che ho collegato menzionano l'istanza del componente come più potente perché ti consente di ** configurare ** l'entità in modo più dettagliato. Qual è qualcosa che io ** non posso fare ** con l'istanza dell'entità, ma posso farlo con l'istanziazione dei componenti? – igon

+1

Leggi [questo] (http://www.doulos.com/knowhow/vhdl_designers_guide/configurations_part_1/) sulle configurazioni – xvan

+1

A [DES] (https://www.dropbox.com/s/abjv929qo0kb90o/vhdl_des.tar.gz ? dl = 1) modello utilizzando la configurazione per 4 componenti identici tranne S Box (ROM). Senza la configurazione dei componenti, sarebbero necessarie quattro architetture uniche, ciascuna delle quali istanziata in modo univoco con due caselle S. La configurazione dei componenti può rendere più compatti, più facili da creare o gestire le descrizioni e la sostituzione di componenti specifici per i componenti virtuali. È inoltre possibile mappare componenti istanziati (ad es. Primitive) a librerie diverse e fornire le loro mappe generiche e portuali nelle indicazioni di associazione delle specifiche di configurazione. – user1155120

1

Una delle cose che è possibile eseguire con la configurazione (che dipende dall'istanza del componente) è l'uso di componenti virtuali.

È possibile scrivere una descrizione VHDL che dipende da una qualche entità idealizzato (chiamato x qui) e la mappa di componente diverso con differenti nomi dei segnali di porta:

entity a is 
    port (
     in1: in bit; 
     in2: in bit; 
     out1: out bit 
    ); 
end entity; 
architecture fum of a is 
begin 
    out1 <= in1 xor in2; 
end architecture; 

entity b is 
end entity; 

architecture foo of b is 
    component x is 
     port (
      a: in bit; 
      b: in bit; 
      c: out bit 
     ); 
    end component; 
    signal a, b, c: bit; 
begin 
TARG: 
    x 
     port map (
      a => a, 
      b => b, 
      c => c 
     ); 

STIMULI: 
    process 
    begin 
     wait for 2 ns; 
     a <= '1'; 
     wait for 2 ns; 
     b <= '1'; 
     wait for 2 ns; 
     a <= '0'; 
     wait for 2 ns; 
     b <= '0'; 
     wait for 2 ns; 
     a <= '1'; 
     wait for 2 ns; 
     wait; 
    end process; 

end architecture; 

configuration fum of b is 
    for foo 
     for TARG: x use entity work.a 
      port map (
       in1 => a, 
       in2 => b, 
       out1 => c 
      ); 
     end for; 
    end for; 
end configuration fum; 

elaborazione e simulando la configurazione dà:

fum.png

Quando si osservano i segnali di porta di TARG.

Questa capacità è stata concepita per essere utilizzata per mappare primitive da librerie di produttori diverse a una dichiarazione di componente standard.

La complessità percepita coinvolta nella configurazione è stata contrastata con librerie di portabilità come LPM (Libreria di moduli parametrizzati) che aggiungono un diverso asse di complessità tramite l'uso di attributi e generici mentre standardizza i nomi di interfaccia e riduce il numero di primitive di libreria.

La sintesi comportamentale è avanzata al punto che entrambi i metodi delle specifiche di progettazione strutturale sono caduti sul lato.

Il supporto del fornitore FPGA per le dichiarazioni di configurazione esplicite è anche storicamente ritardato. È possibile notare che IEEE Std 1076.6-2004 (RTL Synthesis, ora ritirato) richiede il supporto per le dichiarazioni di configurazione e la configurazione implicita fornisce indicazioni di associazione predefinite durante l'elaborazione.