-
Thread
InOut Port Problem
www.lothar-miller.de/s9y/archives/42-Kombinatorische-Schleifen.html Und zudem steht in der Sensitivliste der CLK, der wird aber nirgends verwendet, ist also unnötig und darf da nicht rein. Dafür fehlt der counter_sample, und deshalb sieht die Simulation sogar noch "brauchbar" aus, auch wenn der Zähler
-
Thread
STD_LOGIC_VECTOR --> 7 SEGMENT DISPLAY
end process; [/vhdl] Das funktioniert nur in der Simulation. Und die ist falsch, weil die Sensitivliste falsch ist...
und das umgedrehte A u.a. vor. Lothar Miller schrieb im Beitrag #2814518: > weil die > Sensitivliste falsch ist... das stimmt. Jedoch funktioniert es jetzt folgendermaßen soweit: [vhdl] process(clk) begin if rising_edge(clk) then --if (counter = 999999) then if (counter = 99999
-
Thread
zwischen zwei clocks umschalten
unterschiedlichen Syntaxelementen) nichts anderes als ein Prozess ohne (bzw. mit impliziter) Sensitivliste. Das hier ist beide Male funktionell genau gleich und wird auch genau gleich in Hardware umgesetzt: [vhdl] -- mit Prozess process (a,b) begin z <= a+b; end ptorcess; -- nebenläufige
-
Thread
Modelsim asynchroner Process.
sich der simulator in deltazykles... Und sogar eine Concurrent-Zuweisung hat eine (implizite) Sensitivliste: nur wenn sich eines der betroffenen Signale ändert, wird die Zuweisung neu berechnet.
-
Thread
Fehler bei der Synthese
im Normalfall das das IF nur bei Flanken > von osc_int (osc_int'event) ausgewertet wird. Die Sensitivliste interessiert allerdings *allein und ausschliesslich* nur den Simulator. Die Beschreibung würde also sogar /augenscheinlich/ richtig simuliert, nur eben einfach nicht synthetisiert werden...
-
Thread
rsing_edge Problem
[/vhdl] Wie sollte denn bitteschön das Bauteil aussehen, das sowas kann? BTW: zudem ist die Sensitivliste unvollständig, da würde cnt fehlen :-/ Probiers so: [vhdl] process(value) begin if rising_edge(value) then if (cnt = 98) then cnt <= (others
-
Thread
Freitag: Umgang mit Warnungen
kommt. Das gilt übrigens für alle Meldungen, auch wenn z.B. "nur" die /Info/ kommt, dass die Sensitivliste nicht vollständig und deshalb die Simulation falsch ist...
-
Thread
VHDL: Definieren von unbenutzten Ports
#2214680: > ein einem prozess Das war auch mein erster Gedanke, das lästige daran ist aber die Sensitivliste, die unbedingt passen muß, weil sonst die Simulation falsch ist...
-
Thread
Sensitvity-Liste angeblich unvollständig
damit. Die Zeile ist halt nicht im getakteten Prozess und deshalb muss "value" auch in die Sensitivliste. Gruss Guter Programmierstil
-
Thread
Denkfehler beim Einsatz von Variablen?
eine Zuweisung an die Variable B nötig macht. Blöderweise kann man aber keine Variablen in eine Sensitivliste eintragen. Aber halb so schlimm: das passiert anderen auch... http://www.mikrocontroller.net/topic/117630#1057329
-
Thread
Addition und Subtraktion
www.mikrocontroller.net/topic/161722 Wozu die beiden Prozesse? Du kannst die Operationen auch ganz ohne Sensitivliste einfach so concurrent hinschreiben. [vhdl] doutm <= (others => '0'); din_alt <= (others => '0'); dIn_temp <= dIn - dOutm & '0'; dIn_neu <= dIn_temp + dIn_alt; [/vhdl] Das ist
-
Thread
wait until synthetisierbar
zu interpretieren. Das ist allemal intuitiver als den Takt in die /implizite/ "Warteliste" (=Sensitivliste) aufzunehmen und danach nur die steigende Flanke abzufragen.
-
Thread
Ultraschallentfernungsmessung mit FPGA
Soweit ein guter Anfang. Aber ein paar Verbesserungsvorschläge häte ich doch noch... ;-) Die Sensitivliste ist überbestimmt: [vhdl] --Zähler1: Zählprozess process ( clk, clk2) --Timer wird auf 5mm Weg/Periode gesetzt [/vhdl] Der Prozess /Zähler1/ ist nur auf clk sensitiv. Grundsätzlich
-
Thread
Verständnisproblem: Variablen in Prozessen
vhdl] TEMP_IN <= CIN & BI & AI; case TEMP_IN is ... [/vhdl] und TEMP_IN in dei Sensitivliste aufnehmen. Insgesamt ist das Beispiel so unnötig kompliziert an den Haaren durch die Brust gezogen... :-/ BTW: Ein "normaler" Mensch würde TEMP_IN weglassen und schreiben: [vhdl]
-
Thread
Zähler bei jedem event erhöhen
> allerdings möchte er bei einem process immer ein wait drin haben. Oder ein Element in der Sensitivliste des Prozesses... Aber bleib besser beim wait, dann ist dein Design garantiert synchron. Siehe dazu http://www.lothar-miller.de/s9y/archives/16-Takt-im-Prozess.html > ah ja ich habe doch noch
-
Thread
Volladdierer, Probleme mir Simulation
alten Wert von temp für seine Berechnungen. Ein klarer Fall einer falschen, unvollständigen Sensitivliste :-o Am einfachsten wäre eine Verkettung im Prozess: [vhdl] Volladdierer : process (X,Y,Cin) begin case X & Y & Cin is -- Verkettung der Eingangssignale zu einem Vektor
-
Thread
SPI Slave, Problem mit Latches
vor Latches. Das ist keine Funktion. Und da gibt es auch kein Latch. Und es ist zuviel in der Sensitivliste. Und in der ersten if-Abfrage sind 4 Klammern zuviel... > die Warnung vor Latches. Welche Signale werden denn angemahnt? > Spi_MISO_Out <= SPI_Data_MISO(31) when SPI_EN='1' else '0'; Sollte
-
Thread
Paritätsgenerator mit While-Schleife
Quelltext! > Edit: Mit der Wait-until Anweisung funktioniert es auch :) Klar: man kann nicht eine Sensitivliste und (eines oder mehrere) /wait/ in einem Prozess verwenden! > Edit: Mit der Wait-until Anweisung funktioniert es auch :) In meinem Exemplar vom Buch steht handschriftlich von mir reingeschrieben
-
Thread
ISE 13.1 - VHDL 2008?
) statement braucht also eigentlich /ausschliesslich/ der Simulator. Weil ja auch nur der die Sensitivliste /überhaupt/ braucht... Und was viel schlimmer ist: mit diesem process (all) muss sich keiner mehr fragen, ob ein bestimmtes Signal überhaupt (funktional) in den Prozess gehört. Oder wenn das
-
Thread
Concurrent Execution?
natürlich mehrere Zeilenümbrüche haben kann, aber nur einen Strichpunkt), der zum Speichersparen ohne Sensitivliste geschrieben werden kann. Eine nebenläufige Zuweisung wie [vhdl] a <= b; [/vhdl] könnte exakt funktionsgleich (Simulation und Hardware) auch so geschrieben werden [vhdl] process
-
Thread
VHDL erste Schritte beim Zähler
Prozessteils und damit kombinatorisch zugewiesen. Um das korrekt abzuhandeln fehlt aber cnt in der Sensitivliste(!!!*). Deshalb wird die Simulation /nicht/ zur Realität passen. (*) tut mir leid, dass ich da so viele Ausrufezeichen mache, aber das ist echt böse. Wenn man sich so einen Stil angewöhnt,
-
Thread
keine Variablen - case anweisung
kombinatorischer oder ein getakteter Prozess? Im ersteren Fall müsste dann einfach das Signal C in die Sensitivliste, im zweiten Fall wäre das Signal C dann sowieso ein Speicherelement mit der resultierenden Latency. Kurz: für eine zuverlässige Aussage zum Verhalten der Beschreibung fehlt noch ein wenig Drumherum
-
Thread
Syntaxfehler bei Simulation, kein Syntaxfehler bei Synthese
Und im Resetzustand SS='1' kann sich Din direkt auf das Schieberegister dsr auswirken. Für die Sensitivliste interessiert sich sowieso /nur/ die Simulation. Die Synthese schert sich einen feuchten Kerricht da drum... :-o > Das Design ist ja dann nicht sauber synchron, ja? Das Design ist hier genauso
-
Thread
Woher kommt X / wie vermeiden in dieser Verilog Counter TB ?
Umsetzung in Hardware ist allerdings allein das Hinzufügen oder Weglassen des "negedge reset" in der Sensitivliste zuständig dafür, ob das Design auf dem FPGA mit einem asynchronen oder synchronen Reset umgesetzt wird. Was NÖTIG oder BESSER ist, das findest du im Datenblatt zu den Logikblöcken deines speziellen
-
Thread
process innerhalb eines prozesses starten
wait until rising_edge(clk); : end process; [/vhdl] Der Vorteil: keine fehlerhafte Sensitivliste möglich. Ok, VHDL2008 gibts auch... ;-)
-
Thread
Wie erkennt man, ob VHDL code automatisch generiert wurde?
wie/ der von dort aus zum VHDL-Code kommt, ist erst mal egal. Das mit den überbestimmten Sensitivlisten wäre für mich aber definitiv ein Fehler!
-
Thread
parametrisierbarer Binärzäher
nicht, oder? JA und NEIN. Es braucht in der Simulation (und nur für die Simulation ist die Sensitivliste überhaupt interessant) mehr Rechenzeit, denn der Prozess wird auch neu berechnet, wenn sich enable ändert. Das wäre aber unnötig.
-
Thread
gedrueckter key soll led im wechsel zum leuchten bringen und dunkel machen
Entprellung takeiteasy schrieb im Beitrag #4763953: > process(clk, key, modus) In dieser Sensitivliste sind modus und key überflüssig und falsch. Der Prozess ist ausschließlich auf clk sensitiv.
-
Thread
Lauflicht mit VHDL
.. BTW: 1. man macht keine solchen seltsamen kombinatorisch-getakteten Prozesse. 2. die Sensitivliste des Prozesses ist unvollständig: Qn fehlt. Und zum Thema Lauflicht: http://www.lothar-miller.de/s9y/archives/61-Lauflicht.html
-
Thread
Problem mit integer
... Die Simulation wird allerdings nicht stimmen, denn /offset/ und /spi_en/ fehlen in der Sensitivliste. Sieh dir doch mal an, wie andere einen getakteten Prozess beschreiben (und vor allem, wieviele Takte in einem solchen Prozess auftauchen). BTW: Statt [vhdl] pwm_new_value <= "0000000000000000000000000000000000000000000000000000000000000000
-
Thread
vhdl process zeitablaufdiagramm
Grundfunktion eines "AND" verstanden hat und es erkennen kann. Wenn man, um das "unvollständige Sensitivliste"-Problem zu umgehen, einfach nur den Prozess in eine nebenläufige Beschreibung umsetzen will, dann eher so: [vhdl] y <= '0' when a='0' else '0' when b='0' else '0' when c='0' else
-
Thread
VHDL Einsteigerset
seinen Studenten... ;-) > bzw. unterschiedlich. Du mußt nur mal einen kleinen Fehler in die Sensitivliste eines Prozesses machen, dann hast du sofort einen Unterschied: [vhdl] process (clk) begin a <= b; end process; [/vhdl] Das sieht jetzt in der Simulation aus, als wenn der Prozess
-
Thread
Mux mit One-Hot Eingang
> Mal ein Vorschlag als kombinatorischer Prozess Die Sensitivliste ist nicht vollständig. Es fehlt das wichtigste Signal...
-
Thread
Theoriefrage: Zeitabschätzung
wird. Insbesondere bringt die Mehr-Automaten-Schreibweise Probleme mit sich, wenn z.B. die Sensitivliste des Kombinatorik-Teils nicht komplett ist, dann wird falsch simuliert. Oder wenn im Kombinatorischen Teil ein Zähler eingefügt wird, oder, oder... Such einfach mal hier im Forum nach Ein-,
-
Thread
Quartus. Case statement mit 256 when wirft Fehler
Werden da tatsächlich nur Konstanten zugewiesen oder ist die Sensitivliste unvollständig?
-
Thread
Verständnisproblem Xilinx XC9572 CPLD
Berechnungen. Bei 12 ist es noch schlimmer: da hilft das /Nichtplatzieren/ eines Signals in der Sensitivliste (also das Ignorieren von Regel 9) nur zum Verhindern einer kombinatorischen Schleife /im Simulator/, in der Hardware wird sie trotzdem eingebaut!
-
Thread
VHDL process: letzte Zuweisung immer gültig?
tut er nur in der Simulation. In der Realität teilt dir der Synthesizer lapidar mit, dass die Sensitivliste nicht vollständig sei und deshalb die Simulation nicht zu der Realität passe. > Gelesen habe ich jedoch, dass eine solche Hardware nicht synthetisiert > werden kann. Es gibt Bausteine wie
-
Thread
Taktverschieben
ein Latch auftritt da ich kein else Zweig hab Und zudem ist die Simulation falsch, weil die Sensitivliste nicht vollständig ist :-o TAKT :process (CNT) << hier fehlt TAKT_RESET
-
Thread
Programm läuft nur im Simulator
asynchronen Signale.... Der Prozess ist erst mal Getaktet und dann noch Kombinatorisch, da muß die Sensitivliste schon so sein... :-o [vhdl] if reset='1' then ZUSTAND <= A; elsif takt='1' and takt'event then -- getaktet ZUSTAND <= FOLGEZUSTAND; end if; case ZUSTAND is
-
Thread
VHDL - UP / DOWN 3-Bit Zählerproblem
Zudem ist die Sensitivliste des Prozesses (wie üblich) überdefiniert: [vhdl] process(clk, toAdd, toDelete) [/vhdl] Weil der Prozess nur auf /clk/ sensitiv ist (also nur bei einer Änderung von /clk/ neu berechnet werden
-
Thread
Einige Fragen zu VHDL
mindestens ein /wait/ Statement enthält. Wenn der Prozess aber eine /wait/ Anweisung enthält, muss die Sensitivliste leer sein! Zum Thema "FOR-Schleife und Anfänger"... Such mal nach meinen Postulaten: http://www.mikrocontroller.net/search?query=anf%C3%A4nger+postulate&forums[]=9&max_age=-&sort_by_date=1
-
Thread
Paritätsgenerator VHDL-code fehler
einfach alles nachplappern, was andere vorplappern... :-/ Ein Prozess mit einem /wait/ darf keine Sensitivliste haben. >> with PAR select := false; --hier ist 15.Zeile Was ist das für ein Syntax? Sieh dir mal ein with...select in VHDL an. > Ich weiß nicht ob das > wait until(clk'event and
-
Thread
BUS Muxer spinnt
End If; END Process; [/vhdl] Und dann ginge das auch noch concurrent ohne Prozess und Sensitivliste. Ich würde das also so machen: [vhdl] BUS_OUT <= BUS_IN_Change when Switch_Enable(2) = '1' else BUS_IN_Quelle; [/vhdl] Und damit wird der Mux so aussehen: [vhdl] library IEEE; use
-
Thread
32 bit integer funkt nicht
00000000000000000000000000000000"; end if; end process; [/vhdl] Zudem ist intcount in der Sensitivliste unnnötig... :-/ Ich sehe gerade: if rising_edge(puls)and Puls = '1' then hier ist Puls='1' komplett unnötig, diese Abfrage wird von rising_edge() mit erledigt :-o Mach es so,
-
Thread
kruder Fehler bei FPGA-Programmierung (ISE WEBpack-Schematic)
einfach auf diese Busse zu reagieren? Probiers aus. Das geht so sowieso nicht... Als Info: die Sensitivliste ist /nur und ausschließlich/ für die /Simulation/ interessant. Der Synthesizer schert sich nicht um diese Liste. Du kannst also damit nichts "steuern". > Reicht es da aus, einfach auf diese Busse
übernommen. Und weil du (hoffentlich) sowieso das ganze Design /synchron/ machst, hat in der Sensitivliste nur der Takt was zu suchen. Such mal nach "VHDL Postulate" hier im Forum... ;-) https://www.mikrocontroller.net/search?query=vhdl+postulate Und leih dir mal die Bücher da aus: https://www.mikrocontroller.net
-
Thread
verständnisfrage process vhdl
rising_edge (takt) then if run = '0' then ... [/vhdl] Beachte: 'run' entfällt in der Sensitivliste, da ja alles auf 'takt' synchronisiert ist.
-
Thread
One-Hot encoded Statemachine kommt in illegalen Zustand, wird nicht reseted, gibt unerwartetes aus
andersrum: woher kommen diese Signale? BTW: process (clk, reset, a, b, c) In dieser Sensitivliste sind a, b und c unnötig.
-
Thread
Statemachine mit snychr Ausgangsschaltwerk
Simulation werden sie auch nicht aufgerufen, sondern neu berechnet, wenn sich eines der Signale in der Sensitivliste ändert. > Stateaktualisierung und caseabfrage sind in zwei seperaten prozessen > getriggert auf eine steigende taktflanke. Das ist eine unnötige Verknotung der Ein-Prozess- und Zwei-Prozess-Methode
-
Thread
Synchrone Prozesse
Prozess dann asynchron mit enable in der > Sensiliste? Vielleicht ein kleiner Hinweis: die Sensitivliste ist /nur/ und /ausschließlich/ für die Simulation interessant. Der Synthesizer meldet nur, wenn sie nicht vollständig ist, und zeigt damit an, dass die erzeugte Hardware nicht zur Simulation passt
-
Thread
GHDL Problem
wichtig. Doch hier ist es anders herum im Simulator läuft es aber nicht in der Hardware. Die Sensitivlisten habe ich schon überprüft. Duke zu SUMP Leider bekomme ich das java programm nicht zum Laufen. ;-< Caused by: java.lang.ClassNotFoundException: org.sump.analyzer.Loader at java.net.URLClassLoader