Defaults bei CASE-Anweisungen

[Messi (Gast)]

Ich habe eine Unsicherheit mit Defaults bei CASE-Anweisungen - ich bin 
nicht sicher, wo die hinkommen und ob das so geht:

Bei der Applikation soll EINER von 4 (demnächst 16) DMA-Kanälen 
beschickt werden. Es sind FIFOs, in die ADR+DAT+CNT eingeschrieben wird.
D.h. alle bis auf 1 Kanal müssen die ENA auf 0 haben.
Ich habe es IN das case geschrieben und da wollte er es nicht haben.
Dann habe ich es VOR den case geschrieben und es simuliert richtig.
Allerdings habe ich seltsame Effekte beim Testen: Manche Kanäle werden 
wegsynthetisiert und ich habe den Verdacht, dass die nicht aktiviert 
werden.

Ist das so in Ordnung?

Oder muss ich bei jedem ENA=1 auch die anderen mit 0 einsetzen?

Ich würde mir das gerne ersparen und verstehen, weil es auf 16 ch 
erweitert werden soll.

    
        if (high_out ='1') then

            trx_dma_ch1_ena <= '0';
            trx_dma_ch2_ena <= '0';
            trx_dma_ch3_ena <= '0';
            trx_dma_ch4_ena <= '0';

            case dma_channel_no is    

                when "00" =>
                    trx_dma_ch1_adr <= inp_dma_trx_adr;
                    trx_dma_ch1_dat <= inp_dma_trx_dat;
                    trx_dma_ch1_cnt <= trx_dma_ch1_cnt+1;
                    trx_dma_ch1_ena <= '1';

                when "01" =>
                    trx_dma_ch2_adr <= inp_dma_trx_adr;
                    trx_dma_ch2_dat <= inp_dma_trx_dat;
                    trx_dma_ch2_cnt <= trx_dma_ch2_cnt+1;
                    trx_dma_ch2_ena <= '1';

                when "10" =>
                    trx_dma_ch3_adr <= inp_dma_trx_adr;
                    trx_dma_ch3_dat <= inp_dma_trx_dat;
                    trx_dma_ch3_cnt <= trx_dma_ch3_cnt+1;
                    trx_dma_ch3_ena <= '1';

                when others =>
                    trx_dma_ch4_adr <= inp_dma_trx_adr;
                    trx_dma_ch4_dat <= inp_dma_trx_dat;
                    trx_dma_ch4_cnt <= trx_dma_ch4_cnt+1;
                    trx_dma_ch4_ean <= '1';

[Achim S. (Gast)]

Messi schrieb:
> Dann habe ich es VOR den case geschrieben und es simuliert richtig.

geht in Ordnung. Das ganze steht ja innerhalb eines Prozesses. Und wenn 
du innerhalb des Prozesses einem Signal mehrmals nacheinander Werte 
zuweist, dann wird nur die letzte Zuweisung wirksam. Von deinen 
trx_dma_chx_ena Signalen wird also nur eins den Wert 1 haben, die 
anderen wie gewünscht 0.

Messi schrieb:
> Allerdings habe ich seltsame Effekte beim Testen: Manche Kanäle werden
> wegsynthetisiert und ich habe den Verdacht, dass die nicht aktiviert
> werden.

Vielleicht nimmt dma_channel_no nie den Wert des weg-optimierten Kanals 
an. Oder high_out wird nie 1. Oder irgendwas anderes, das man deinem 
Code-Schnippsel nicht ansehen kann.

[J. S. (engineer)]

Achim S. schrieb:
> Vielleicht nimmt dma_channel_no nie den Wert des weg-optimierten Kanals
> an.

Oder hinten dran hängt irgend etwas dran, was nicht richtig ist und 
Ursache für das Verschwinden ist.

@TE: Verwendest du Code Coverage? Damit lässt sich manch ein 
undefinierter Ast in den IFs auffinden.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Messi schrieb:
> Ist das so in Ordnung?
Eines vorneweg: ganz pfiffig wäre es, die DMA-Kanal-Namensgebung wie in 
der Software- und Hardwarewelt üblich bei 0 beginnen zu lassen. Denn 
wenn "00" den Kanal 1 auswählt und "11" den Kanal 4, dann ist das 
zumindest arg unglücklich.

> Oder muss ich bei jedem ENA=1 auch die anderen mit 0 einsetzen?
Das kommt darauf an, wie diene Hardware diese DMA-Anforderungen 
abhandelt.

> D.h. alle bis auf 1 Kanal müssen die ENA auf 0 haben.
Ich würde dann den gesamten Klimbim von der Datenstruktur her nicht auf 
dieses ausufernde Copy&Paste ausrichten, sondern mit Arrays und einem 
Index arbeiten.
Und vor Allem auch mit Datentypen, die Mehrdeutigkeiten ausschließen. 
Zuallerserst gehört der dma_channel_no vom std_logic_vector in einen 
Integer mit dem range 0 to 15 umgewandelt. Denn dann kannst du den 
aktiven DMA-Kanal eben auch als Integer abspeichern und hast in 4 Bits 
automatisch nur 1 einzigen aktiven "Kanal", statt einer one-hot 
codierten Kanalauswahl mit 15 Bits auf '0' und 1 Bit auf '1'.

> trx_dma_ch1_ena
Wenn du deine Signale umbenennen würdest, könntest du mit Indices 
arbeiten. Hier mal dein Copy-Paste-Ansatz:

:
signal std_logic trx_dma_ch1_ena, 
                 trx_dma_ch2_ena,
                 trx_dma_ch3_ena,
                 trx_dma_ch4_ena,
                 :
                 :
                 :
                 trx_dma_ch15_ena,
                 trx_dma_ch16_ena;
:
:
            trx_dma_ch1_ena <= '0';
            trx_dma_ch2_ena <= '0';
            trx_dma_ch3_ena <= '0';
            trx_dma_ch4_ena <= '0';
            trx_dma_ch5_ena <= '0';
            trx_dma_ch6_ena <= '0';
            trx_dma_ch7_ena <= '0';
            trx_dma_ch8_ena <= '0';
            trx_dma_ch9_ena <= '0';
            trx_dma_ch10_ena <= '0';
            trx_dma_ch11_ena <= '0';
            trx_dma_ch12_ena <= '0';
            trx_dma_ch13_ena <= '0';
            trx_dma_ch14_ena <= '0';
            trx_dma_ch15_ena <= '0';
            trx_dma_ch16_ena <= '0';
:
            case dma_channel_no is    

                when "0000" =>
                    trx_dma_ch1_ena <= '1';
:
                when "0001" =>
                    trx_dma_ch2_ena <= '1';
:
:
:
:
:
                    trx_dma_ch15_ena <= '1';
:
                when "1111" =>
                    trx_dma_ch16_ena <= '1';
:

Das zieht sich hin, braucht laufend viel Tipparbeit und wehe, da 
vergisst mal einer, eine Zahl anzupassen...

Das wäre eine kompaktere one-hot-Lösung:

:
signal trx_dma_ena : std_logic_vector (15 downto 0);
:
     trx_dma_ena <= (others=>'0');
:
     trx_dma_ena(to_integer(unsigned(dma_channel_no)) <= '1';
:

Und ich würde zusehen, dass ich es so machen kann:

:
signal trx_dma_ena : integer range 0 to 15 := 0;
:
:
:
     trx_dma_ena <= to_integer(unsigned(dma_channel_no));
:

[Messi (Gast)]

Die Idee der geschickten Zusammenfassung hatte ich auch bereits. Es ist 
aber leider so, dass der Code für die anderen Kanäle komplizierter ist 
und die Signale dort anders heißen und einige auch für Umsetzer in 
anderen Baugruppen laufen. Ich möchte das nicht alles ändern, weil 
Vieles aus Schaltplänen kommt, die mitgeändert werden müssten.

Mir kommt es einfach darauf an, zu wissen, ob das synthesemäßig i.O. 
ist.