Mux als Tristate-Ersatz bläst das Design auf?

[Christian P. (kron)]

Hallo,

ich habe in einem Design den schon mehrfach gelesenen
Rat befolgt, bei einem Datenbus keine Tristates in den
einzelnen Modulen zu verwenden, sondern einen Mux in der Top-Ebene.
Dieser sieht bei mir so aus:

  mux_signal <= ctrl_oe_r2 & tmp_oe_r2 & lcd_oe & stat_oe_r2 & codec_audio_en;

  MUX: process
  begin
      case mux_signal is
      when "01111" =>
        d_out <= d_out_ctrl;
      when "10111" =>
        d_out <= d_out_sr_tmp;
      when "11011" =>
        d_out <= d_out_c2;  
      when "11101" =>
        d_out <= d_out_cs_control;
      when "11110" =>
        d_out <= d_out_audio;
      when others =>
        d_out <= (others => '-');
      end case;
  end process MUX;

Soweit so gut. ISE 8.1 macht aber daraus (ich gucke in der 
RTL-Schematic) merkwürdige Sachen.
Das mux-signal wird nicht einmal, sondern fünfmal erzeugt, und dann wird 
für jedes Element von d_out ein Konstrukt aus ANDs und OR5 gemacht. 
(Jeweils d_out_xxx und ein Mux-Signal, das 5mal und damit ein OR5).
Obwohl das die gewünschte Funktion hat, muss ich doch stark zweifeln,
ob das so ideal ist, das muxen wird hier überhaupt nicht als solches 
erkannt.
Kann ich das irgendwie anders schreiben, sodass mein Design ein bißchen 
kleiner wird und der Mux wirklich ein Mux wird?

[na (Gast)]

Erstmal eine sensitivity list dazuschreiben, auch wenn das nicht zum 
eigentlichen Problem gehört.
Wird das mux_signal wirklich fünfmal erzeugt oder lediglich dessen 
Bitleitungen getrennt? Vermutlich nimmt er die einzeln, weil es ja nur 
jeweils um die '0' des Bitsignals geht. Es wird so etwas gebaut wie

d_out <= (not mux_signal(4) and d_out_ctrl) or (not mux_signal(3) and 
d_out_sr_temp) or ...

bzw. so breit erweitert, wie d_out eben ist. Das macht dann einige ANDs 
und ORs aber ein MUX ist ja nichts anderes.

[Joerg W. (joergwolfram)]

Ich denke, das hängt mit der Optimierung und Deiner Quelle für das 
Mux-Signal zusammen. Dadurch wird nicht das Mux-Signal als reales 
Zwischenprodukt erzeugt und dadurch die Laufzeit verringert. Das wäre 
zumindest meine Erklärung dafür.

Gruß Jörg

[Christian P. (kron)]

Aah, jetzt habe ich gefunden, warum das mux-Signal 5mal erstellt wird!
Das ist jeweils ein 5er AND, wobei immer eins der 5 Signale invertiert 
wird!
Und dann braucht es natürlich für jede Stelle von d_out jedes dieser 5 
Signale, weil dann jedes der d_outs AND das jeweilige mux-Signal 
genommen wird.
Naja, wie gesagt, es macht zwar das, was es soll, aber scheint mir halt 
etwas kompliziert. Und in der RTL-Schematic wird eben auch kein Mux 
angezeigt.
Hingegen bei diesem Code hier:

mux: process (fab,MCLK,count)
begin
  case fab is
    when "00" => 
      CO_CLK <= MCLK;
    when "01" =>
      CO_CLK <= count(1);
    when "10" =>
      CO_CLK <= count(0);
    when "11" =>
      CO_CLK <= count(2);
    when others =>
      null;
  end case;
end process mux;

Erscheint in der Schematic dann wirklich ein Mux, der von "fab" 
gesteuert wird. Aber das geht vielleicht nicht bei a) einem 5-stelligen 
Kontrollsignal und b) bei einem Datenbus statt einem einzelnen Signal.

[na (Gast)]

Nur weil die schematic etwas umfangreicher aussieht, muss das deswegen 
nicht umständlicher sein.
Was du in deinem letzten post geschrieben hast, war das was ich mit 
meinem ersten post meinte. Es geht bei deinem MUX immer nur darum, ob 
ein bestimmtes Bit 0 ist. Deswegen wird das zu der logischen Gleichung, 
oben beschrieben, geformt. Das ist im Endeffekt effektiver als ein 
ganzer MUX. Denn, was macht ein Mux intern:

mux_out <= (mux_sel and mux_in_a) or ((not mux_sel) and mux_in_b);

und das für jedes Bit des mux_in-Signals. Die Benutzung eines schon auf 
dem FPGA vorhandenen MUX ist u.U. schneller, da speziell optimiert aber 
die Umsetzung in AND und OR ist in deinem Fall zumindest nicht 
komplexer.