Le configurazioni VHDL avanzate sono mai state utilizzate nella vita reale?

Question

Le configurazioni VHDL possono essere utilizzate per associare componenti a entità con un nome diverso e persino con porte completamente diverse. [see this article for more info]

configuration c2 of testbench is 
    for str 
     for dut_inst : dut 
      use entity work.unrelated(rtl) 
       port map(
        port1 => a, 
        port2 => b, 
        port3 => c, 
        port4 => "unused" 
       ); 
     end for; 
    end for; 
    end configuration c2; 

Qualcuno di voi ha mai visto accadere in un progetto progetto commerciale? Qual era lo scopo di abbandonare un'entità apparentemente non correlata? Perché non hanno semplicemente modificato il codice di istanziazione?

Posso inventare situazioni ipotetiche, ma sono interessato a un caso di utilizzo nella vita reale.

Answer 1

No, non l'ho mai visto in natura.

Suppongo che la maggior parte delle persone (me compreso) non sappia nemmeno che tali cose sono possibili con le configurazioni.

Answer 2

Mai viste le associazioni delle porte cambiano, ma ho visto che si usava legare in diverse versioni di componenti con la stessa mappa di porte. Alcuni esempi che ho visto:

• Associazione in versioni vuote durante la creazione di simulazioni a livello di sistema di grandi dimensioni. Parte del design è sostituita da versioni che non fanno nulla per mantenere basso l'ingombro della memoria durante il test di altre parti del progetto.
• Simile, ma quando si verifica l'infrastruttura del bus di un progetto, si legano in unità semplici che rispondono in modo "selvaggio" e "selvaggio".
• Diverse versioni di un particolare blocco che presentano compromessi di design diversi. per esempio. Una versione grande e veloce, una piccola ma lenta. Può quindi essere sostituito a seconda di cosa è necessario quando il sistema si riunisce o per una particolare applicazione.

Nessuno di questi ha bisogno delle funzionalità di cui si sta parlando. L'unica cosa che posso pensare che l'utilizzo di un componente diverso potrebbe essere utile è se hai qualcosa come più fornitori di librerie di RAM e hai bisogno di scambiarli regolarmente. Anche in questo caso è improbabile che tu possa eseguire una mappatura delle porte one-for-one. C'è sempre un pin di spegnimento che ha bisogno di essere invertito o qualcosa del genere.

Answer 3

Ho usato questo tipo di configurazione alcune volte. Cerco di evitarlo, ma a volte è utile per i test di whitebox.

Supponiamo di avere un'entità molto grande + architettura FooMachine, e desidero scrivere una serie di test dell'unità whitebox riferiti ai segnali all'interno di FooMachine. Idealmente, FooMachine sarebbe suddiviso in più componenti e scriverò test black-box su questi, ma ho ereditato alcune architetture davvero massicce in cui non potevo, da un punto di vista economico, giustificare il tempo necessario al refactoring quando erano necessari solo piccoli cambiamenti.Quello che farò è definire un componente in FooMachine

component Dummy is 
end component Dummy; 

e un'istanza

dummy_g : Dummy; 

Poi, in una prova di unità di segnale x in FooMachine, scriverò un'entità + un'architettura

entity TestDummy is 
    port (
     x : in std_logic 
    ); 
end entity; 

architecture Arch of TestDummy is 
    ... 
end Arch; 

ed una configurazione

configuration conf of ... is 
... 
    for all : FooMachine 
     ... 
     for all : Dummy 
      use entity work.TestDummy(Arch) 
       port map (x => x); 
     end for; 
    end for; 
... 
end configuration; 

E quindi posso scrivere le mie affermazioni in TestDummy.

Ancora, questo non è il modo in cui preferisco scrivere i miei test di unità, ma ci sono stati momenti in cui questa era la soluzione migliore per uno sfortunato problema.