Case mit don't care

[Thomas P. (pototschnig)]

Hallo,

Funktioniert sowas?

  case foo is
    when "0101" => ...
    when "1---" => ...
    when others => ...
  end case;

Muss foo dabei wirklich "1---" enthalten, oder kann es auch "1010" sein? 
Also eben egal sein was die hinteren 3 Bits sind?

Mfg
Thomas Pototschnig

[Thomas H. (mac4ever)]

Don't cares werden doch als X bezeichnet oder ? Ob es funktioniert kann 
ich leider gerade nicht testen. Zur Not würde ich einfach

if foo(3) = '1' then
 -- mach was
end if;

benutzen, da bist Du auf der sicheren Seite.

[Gabriel W. (gagosoft)]

Thomas Hertwig wrote:
> Don't cares werden doch als X bezeichnet oder ?
NEIN, 'X' steht für konfliktbehaftete Signal (mehrere Treiber 
beschreiben ein Signal unterschiedlich. '-' für don't care stimmt schon, 
doch ob das in einem case funktioniert weis ich nicht. ich würde auch 
eher das erste Bit auf '1' abfragen...

[Jan M. (mueschel)]

Mit ISE / xst funktioniert die Synthese einwandfrei. Dabei wird 
allerdings eine Warnung "possible simulation mismatch" ausgegeben. Wo 
genau das Problem dabei liegt, weiss ich jedoch nicht.

[Thomas P. (pototschnig)]

Gabriel Wegscheider wrote:
> Thomas Hertwig wrote:
>> Don't cares werden doch als X bezeichnet oder ?
> NEIN, 'X' steht für konfliktbehaftete Signal (mehrere Treiber
> beschreiben ein Signal unterschiedlich. '-' für don't care stimmt schon,
> doch ob das in einem case funktioniert weis ich nicht. ich würde auch
> eher das erste Bit auf '1' abfragen...

Das Problem ist, dass das Ding auf 100MHz in einem Spartan-III laufen 
muss und ein IF ist zu langsam ... Also gerade mal so geht es nicht. Das 
Design macht natürlich noch wesentlich mehr :-)

Sowas hier geht grad noch:

case foo(3) is
  when '1' => ...
  when '0' =>
    case foo(2 downto 0) is
      when "101" => ...
      when others => ...
    end case;
  when others => ...
end case;

[Andreas S. (andreas) (Admin)]

Thomas Pototschnig wrote:
> Das Problem ist, dass das Ding auf 100MHz in einem Spartan-III laufen
> muss und ein IF ist zu langsam ...

Wieso sollte ein case schneller als ein if sein?

[Bernd G. (Gast)]

> Das Problem ist, dass das Ding auf 100MHz in einem Spartan-III laufen
> muss und ein IF ist zu langsam ...

Um Himmelwillen, VHDL ist nicht C! VHDL beschreibt keinen Ablauf, 
sondern eine Struktur!

[Jan M. (mueschel)]

@Bernd / Andreas:
Logisch gibt es sicher keinen Unterschied, aber ISE ist leider so 
einiges zuzutrauen was (Fehl-)Optimierungen angeht...

[Thomas P. (pototschnig)]

Andreas Schwarz wrote:
> Thomas Pototschnig wrote:
>> Das Problem ist, dass das Ding auf 100MHz in einem Spartan-III laufen
>> muss und ein IF ist zu langsam ...
>
> Wieso sollte ein case schneller als ein if sein?

Case wird meinst Wissens als Multiplexer umgesetzt, bei einem IF weiß 
ich es nicht genau, aber es hat sich öfters herausgestellt, dass das 
Syntheseergebnis langsamer ist, wenn IFs statt case verwendet werden.

Weiß da jemand mehr?

Mfg
Thomas Pototschnig

[Andreas S. (andreas) (Admin)]

If wird genauso als Multiplexer umgesetzt. Wenn du die selbe Logik 
beschreibst kannst du erwarten dass das selbe rauskommt, so blöd ist XST 
wirklich nicht.

[Andreas S. (andreas) (Admin)]

Zum ursprünglichen Problem:
> Muss foo dabei wirklich "1---" enthalten, oder kann es auch "1010" sein?
> Also eben egal sein was die hinteren 3 Bits sind?

Was die Synthese aus don't cares macht weiß ich nicht, aber der 
Simulator kann nichts damit anfangen, "-" ist einfach ein Zeichen wie 1 
oder 0 oder X und wird nicht besonders ausgewertet. Fazit: nicht für 
Vergleiche verwenden. std_match ist eine Alternative, geht aber nur bei 
if, nicht bei case.

[Bernd G. (Gast)]

Irgendwo habe ich mal gelesen...
Ich würde jedenfalls die betreffenden acht Zeilen im case ausschreiben, 
dann liegt man auf der sicheren Seite:

case foo is
    when "0101" => ...
    when "1000" =>
    when "1001" =>
    when "1010" =>
    when "1011" =>
    when "1100" =>
    when "1101" =>
    when "1110" =>
    when "1111" =>
    when others =>
  end case;

[Matthias F. (flint)]

Ich hab da im Xilinx code für den PCIe Endpoint folgendes:

  process(rd_be_o_int, req_addr_i)
  begin

    case rd_be_o_int(3 downto 0) is

      when "0000" => lower_addr <= req_addr_i(6 downto 2) & "00";
      when "---1" => lower_addr <= req_addr_i(6 downto 2) & "00";
      when "--10" => lower_addr <= req_addr_i(6 downto 2) & "01";
      when "-100" => lower_addr <= req_addr_i(6 downto 2) & "10";
      when "1000" => lower_addr <= req_addr_i(6 downto 2) & "11";
      when others => lower_addr <= req_addr_i(6 downto 2) & "00";

    end case;

  end process;

Also die verlassen sich darauf, dass es funktioniert.


Bzgl If vs Case dachte ich, dass der Unterschied ist, dass bei 
If-Elsif-Else unter Umständen Priorisierungslogik dazukommt und es daher 
in der HW langsamer ist. Um den Else-Zweig auszuführen müssen im Prinzip 
alle vorherigen If-Elsif als nicht gültig erkannt werden.

[Bernd G. (Gast)]

> Also die verlassen sich darauf, dass es funktioniert.

Danke, hatte ich bei Xilinx so explizit noch nicht gesehen...

[Andreas S. (andreas) (Admin)]

Matthias F. wrote:
> Ich hab da im Xilinx code für den PCIe Endpoint folgendes:
>
>   process(rd_be_o_int, req_addr_i)
>   begin
>
>     case rd_be_o_int(3 downto 0) is
>
>       when "0000" => lower_addr <= req_addr_i(6 downto 2) & "00";
>       when "---1" => lower_addr <= req_addr_i(6 downto 2) & "00";

Dann kann man wohl annehmen dass es in der Synthese als don't care 
umgesetzt wird. Ich halte es für nicht sehr schlau Code zu schreiben der 
sich in Synthese und Simulation unterschiedlich verhält, aber von 
Standards scheint man bei Xilinx sowieso nicht übermäßig viel zu halten 
(std_logic_unsigned...).

> Bzgl If vs Case dachte ich, dass der Unterschied ist, dass bei
> If-Elsif-Else unter Umständen Priorisierungslogik dazukommt

Ja, wenn sich die Bedingungen überlappen. Da muss man schon aufpassen 
wenn man z.B. std_match verwendet.

Übrigens geht auch folgendes:

case ... is
  when "0000" | "0001" | "0010" => ...;
  when others => ...;
end case;

Spart ein bisschen Schreibarbeit.