Vivado Warnung, "Sequential element unused" warum tritt sie auf?

[Matze (Gast)]

Hallo,

Ich habe ein an sich übersichtliches VDHL-Design, welches in der 
Behavorial-Simulation funktioniert.

Wird, es jedoch Synthetisiert, so erscheinen viele Warnungen der Sorte:

[Synth 8-3332] Sequential element (\SPI/timestamp_reg[47] ) is unused 
and will be removed from module Main.

Dabei werden alle Signale zu Beginn mittels reset initialisiert und 
ihnen vielfach Werte zugewiesen.

Durch Attribute wie "keep" oder "dont touch" ergibt sich keinerlei 
Ändeung, die Signale werden weiterhin als unused erkannt und entfernt.

Selbst wenn die Signale herausführt und direkt auf Pins gegeben werden, 
so sind sei weiterhin unused.

Habt ihr ideen woran es liegen könnte?

[Da D. (dieter)]

Der Fehler ist in Zeile 42.

[Dussel (Gast)]

Wahrscheinlich werden die Signale nicht benutzt -.-

Wenn du ein Signal hast, das immer 0 ist, wird der entsprechende Pin auf 
Masse gelegt und das Signal wegoptimiert.
Warum das so ist, ist nicht immer einfach herauszufinden. Ich hatte das 
Problem auch mal und habe relativ lange gesucht, bis ich rausgefunden 
habe, warum das Signal nicht geändert wird.

[Matze (Gast)]

Dussel schrieb:
> Wenn du ein Signal hast, das immer 0 ist, wird der entsprechende Pin auf
> Masse gelegt und das Signal wegoptimiert.

Die betreffenden Signale ändern ihren Zustand in der 
Behavorial-Simulation, sonst könnte die Schaltung auch nicht 
funktionieren.

Wie kann die Synthese dann fest stellen dass sie ihren Zustand nicht 
ändern?

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

Matze schrieb:
> Wie kann die Synthese dann fest stellen dass sie ihren Zustand nicht
> ändern?
Der Synthesizer bemängelt nicht, dass sie ihren Zustand nicht ändern, 
sondern, dass sie unbenutzt sind. Du kannst ein riesiges Design 
machen, aber wenn du keine Ausgänge hast, wird alles "wegoptimiert", 
denn egal was gemacht wird, aussen merkt es ja niemand, dass da was 
fehlt.

Matze schrieb:
> Ich habe ein an sich übersichtliches VDHL-Design, welches in der
> Behavorial-Simulation funktioniert.
Das sagt nicht viel. In der Simulation funktioniert sogar eine "wait for 
10 ms;" Anweisung tadellos.

> Dabei werden alle Signale zu Beginn mittels reset initialisiert und
> ihnen vielfach Werte zugewiesen.
Das sollte man mal mit eigenen Augen sehen. Oder andersrum: bisher hatte 
bei mir der Synthesizer mit solchen einfachen Behauptungen (...is 
unused...) immmer Recht...

Genauere Aussagen gibt es nur, wenn du die paar Quelldateien deines "an 
sich übersichtlichen" Desgins mal postest. So viele können das ja nicht 
sein.

[Bitwurschtler (Gast)]

Matze schrieb:
> Dussel schrieb:
>> Wenn du ein Signal hast, das immer 0 ist, wird der entsprechende Pin auf
>> Masse gelegt und das Signal wegoptimiert.
>
> Die betreffenden Signale ändern ihren Zustand in der
> Behavorial-Simulation, sonst könnte die Schaltung auch nicht
> funktionieren.
>
> Wie kann die Synthese dann fest stellen dass sie ihren Zustand nicht
> ändern?

Wenn ich dich recht verstehe stellt die Synthese garnicht fest das deren 
Zustand konstant ist, sondern das dieser Zustand nirgends benutzt wird, 
also der Ausgang des FF o.ä. nicht verdrahtet ist.

Mglw führen deine Register ja auf ein SPI modul was nicht angeschlossen 
nach draussen verdrahtet ist.

Wenn du eine alternative synthesetool verwenden kannst (XST) dann 
versuch das mal mit diesem.

Im Zusammenhang mit Chipscope irrt sich die Synthese gelegentlich 
bezüglich des unused, da das chipscope-modul im design ohne ausgänge 
erscheint, der JTAG-Port steckt nur in der Netzliste. Aber das scheint 
hier nicht der Fall zu sein.

Problem ähnlicher Art könnte man bei SOC-FPGA's wie Zynq erwarten, wenn 
Module genutzt werden die nicht im FPGA-Anteil realisiert sind sondern 
als Hardcore bspw. Peripherals.

MfG,

[Dussel (Gast)]

Lothar M. schrieb:
> Matze schrieb:
>> Wie kann die Synthese dann fest stellen dass sie ihren Zustand nicht
>> ändern?
> Der Synthesizer bemängelt nicht, dass sie ihren Zustand nicht ändern,
> sondern, dass sie unbenutzt sind. Du kannst ein riesiges Design
> machen, aber wenn du keine Ausgänge hast, wird alles "wegoptimiert",
> denn egal was gemacht wird, aussen merkt es ja niemand, dass da was
> fehlt.
Bei mir war damals das Problem, dass sich Signale wegen eines Fehlers 
nicht geändert haben. Deswegen wurde der entsprechende Ausgang auf einen 
festen Wert gelegt. Darauf hat der Synthesizer erkannt, dass der Ausgang 
auf einem festen Wert liegt und das entsprechende Signal unbenutzt ist 
und hat den ganzen Rest wegoptimiert. Da kam auch die Meldung mit dem 
unbenutzten Signal, aber die eigentliche Ursache war, dass das Signal 
konstant war.

Hier wurde ja das Signal auf einen Ausgang gelegt, wird aber trotzdem 
noch als unbenutzt wegoptimiert. Deshalb denke ich, dass hier der 
gleiche Fehler wie bei mir damals vorliegen könnte.

[Matze (Gast)]

Lothar M. schrieb:
> Das sollte man mal mit eigenen Augen sehen. Oder andersrum: bisher hatte
> bei mir der Synthesizer mit solchen einfachen Behauptungen (...is
> unused...) immmer Recht...

Ja, sollte man:
Hier mal der Quellcode des SPI-Empfängers:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use ieee.std_logic_unsigned.all;

entity QSPI_Analyzer_Input is
    Port (  
            SYS_CLK         : in STD_LOGIC;                             -- 100MHZ-Clk
            SCLK            : in STD_LOGIC;                             -- clk des SPI-Bus
            DATA            : in STD_LOGIC_VECTOR (3 downto 0);         -- Daten des SPI-Bus
            CS              : in STD_LOGIC;                             -- CS-Leitung des SPI-Bus
            reset           : in Std_logic;                             -- Reset des QSPI-Interface
            out_reg         : out STD_LOGIC_VECTOR (7 downto 0);        -- 1 SPI-Word
            wren_out_reg    : out STD_LOGIC);                            -- ausgabe fuer "Daten gueltig"           
end QSPI_Analyzer_Input;

architecture Behavioral of QSPI_Analyzer_Input is                       -- um Aus 4 Datenleitungen + cs (5 Bit) einen 15-Bit Register wert zu machen,                                                      
begin
    SHIFT_PROC: process(SCLK, CS,  DATA, SYS_CLK, reset)                   -- Abtastung mit SPI-Clk, auch Aktiv mit SC, Mode, DATA, timetick
    begin
    if reset = '0' then
        if CS = '0' then-- cs_active                                         -- Beginned wenn CS Aktiviert wurde           
            if (rising_edge(SCLK)) then                                 -- Abtasten bei falling_edge wenn cs ausgelöst wurde     
                wren_out_reg <= '1';                                -- Nun sind die Daten nicht mehr gültig
                out_reg(0)<=DATA(0);                                -- Parallele Abtastung der 5 Eingangssignale
                out_reg(1)<=DATA(1);
                out_reg(2)<=DATA(2);
                out_reg(3)<=DATA(3);
                out_reg(4)<=CS;
            end if;
        else                                                                -- solange der CS nicht aktiv ist
            wren_out_reg <= '0';
        end if;
    else
        out_reg          <= x"00";                                --: out STD_LOGIC_VECTOR (15 downto 0);       -- 3 SPI-Worte in 1 16-Bit-Wort, Bit 15 ist frei
        wren_out_reg     <= '0';                                    --: out STD_LOGIC;                            -- ausgabe fuer "Daten gueltig"
    end if;
    end process;

end Behavioral;

Dazu kommt folgendes Main:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use ieee.std_logic_unsigned.all;

entity Main is
    Port (  CLK100MHZ   : in std_logic;
            SDATA       : in std_logic_vector(3 downto 0);
            SCS_IBUF    : in std_logic;
            SCLK_pin    : in std_logic;
            LED         : out Std_logic_vector(15 downto 0);
            RESET_PIN_N : in std_logic;
            C           : out std_logic_vector(7 downto 0);
            AN          : out std_logic_vector(7 downto 0);
            LED16_B     : out std_logic);
end Main;

architecture Behavioral of Main is

component Seg_Disp
    Port (  clk : in STD_LOGIC;
            disp_data : in STD_LOGIC_VECTOR (39 downto 0);
            led_out : out STD_LOGIC_VECTOR (7 downto 0);
            an_out : out STD_LOGIC_VECTOR (7 downto 0));
end component;

component Timetick
    Port (  clk                 : in STD_LOGIC;                         -- Systemoszillator
            reset               : in std_logic;            
            Sys_time            : out std_logic_vector (63 downto 0));  -- Systemzeit
end component;

component QSPI_Analyzer_Input
    Port (  
            SYS_CLK         : in STD_LOGIC;                             -- 100MHZ-Clk
            SCLK            : in STD_LOGIC;                             -- clk des SPI-Bus
            DATA            : in STD_LOGIC_VECTOR (3 downto 0);         -- Daten des SPI-Bus
            CS              : in STD_LOGIC;                             -- CS-Leitung des SPI-Bus
            reset           : in Std_logic;                             -- Reset des QSPI-Interface
            out_reg         : out STD_LOGIC_VECTOR (7 downto 0);       -- 3 SPI-Worte in 1 16-Bit-Wort, Bit 15 ist frei
            wren_out_reg    : out STD_LOGIC);                            -- ausgabe fuer "Daten gueltig"
end component;

signal aout_reg          : STD_LOGIC_VECTOR (7 downto 0);       -- 3 SPI-Worte in 1 16-Bit-Wort, Bit 15 ist frei


attribute dont_touch : string;
attribute dont_touch of aout_reg : signal is "true";

signal wren_out_reg : std_logic;


signal adisp_data    : std_logic_vector(39 downto 0);
signal reset_qspi_analyzer_input : std_logic;

begin   

    P1: process(RESET_PIN_N, CLK100MHZ, SCLK_pin, SDATA, SCS_IBUF)
    begin                     
        LED16_B                         <= NOT RESET_PIN_N;
        reset_qspi_analyzer_input       <= NOT RESET_PIN_N;
        if rising_edge(CLK100MHZ) then
            --disp_data(7 downto 0)       <= disp_data(7 downto 0) + '1';
            --disp_data(39 downto 8)       <= disp_data(39 downto 8) + '1';
            adisp_data(7 downto 0)     <= aout_reg;
            adisp_data(39 downto 8)    <= x"00000000";
            LED(7 downto 0)             <= aout_reg;
        end if;
    end Process;

    G1_1: QSPI_Analyzer_Input Port map (
            SYS_CLK           => CLK100MHZ,                 --!!! wird im Moment nicht benötigt
            SCLK              => SCLK_pin,                      --: in STD_LOGIC;                         -- clk des SPI-Bus
            DATA              => SDATA,                     --: in STD_LOGIC_VECTOR (3 downto 0);         -- Daten des SPI-Bus
            CS                => SCS_IBUF,                       --: in STD_LOGIC;                        -- CS-Leitung des SPI-Bus
            reset             => reset_qspi_analyzer_input, --: in Std_logic;                             -- Reset des QSPI-Interface
            out_reg           => aout_reg,                   --: out STD_LOGIC_VECTOR (15 downto 0);       -- 3 SPI-Worte in 1 16-Bit-Wort, Bit 15 ist frei
            wren_out_reg      => wren_out_reg);              --: out STD_LOGIC;                            -- ausgabe fuer "Daten gueltig"

    Disp: Seg_Disp Port map 
    (       clk             => CLK100MHZ,           --: in STD_LOGIC;
            disp_data       => adisp_data,
            led_out         => C,                    --: out STD_LOGIC_VECTOR (7 downto 0);
            an_out          => AN);                 --: out STD_LOGIC_VECTOR (7 downto 0));

end Behavioral;

Somit sollen die Daten wenn kein Reset anliegt, und der CS auf '0' ist 
sowohl auf die LED's als auch auf der 7-Seg-Anzeige ausgegeben werden.

Problem ist, dass die Fehlermeldung

[Synth 8-3332] Sequential element (\adisp_data_reg[0] ) is unused and will be removed from module Main.

für alle 8-Bits [0..7] des 7-Segment-Decoders erscheint.
Nicht jedoch für die LED's welche dann aber eigentlich auch "UNUSED" 
sein müssten.

Wird z.b. ein Counter auf die 7-Segment-Anzeige ausgegeben, dann treten 
die Warnungen nicht auf:

            disp_data(7 downto 0)       <= disp_data(7 downto 0) + '1';
            disp_data(39 downto 8)       <= disp_data(39 downto 8) + '1';
            --adisp_data(7 downto 0)     <= aout_reg;
            --adisp_data(39 downto 8)    <= x"00000000";

Wie kann es also sein, dass "aout_reg" für die LED's "used" ist, bei 
Anzeige auf 7-Segment jedoch keine zustandsänderung erfolgen soll?

Wiederspricht sich dass nicht?

[Achim S. (Gast)]

Matze schrieb:
> Problem ist, dass die Fehlermeldung[Synth 8-3332] Sequential element
> (\adisp_data_reg[0] ) is unused and will be removed from module Main.
> für alle 8-Bits [0..7] des 7-Segment-Decoders erscheint.
> Nicht jedoch für die LED's welche dann aber eigentlich auch "UNUSED"
> sein müssten.

erst mal zur Begriffsklärung: deine Ausgänge "LED" hängen nicht von 
adisp_data ab sondern nur von areg. Wenn DispData auf etwas einen 
Einfluss haben sollte, dann auf die Ausgänge "C".

Ob Dispdata einen wirklichen Einfluss auf C hat sieht man nicht, weil 
das in der nicht gezeigten Komponente Seg_Disp festgelegt wird. Also: 
wie sieht Seg_Disp intern aus? Bei den Warnings sind Bits 39..4 von 
disp_data immer auf 0, beim Beispiel mit dem Counter ist das nicht der 
Fall. Macht das den Unterschied für Seg_Disp?

Noch eine Anmerkung zu deiner SPI-Komponente: deine Beschreibung mit 
rising_edge(sclk) ist unsauber (gibt es hierzu keine Warnings? Evtl. 
steckt schon hier der Grund für deine Warnung bei disp_data). Nutze 
lieber die 100MHz-Clock um sauber mit getakteten FlipFlops zu arbeiten, 
und machen an SCLK eine Flankenerkennung, wann die Werte von Data 
übernommen werden sollen.

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

Achim S. schrieb:
> deine Beschreibung mit rising_edge(sclk) ist unsauber (gibt es hierzu
> keine Warnings?
Ich würde hier wenigstens eine Meldung in Richtung "this is no good 
design practice" erwarten.
Man kann das mit dem lokalen Takt schon so machen. Allerdings sollte man 
sich dann ausführlich Gedanken zur Übergabe der Daten an die 100MHz 
Clock-Domäne machen.

Wenn im vorigen Absatz zu viele unbekannte Worte waren, dann empfehle 
ich streng synchrones Design (im gesamten Design nur 1 einziger Takt: 
der Oszillatortakt), wo alle externen Eingänge (auch die, die einen 
Namensteil "-clock" haben) einfach erst mal einsynchronisiert werden.

[Achim S. (Gast)]

Lothar M. schrieb:
> Man kann das mit dem lokalen Takt schon so machen. Allerdings sollte man
> sich dann ausführlich Gedanken zur Übergabe der Daten an die 100MHz
> Clock-Domäne machen.

Ist in diesem Fall imho noch etwas problematischer, weil das 
"rising_edge(sclk)" innerhalb eines geschachtelten if-then-else steht 
(ein äußeres Konstrukt für den asynchronen Reset, aber drunter noch eine 
Abfrage für das CS und erst abhängig davon kommt das rising_edge). Ich 
bin mir nicht sicher, ob die geschachtelten if-then-else in die 
Generierung eines Reset-Signals zusammengefasst werden können (für 
wren_out ein Reset abhängig vom externen Signal Reset, für outreg ein 
Reset abhängig von den externen Signalen Reset und CS).

Wenn das nicht passiert, macht er mit SCLK hier nicht nur eine zweite 
Taktdomäne auf, sondern es wird noch verwickelter.

[Matze (Gast)]

Danke für eure bisherigen Ratschläge ;)

Achim S. schrieb:
> Ob Dispdata einen wirklichen Einfluss auf C hat sieht man nicht, weil
> das in der nicht gezeigten Komponente Seg_Disp festgelegt wird. Also:
> wie sieht Seg_Disp intern aus?

Hier ist es, ein gewöhnlicher Multiplexer für 7Segment-Anzeigen:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use ieee.std_logic_unsigned.all;

entity Seg_Disp is
    Port (  clk : in STD_LOGIC;
            disp_data : in STD_LOGIC_VECTOR (39 downto 0);
            led_out : out STD_LOGIC_VECTOR (7 downto 0);
            an_out : out STD_LOGIC_VECTOR (7 downto 0));
end Seg_Disp;

architecture Behavioral of Seg_Disp is
signal count : std_logic_vector (19 downto 0); 


component Bcd_Dec 
    Port (  hex : in STD_LOGIC_VECTOR (3 downto 0);
            bcd : out STD_LOGIC_VECTOR (7 downto 0));
end component;
signal hex : std_logic_vector (3 downto 0);
signal bcd : std_logic_vector (7 downto 0);
begin

Seg_Disp: process(clk)
variable count_disp : integer;
begin

    if (rising_edge(clk)) then
        count <= count + 1;
        if count = x"20000" then
            count <= x"00000";
                case count_disp is
                    when 0 => 
                        count_disp := count_disp + 1;
                        an_out <= "01111111";
                        hex <= disp_data (3 downto 0);
                        led_out(6 downto 0) <= bcd(6 downto 0);
                        led_out(7) <= not disp_data(39);
                    when 1 =>
                        count_disp := count_disp + 1;
                        an_out <= "11111110";
                        hex <= disp_data (7 downto 4);
                        led_out(6 downto 0) <= bcd(6 downto 0);
                        led_out(7) <= not disp_data(32);
                    when 2 =>
                        count_disp := count_disp + 1;
                        an_out <= "11111101";
                        hex <= disp_data (11 downto 8);
                        led_out(6 downto 0) <= bcd(6 downto 0);
                        led_out(7) <=  not disp_data(33);
                    when 3 =>
                        count_disp := count_disp + 1;
                        an_out <= "11111011";
                        hex <= disp_data (15 downto 12);
                        led_out(6 downto 0) <= bcd(6 downto 0);
                        led_out(7) <= not disp_data(34);
                    when 4 =>
                        count_disp := count_disp + 1;
                        an_out <= "11110111";
                        hex <= disp_data (19 downto 16);
                        led_out(6 downto 0) <= bcd(6 downto 0);
                        led_out(7) <= not disp_data(35);
                    when 5 =>
                        count_disp := count_disp + 1;
                        an_out <= "11101111";
                        hex <= disp_data (23 downto 20);
                        led_out(6 downto 0) <= bcd(6 downto 0);
                        led_out(7) <= not disp_data(36);
                    when 6 =>
                        count_disp := count_disp + 1;
                        an_out <= "11011111";
                        hex <= disp_data (27 downto 24);
                        led_out(6 downto 0) <= bcd(6 downto 0);
                        led_out(7) <= not disp_data(37);
                    when 7 =>
                        count_disp := count_disp + 1;
                        an_out <= "10111111";
                        hex <= disp_data (31 downto 28);
                        led_out(6 downto 0) <= bcd(6 downto 0);
                        led_out(7) <= not disp_data(38);
                        count_disp := 0;
                    when others => an_out <= "11111111";
                end case;
        end if;
    end if;
end process;

G1_Bcd_Dec: Bcd_Dec port map (hex,bcd);
                
end Behavioral;

Er benutzt diesen BCD-Decoder:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

entity Bcd_Dec is
    Port ( hex : in STD_LOGIC_VECTOR (3 downto 0);
           bcd : out STD_LOGIC_VECTOR (7 downto 0));
end Bcd_Dec;

architecture Behavioral of Bcd_Dec is
begin
BCD_Proc: Process (hex)
begin
    case hex is
    when "0000" => bcd <= "01000000"; --0
        when "0001" => bcd <= "01111001"; --1
        when "0010" => bcd <= "00100100"; --2
        when "0011" => bcd <= "00110000"; --3
        when "0100" => bcd <= "00011001"; --4
        when "0101" => bcd <= "00010010"; --5
        when "0110" => bcd <= "00000011"; --6
        when "0111" => bcd <= "01111000"; --7
        when "1000" => bcd <= "00000000"; --8
        when "1001" => bcd <= "00011000"; --9
        when "1010" => bcd <= "00001000"; --A --> "01110111"
        when "1011" => bcd <= "00000011"; --B --> "01111100"
        when "1100" => bcd <= "01000110"; --C --> "00111001"
        when "1101" => bcd <= "00100001"; --D --> "01011110"
        when "1110" => bcd <= "00000110"; --E --> "01111001"
        when "1111" => bcd <= "00001110"; --F --> "01110001"
        when others => bcd <= "00000000";
    end case;
end process;
end Behavioral;

Achim S. schrieb:
> Also:
> wie sieht Seg_Disp intern aus? Bei den Warnings sind Bits 39..4 von
> disp_data immer auf 0, beim Beispiel mit dem Counter ist das nicht der
> Fall. Macht das den Unterschied für Seg_Disp?

Tatsächlich, mann müsste erwarten dass die Bits 4..39 immer auf 0 sind 
und deshalb unused und ab 8 auch undriven sind. Allerdings kommt die 
Meldung unused für die Bits 0..7, lediglich für die Bits 8..39 gibt es:
[Synth 8-3295] tying undriven pin Disp:disp_data[37] to constant 0

Wobei das undriven nachvollziebar ist, das unused von 0..3 finde ich 
nicht nachvollziehbar.

Achim S. schrieb:
> Nutze
> lieber die 100MHz-Clock um sauber mit getakteten FlipFlops zu arbeiten,
> und machen an SCLK eine Flankenerkennung, wann die Werte von Data
> übernommen werden sollen.

Wie meinst du dass?
Ich möchte nur Daten übernehmen, wenn die der CLK sich sinvoll ändert. 
Darüber geben die 100MHZ je keine Information. Auch wünsche ich mir 
keine "Überabtastung" mit hoher Frequenz und meist den selben Werten. 
Deshalb gibt es an SCLK, welches ein CLK-Eingang ist, eine 
Pflankenerkennung.

Mein langfristiges Ziel ist die aufgenommenen Daten in ein FIFO zu 
schreiben. So hätte ich alles vor dem FIFO mit SCLK eingetacktet und die 
daten mit 100MHZ herausgeholt.

Warnings gibt es deshalb keine.

Lothar M. schrieb:
> Man kann das mit dem lokalen Takt schon so machen. Allerdings sollte man
> sich dann ausführlich Gedanken zur Übergabe der Daten an die 100MHz
> Clock-Domäne machen.

Die Übergabe soll letztendlich über einen FIFO passieren.
So sollte es doch keine Probleme geben?

Achim S. schrieb:
> Ist in diesem Fall imho noch etwas problematischer, weil das
> "rising_edge(sclk)" innerhalb eines geschachtelten if-then-else steht
> (ein äußeres Konstrukt für den asynchronen Reset, aber drunter noch eine
> Abfrage für das CS und erst abhängig davon kommt das rising_edge). Ich
> bin mir nicht sicher, ob die geschachtelten if-then-else in die
> Generierung eines Reset-Signals zusammengefasst werden können (für
> wren_out ein Reset abhängig vom externen Signal Reset, für outreg ein
> Reset abhängig von den externen Signalen Reset und CS).
>
> Wenn das nicht passiert, macht er mit SCLK hier nicht nur eine zweite
> Taktdomäne auf, sondern es wird noch verwickelter.

Dass dachte ich auch schon.
Würde gerne weniger Abfragen von Signalen mit rising_edge's quasi 
&-Verknüpft haben wollen.

Aber wie wird so etwas 'vereinfacht'?

[Achim S. (Gast)]

Matze schrieb:
> Mein langfristiges Ziel ist die aufgenommenen Daten in ein FIFO zu
> schreiben. So hätte ich alles vor dem FIFO mit SCLK eingetacktet und die
> daten mit 100MHZ herausgeholt.

ok, kannst du machen (wenn SCLK auf einen CLK-Eingang geht und wenn du 
auf das Framing mit CS verzichten willst - denn du wirst ggf. nur 
SCLK-Flanken bekommen, während CS low ist, und den Anfang/das Ende eines 
Frames nicht erkennen können).

Ich hatte Bedenken, dass das geschaltete if-then-else um die rising_edge 
Abfrage nicht zu einem Reset aufgelöst wird. Aber die Bedenken haben 
sich zerstreut, als ich eben deinen SPI-Code in Vivado eingegeben und 
mir das Synthese-Ergebnis angeschaut habe (siehe Anhang). Die 
geschachtelte if-then-else wird tatsächlich in eine Kombinatorik zur 
Erzeugung eines Resets aufgelöst, du hast also eine "saubere" zweite 
Taktdomäne.

Matze schrieb:
> Dass dachte ich auch schon.
> Würde gerne weniger Abfragen von Signalen mit rising_edge's quasi
> &-Verknüpft haben wollen.
>
> Aber wie wird so etwas 'vereinfacht'?

indem du alles mit SYSCLK taktest und eine Flankenerkennung auf SCLK 
machst, die das Abspeichern der Eingänge steuert.
http://www.lothar-miller.de/s9y/categories/18-Flankenerkennung

Matze schrieb:
> Hier ist es, ein gewöhnlicher Multiplexer für 7Segment-Anzeigen:

Tja, dem sehe ich auf die Schnelle ehrlich gesagt auch nicht an, wieso 
LED_out dieser Komponente / C des topmoduls nicht mit echten Daten 
getrieben werden sollten. Vielleicht kannst du dich ja mal durch die 
Ergebnisse deiner Synthese durcharbeiten (z.B. per schematic view) um zu 
sehen, wer laut Syntheseergebnis C treibt.

[Achim S. (Gast)]

ok, ich denke jetzt hab ich den Grund für die Warnung gefunden.

adisp_out(3..0) und led_out(3..0) sind genau die identischen Daten. Es 
gibt keinen Grund, zwei identische Kopien unter zwei verschiedenen Namen 
zu führen. Deswegen wird adisp_out(3..0) wegoptimiert.

adisp_out(39..4) ist konstant 0 und braucht deswegen auch keine eigenen 
Flipflops.