Suchergebnisse für "sensitivity list unvollständige"

Sensitivity List Problem bei GENERATE-Konstrukten

Die option "check for Synthesis" liefert bei ModelSIM AE folgenden Fehler: "Signal ctrl_we is not in the s.-list" - obwohl es geclocked ist. Kann es an dem Generate Konstukt liegen? Der Code stammt vom open cores SPDIF Decoder. [c] -- control register generation CTRLREG : for k in ctrl_din'range generate -- active bits can be written to ACTIVE : if ACTIVE_BIT_MASK(k) = '1' generate CBIT : process (clk, rst) begin if rst = '1' then ctrl_internal(k) <= '0'; else if rising_edge(clk) then

FPGA, VHDL & Co. ·Frager ·23.04.2009 12:24 ·12 Antworten

warning beim Implementieren einer State Machine

z_speicher; : : [/vhdl] Die Simulation deines Codes funktioniert (scheinbar), weil die Sensitivity-List unvollständig ist. Auch ein gern gemachter Fehler bei der Mehrprozess-Schreibweise: [vhdl] ue_sn: process( RxData, zustand ) [/vhdl] Richtig wäre: [vhdl] ue_sn: process( RxData, zustand

aktiviert wird und in diesem Zustand so schnell wie möglich hochgezählt wird. Auf diese Art (unvollständige Sensitivity-List) sieht zwar die Simulation richtig aus, die real implementierte Hardware verhält sich anders :-o

FPGA, VHDL & Co. ·befro ·18.03.2009 18:34 ·11 Antworten

Bidirektional in_out

falsch zu sein, so wirst du ungewollt irgend ein latch einbauen, weil hilfe und b nicht in der sensitivity-list stehen. Zudem hast du das problem das du nie den Wert 'Z' auf den Ausgang zuweist. 'Z' ist ja bekanntlich high-Impedanz process (a, b, c) begin if a = '0' then b <= 'Z' c <

klar und deutlich. Das Latch wird aber nicht eingebaut... > ...weil hilfe und b nicht in der sensitivity-list stehen. Die Sensitivity-List wird *nur* von der /Simulation/ verwendet. Falls die /Synthese/ auf eine unvollständige Liste trifft, wird sie dir lediglich ein paar Warnungen servieren.

FPGA, VHDL & Co. ·Gast ·22.02.2009 12:40 ·7 Antworten

MUX mit bidirektionalem Pin

: auch fehlt irgendwie die Zuweisung von Y nach B in deinem Code. Und das READ Signal in den Sensitivity Liste benötigst Du in Deinem Beispiel auch nicht. Aber ausprobieren und Fragen sind schonmal der beste Weg zum Erfolg! Der Besucher

> Und das READ Signal in den Sensitivity Liste benötigst Du in Deinem > Beispiel auch nicht. Richtig, zuviel vom Falschen drin: unvollständige Sensitivity-Liste [vhdl] MUX_PROCESS : process(SEL, READ, A, B, Y) begin if DIR

FPGA, VHDL & Co. ·Manuel F. ·11.02.2009 10:49 ·11 Antworten

RTL: "wait until rising_edge" oder "if rising_edge"

gespart wird > - die Simulation und die Synthese stimmen immer überein, > weil es keine unvollständigen Sensitivity-Listen mehr gibt > - der Prozess ist garantiert getaktet, > und hat nicht irgendwo einen asynchronen Teil > Und wieso sollte man etwas nicht verwenden, wenn es Vorteile bringt

> Bei der Beschreibungsform 2 hat man den (fragwürdigen) Vorteil, > dass man die sensitivity list nicht zu schreiben braucht. Ich würde gerade diesen Vorteil nicht in Frage stellen. Man muß sich nur mal in den hier (im Forum) geposteten Quellen die überdefinierten oder unvollständigen

FPGA, VHDL & Co. ·Matthias G. ·10.02.2009 11:12 ·16 Antworten

Wie zwei Taktsignale in einem Prozess verarbeiten?

warten [/vhdl] sorgt dafür, dass das Genze garantiert ein synchrones Design wird. Sie ersetzt die Sensitivity-List komplett, und deshalb kann es auch keine unvollständige Sens-List mehr geben.

FPGA, VHDL & Co. ·Peterchen ·28.01.2009 12:04 ·22 Antworten

4-Bit CPU in VHDL - Synchronisationsproblem

Hi Lothar, ich danke dir für deine Hilfe, vorallem für die Tips bzgl. Sensitivity-Lists. Das Latch habe ich dann auch erkannt (bzw. das Xilinx Tool hat es mir im Report gemeldet), als ich eine Timing-Simulation durchführen wollte. Allerdings durchschaue ich noch nicht, wieso

Concurrent machen muss. Was ist so schlecht an einem eigenen Prozess (einmal abgesehen von meiner unvollständigen Sens-List ;-))? Viele Grüsse, F. P.S: Das Delay von einem halben Takt kam in der Testbench auf. Der Reset war zur fallenden Clk-Flanke beendet, und sofort startete das MemEn...

FPGA, VHDL & Co. ·Felix ·18.12.2008 09:43 ·8 Antworten

Vergleich von 2 code Varianten

beides in der Simulation dasselbe Verhalten zeigt. Übrigens wenn ich next_state nicht in der sensitivity list vom process B eintragen würde, sollte es an der Simulation auch nichts ändern. Man liest ja in Büchern immer, dass alle gelesenen Signale in die sensitivity list gehören, damit die kombinatorische

> Übrigens wenn ich next_state nicht in der sensitivity list vom > process B eintragen würde, sollte es an der Simulation auch nichts > ändern. Man liest ja in Büchern immer, dass alle gelesenen Signale > in die sensitivity list gehören, damit die

FPGA, VHDL & Co. ·Martin ·06.12.2008 15:16 ·7 Antworten

Variable vs Signal

Ersetzen der Variable durch ein Signal wird schon mal die Sens-List vergessen. In der Hardware werden beide Prozesse (abgesehen von einer Warnung wegen der unvollständigen Sens-List) sowieso identisch realisiert (Bild). Korrekt müsste die Sens-List vom proc2 so

Ich hab solche Prozesse mit was anderem als das Taktsignal in der Sensitivity-List eigentlich überhaupt ... Mach ich irgendwas falsch? Grüße thomas

FPGA, VHDL & Co. ·thomas ·26.07.2020 14:25 ·30 Antworten

State Machine Zähler-Problem

keine Kombinatorik. Und FFs sind getaktet. Das geht in der Simulation nur durch, weil deine Sensitivity-Liste unvollständig ist. [vhdl] process(state,c) <<< Kombinatorik, hier fehlt c begin case state is when state0=> --Grundzustand c<= 0; -- c zurücksetzen next_state <=

FPGA, VHDL & Co. ·Julian ·21.08.2008 17:10 ·3 Antworten

Flipflop und Latch

aber als T-Latch _synthetisiert_, zusammen mit einer dezenten Warnung: da fehle ein Signal in der Sensitivity-List und es werde ein Latch eingebaut. Das ist ein gern gemachter Fehler.

Kombinatorik im Prozess, keine Defaultzuweisung (else... bzw. when others...) --> Latch Eine unvollständige Sensitivity-Liste dazu, und das Ganze verhält sich in der Simulation grundlegend anders als in der Realität.

FPGA, VHDL & Co. ·Christian H. ·13.08.2008 14:49 ·26 Antworten

FSM springt nicht in nächsten Status

Richtig, nur CLK in die Liste. Die sensitivity-list eines process ist _nur_ für die Simulation interessant. Wenn sich der Zustand eines der Signale in der Liste ändert, wird die Simulation neu berechnet. Die Synthese legt mit einer unvollständigen Liste ein paar Warnungen vor, macht aber sonst alles richtig (fügt die Signale selbständig ein). Und in dem von mir beschriebenen getakteten Prozess kann sich nur was ändern, wenn sich CLK

FPGA, VHDL & Co. ·Richard B. ·05.07.2008 17:30 ·14 Antworten

Problem: Latches oder unkorrektes Verhalten

definieren. Den Begriff "Anfangswert" sollte mn nicht verwenden. > Zusätzliche Signale in der Sensitivity List sollten das Ergebnis der > Simulation nicht ändern. Doch! Definiere einen Zähler als Variable, die mit +1 hochzählt. Nimm in die sensitivity-Liste einen x-beliebigen Takt und der Zähler

, da kannst du in die Sensitivity List so viele überflüssige Signale reinschreiben wie du willst, es wird weder an der Simulation noch an der Synthese etwas ändern.

FPGA, VHDL & Co. ·Screamapilla ·18.12.2007 20:28 ·23 Antworten

Frage zu VHDL Code

if Konstrukt heisst üblicherweise process heisst sensitivity list. Ist die unvollständig? sind die signale in der list gesetzt? Also dein codeschnipsel ist OK, der Fehler liegt in den anderen zeilen. [vhdl] process(clk_i,rst_i) --sensetiivizy list (Takt, async. reset) if rst_i = '1' then --synchroner reset stat_reg(4)<='0' elsif rising_edge(clk_i) then --dein code if XA_4 = '1' then stat_reg(4)<='1'; else stat_reg(4

FPGA, VHDL & Co. ·Martin ·30.08.2007 14:04 ·5 Antworten

Ausgabe an LED's

leider schon schmerzlich selber feststellen, dass dem so ist. Der Code stimmte, allerdings war die Sensitivity-List unvollständig und nach der Implementierung auf die Zielhardware traten immer wieder äusserst seltsame Fehler auf, die dann verschwanden, sobald die Sensititivty-Liste vollständig beschrieben

>schon schmerzlich selber feststellen, dass dem so ist. >Der Code stimmte, allerdings war die Sensitivity-List unvollständig und Says who? >nach der Implementierung auf die Zielhardware traten immer wieder >äusserst seltsame Fehler auf, die dann verschwanden, sobald die >Sensititivty-Liste vollständig

FPGA, VHDL & Co. ·jojo ·22.02.2007 09:38 ·64 Antworten

GHDL Problem

Wie oben schon mal angefragt: Vlt. eine unvollstaendige sensitivity Liste? Daraus resultierend ein Latch?

berndl schrieb im Beitrag #2488740: > Wie oben schon mal angefragt: Vlt. eine unvollstaendige sensitivity > Liste? Daraus resultierend ein Latch? Meist läuft es in der Hardware, doch für den Simulator sind die sensitiv Listen ganz wichtig. Doch hier ist es anders herum im Simulator

FPGA, VHDL & Co. ·BadHorst ·09.01.2012 08:25 ·31 Antworten

Do's und Do Not's

kombinatorische. Erstere brauchen nur den Takt und ein evtl. vorhandenes asynchrones reset in der Sensitivity List, der Rest ist vollkommen egal und korrekt! Kombinatorische Prozesse brauchen natürlich alle Eingangsvariablen in der Sensitivity List, sonst gibts böse Simulationsfehler !!! (IIRC, Modelsim

in die Sensitivity List eintragen (während der Synthese). MfG Falk

FPGA, VHDL & Co. ·TheMason ·08.12.2006 16:22 ·12 Antworten

System interner Reset

Klammerebene gespart wird - die Simulation und die Synthese stimmen immer überein, weil es keine unvollständigen Sensitivity-Listen mehr gibt - der Prozess ist garantiert getaktet, und hat nicht irgendwo einen asynchronen Teil Und wieso sollte man etwas nicht verwenden, wenn es Vorteile bringt?

FPGA, VHDL & Co. ·Paul Jensen ·05.02.2009 10:16 ·25 Antworten

Fehler Meldung

Erkennen bestimmter VHDL-Konstrukte. Deshalb kann man auch nicht sagen, daß die Synthese die sensitivity list ignoriert. Die sensitivity list dient dem Compiler dazu, diese Konstrukte zu erkennen, weil es z.B. der Unterschied zwischen Latch und FF sein kann, ob ein Signal in der sensitivity list steht

oder nicht. Leider sind manche Compiler zu schlau, und erkennen bestimmte Strukturen obwohl die sensitivity list nicht korrekt angeben ist. Davon entsteht dann die Meinung, daß die sensitivity list bei der Synthese ignoriert wird. Deshalb hat Du, Xenu nicht recht. Der Synthesizer ist kein Simulator

FPGA, VHDL & Co. ·Absolut Beginner ·07.06.2006 10:25 ·21 Antworten

Verständnisprobleme synchron, asynchron

o.ä.? Ich kenne eins (allerdings ein älteres, 1996 oder 98), wo ein ganzes Kapitel dem Thema "unvollständige Sensitivity Liste" gewidmet ist, "Abstrakte Modellierung digitaler Schaltungen" von ten Hagen. Weiss nicht, ob eine neue Auflage erschienen ist, vielleicht hat sich inzwischen was geändert...

Eine korrekte Sensitivity List ist wichtig, und wenn man VHDL programmiert sollte man sich auch bemühen zu verstehen was passiert. Daß sich einige Synthese-Werkzeuge mit falschen oder unvollständigen Listen abfinden

FPGA, VHDL & Co. ·Martin ·27.02.2006 19:53 ·61 Antworten