Hallo liebes Forum,
hallo Lothar,
ich habe ein Problem beim eintakten von 4 Sensor Signalen (2 Signale
sind LOW Aktiv).
Ich möchte, wie im vhdl Code ersichtlich, genau dann eine 0 am Ausgang
haben wie ich es definiert habe. Der Encoder ist ein "schnarchlangsames"
Encoder Signal (max. 18kHz). Ist es für euch/dich ersichtlich warum es
nicht so wie gedacht funktioniert? Ich sehe den Wald vor lauten Bäumen
nicht mehr.
Wahrheitstabelle:
3 downto 0
3 2 1 0
-------------
1 0 0 1
1 0 1 0
1 0 0 0
0 1 0 1
0 1 1 0
0 1 0 0
1
libraryIEEE;
2
useIEEE.STD_LOGIC_1164.ALL;
3
useIEEE.NUMERIC_STD.ALL;
4
5
entityTest_UST96_150205is
6
Port(Sensor:inSTD_LOGIC_VECTOR(3downto0);
7
Motor:outSTD_LOGIC;
8
LED:outSTD_LOGIC;
9
Encoder:inSTD_LOGIC;
10
CLK:inSTD_LOGIC);
11
endTest_UST96_150205;
12
13
14
architectureBehavioralofTest_UST96_150205is
15
signals_alt:std_logic_vector(3downto0):="0000";-- speichern der vorigen Sensortzustände
16
signalenc_sr:std_logic_vector(3downto0):="0000";-- Schieberegister zum Einsynchronisieren und für die Flankenerkennung
17
signalcnt:integerrange0to19999;-- Zähler: 19999 Schritte sind 0...8
Nun, dein Post ist leider etwas wirr.
- Du solltest uns sagen, WAS nicht funktioniert.
- Ne Wahrheitstabelle hat immer auch eine Spalte für das "Ergebnis"
Aber so wie ich es sehe, synchronisierst du gar nicht ein, da du in
deinem Code immer wieder direkt mit dem Sensor-Port vergleichst und
nicht mit einem einsynchronisierten Sensor-Port
Hi,
also wenn ich das ganze in Betrieb nehme, alle Signale anschließe dann
ist der Ausgang, sprich Motor/LED auf '0' also aus. Wenn ich nun keinen
der Zustände laut Wahrheitstabelle einstelle, dann erwarte ich, dass die
LED leuchtet und das Motor Signal '1' ist.
Wird nun ein Zustand laut Wahrheitstabelle erreicht, so soll die LED
ausgehen /Motor '0' werden und nach 20000 Pulsen die LED wieder angehen
/ Motor '0'.
Leider passiert genau das nicht. Egal was ich mache die LED bleibt immer
aus und der Motor Ausgang ist dauerhaft '0'.
Egal wie ich die Signale schalte der Ausgang bleibt aus.
Wenn ich nun den Sensor 0 abklemme und mit Sensor 1 zwischen '0' und '1'
wechsel dann geht der Motor/LED zumindest aus und nach 20000 Pulsen
wieder an.
Aber das ist nicht Sinn der Sache.
Was muss ich in meinem Code ändern, sodass die LED und der Motor laut
Wahrheitstabelle für 20000 Pulsen ausgehen und dann wieder angehen?
Ich hoffe es ist nun etwas verständlicher was ich möchte.
Vielen Dank für eure rasche Hilfe.
Schlumpf schrieb:> Aber so wie ich es sehe, synchronisierst du gar nicht ein, da du in> deinem Code immer wieder direkt mit dem Sensor-Port vergleichst und> nicht mit einem einsynchronisierten Sensor-Port
Müsste das also so aussehen?
if s_alt="1001" then
Frage ich nun den einsynchronisierten Sensorport ab?
Dein Code ist schon sehr eigenartig.
Der macht folgendes:
Es wird mit JEDER steigenden Flanke des Encoders cnt inkrementiert. Wenn
cnt = 20000, wird aufgehört zu zählen und Motor und LED auf '1' gesetzt.
Motor, LED und cnt wird ZWISCHEN den steigenden Flanken des Encoders auf
'0' gesetzt, wenn der Wert von Sensor sich in diesem Zeitpunkt ändert
und einen der auscodierten Werte annimmt.
Ist es das, was du willst?
Schlumpf schrieb:> Dein Code ist schon sehr eigenartig.>> Der macht folgendes:>> Es wird mit JEDER steigenden Flanke des Encoders cnt inkrementiert. Wenn> cnt = 20000, wird aufgehört zu zählen und Motor und LED auf '1' gesetzt.>> Motor, LED und cnt wird ZWISCHEN den steigenden Flanken des Encoders auf> '0' gesetzt, wenn der Wert von Sensor sich in diesem Zeitpunkt ändert> und einen der auscodierten Werte annimmt.>> Ist es das, was du willst?
Also ich verstehe nicht ganz was du meinst. Ich versuche mal kurz zu
erklären was ich möchte.
Die Schaltung wird in Betrieb genommen: Motor = '1' und die LED
leuchtet.
Wenn nun eine '0' laut Wahrheitstabelle erreicht wird soll folgendes
passieren.
1.) Motor = '0' und LED aus
2.) Der Counter soll die positiven Flanken vom Encoder Signal zählen
sind 20000 erreicht: Motor = '1' LED leuchtet
Wird innerhalb der 20000 Flanken eine weitere '0' laut Wahrheitstabelle
erreicht soll Schritt 1.) wieder von vorn beginnen.
Ist das verständlich rübergekommen was ich möchte? Wie muss der Code
dazu aussehen?
Vielen Dank
s.w.
s.w. schrieb:> Wird innerhalb der 20000 Flanken eine weitere '0' laut Wahrheitstabelle> erreicht soll Schritt 1.) wieder von vorn beginnen.
Um Missverständnissen vorzubeugen. Es soll quasi der ganze Prozess ab
Schritt 1.) wieder durchlaufen werden. das umfasst also auch den Schritt
2.)
denke nun ist es ganz klar was gemeint ist
s.w.
s.w. schrieb:> 1.) Motor = '0' und LED aus> 2.) Der Counter soll die positiven Flanken vom Encoder Signal zählen> sind 20000 erreicht: Motor = '1' LED leuchtet
Hab vergessen den Cnt auf 0 zu setzen. Der Ablauf sieht nun wie folgt
aus:
1.) Motor <= '0';
2.) LED <= '0';
3.) cnt <= 0;
4.) Der Counter soll nun die positiven Flanken vom Encoder Signal zählen
sind 20000 erreicht: Motor = '1' LED leuchte
Bin gerade ein bissel durch den Wind, sorry.
So soll der Ablauf nun aussehen.
danke.
s.w.
Lothar Miller schrieb:> Was macht die Simulation?
Das kann ich im Moment nicht probieren, und eine Testbench erstellen ist
für mich noch immer zu schwer. Ich habe die Hardware hier und würde sehr
gern damit testen. Mit deiner Änderung geht´s leider auch nicht , die
Schaltung verhält sich genau wie vorher (aber ich denke das ist dir auch
bewusst).
Ich habe auf jeden Fall noch ein Verständnis Problem. Kannst du mir
bitte mal folgenden Abschnitt Step by Step genau erklären was da
passiert?
warum wird hier "enc_sr <= enc_sr(2 downto 0)& Encoder; --
Einsychronisieren" nur 2 downto 0 einsynchronisiert wo doch 4 Sensoren
vorhanden sind?
Das verstehe ich überhaupt nicht.
vielen Dank
s.w. schrieb:> Kannst du mir> bitte mal folgenden Abschnitt Step by Step genau erklären was da> passiert?
Du verstehst offensichtlich nicht, was du selbst codierst? Das ist aber
bedenklich.
Wenn du das aber schon selbst eingestehst, dann wäre es vielleicht
besser, du befasst dich erst mal mit den rudimentärsten Grundlagen von
VHDL.
Ich habe dir in Prosa erklärt, was dein Code macht. Das hast du nicht
verstanden. Dann schreibst du selbst hin, was dein Code können soll,
allerdings ziemlich widersprüchlich. Und dann bittest du darum, dir die
grundlegendsten Zeilen deines eigenen Codes zu erklären.
Das wird für alle Beteiligten hier echt schwer.
Und ich denke, dir ist nicht klar, dass du mit VHDL keine Software
machst, sondern eine Hardware-Beschreibung. Es ist eben nicht so, dass
da eine Art Programm von oben nach unten durchlaufen wird, sondern dass
du mit dem Code das Verhalten einer Hardware beschreibst. Das ist ein
grundlegender Unterschied.
Ist dir dieser Unterschied bewusst?
s.w. schrieb:> Das verstehe ich überhaupt nicht.
Sieh dir dad im Simulator an. Und der &-Operator ist ein
Verknüpfungsoperator, oder "Zusammenfügeoperator". Damit werden einfach
Bits oder Vektoren zusammengeklebt...
Schlumpf schrieb:> s.w. schrieb:>> Kannst du mir>> bitte mal folgenden Abschnitt Step by Step genau erklären was da>> passiert?>> Du verstehst offensichtlich nicht, was du selbst codierst? Das ist aber> bedenklich.
1. Ich habe das nicht selbst codiert, sondern das netterweise von Lothar
zur Verfügung bestellt gekommen und soweit auch verstanden.
Was ich an dem ganze code nicht verstehe ist die Zeile
" enc_sr <= enc_sr(2 downto 0)& Encoder; "
> Wenn du das aber schon selbst eingestehst, dann wäre es vielleicht> besser, du befasst dich erst mal mit den rudimentärsten Grundlagen von> VHDL.>> Ich habe dir in Prosa erklärt, was dein Code macht. Das hast du nicht> verstanden. Dann schreibst du selbst hin, was dein Code können soll,> allerdings ziemlich widersprüchlich. Und dann bittest du darum, dir die> grundlegendsten Zeilen deines eigenen Codes zu erklären.
Auch das stimmt so nicht. 1. Das wie du dir denkst wie der Code
funktioniert ist nicht so. Er funktioniert so wie ich es erklärt habe,
allerdings nur bis zu drei Sensoren. Sobald ich Sensor 4 anschließe und
dieser High ist funktioniert gar nichts mehr und das verstehe ich nicht.
>> Das wird für alle Beteiligten hier echt schwer.>> Und ich denke, dir ist nicht klar, dass du mit VHDL keine Software> machst, sondern eine Hardware-Beschreibung. Es ist eben nicht so, dass> da eine Art Programm von oben nach unten durchlaufen wird, sondern dass> du mit dem Code das Verhalten einer Hardware beschreibst. Das ist ein> grundlegender Unterschied.> Ist dir dieser Unterschied bewusst?
Das ist mir natürlich auch klar.
Ich benötige einfach nur einen Denkanstoß. Was muss ich tun um eine
Anzahl (5-20) von Sensoren einzusynchronisieren
Und wie stelle ich das an, dass ich das wie in meiner Wahrheitstabelle
definiert, den Ausgang Motor und LED schalte?
Ich fände es schön mir NUR diesen Abschnitt für meine 4 Sensoren einmal
zu zeigen.
Vielen Dank
s.w. schrieb:> 1. Ich habe das nicht selbst codiert, sondern das netterweise von Lothar> zur Verfügung bestellt gekommen und soweit auch verstanden.
Hast du nicht.. definitiv nicht.
Und ich bezweifle sehr stark, dass Lothar dir sowas zur Verfügung
gestellt hat. Jedenfalls nicht in diesem Kontext. In einem synchronen
Prozess auf asynchrone Signale zu vergleichen, das passiert Lothar
nicht.
s.w. schrieb:> Was ich an dem ganze code nicht verstehe ist die Zeile> " enc_sr <= enc_sr(2 downto 0)& Encoder; "
Und was genau verstehst du an dieser Zeile nicht?
s.w. schrieb:> Das wie du dir denkst wie der Code> funktioniert ist nicht so.
Doch, er tut das, was ich beschrieben habe.. definitiv!
s.w. schrieb:> Er funktioniert so wie ich es erklärt habe,
Welche deiner zig widersprüchlichen und unvollständigen Erklärungen
meinst du?
s.w. schrieb:> Ich benötige einfach nur einen Denkanstoß. Was muss ich tun um eine> Anzahl (5-20) von Sensoren einzusynchronisieren
Indem du für jeden Sensor zwischen dem asynchronen Teil und dem
synchronen Teil mindestens EIN Synchronisationsregister schaltest,
welches mit dem Takt des synchronen Teils betrieben wird.
s.w. schrieb:> Und wie stelle ich das an, dass ich das wie in meiner Wahrheitstabelle> definiert, den Ausgang Motor und LED schalte?>> Ich fände es schön mir NUR diesen Abschnitt für meine 4 Sensoren einmal> zu zeigen.
Hat Lothar dir bereits hingeschrieben.
Kann es sein, dass Sensor(0) ständig seinen Wert ändert, während
Sensor(3 downto 1) auf "100" oder "010" steht?
Wenn einer der Reset-Werte aus deiner Wahrheitstabelle öfter auftritt,
als dein Zähler braucht, um auf 20000 zu zählen, dann bleibt die LED
aus, da du auch während des Zählvorgangs jederzeit den Zähler wieder
zurücksetzt, wenn einer der codierten Werte von Sensor eintritt.
Schlumpf schrieb:> Kann es sein, dass Sensor(0) ständig seinen Wert ändert, während> Sensor(3 downto 1) auf "100" oder "010" steht?
Nein. Sensor 0 ist ein induktiver Sensor. Der ist normal immer auf 1 und
ist mit einem optokoppler verbunden. Von dort aus geht's in mein de0
nano Board. Wenn ich nun den Sensorausgang aus dem optokoppler ziehe
habe ich also eine 0 auf dem Sensoreingang 0. wenn das so ist dann
funktioniert zumindest die Logik mit den 3 restlichen Sensoren.
Ich könnte zur Sicherheit allerdings auch mal den Eingang von s0 an 3,3V
oder Masse legen, dann bin ich da ganz sicher was den pegel betrifft.
>> Wenn einer der Reset-Werte aus deiner Wahrheitstabelle öfter auftritt,> als dein Zähler braucht, um auf 20000 zu zählen, dann bleibt die LED> aus, da du auch während des Zählvorgangs jederzeit den Zähler wieder> zurücksetzt, wenn einer der codierten Werte von Sensor eintritt.
Korrekt. So soll es sein.
Aber wie gesagt. Sobald s0 auf '1' steht geht nicht mehr und ich versteh
einfach nicht warum.
:-(
Was ich an dem ganze code nicht verstehe ist die Zeile
> " enc_sr <= enc_sr(2 downto 0)& Encoder; ">> Und was genau verstehst du an dieser Zeile nicht?
Ich habe 4 Sensoren (3 downto 0). Warum werden dann abe nur 2 downto 0
eingetaktet? Dann wird doch der Sensor s0 garnicht eingetaktet?!?
Für was steht enc_sr?
Encoder Source oder was?
Vielleicht hast du noch mal die Lust mir das zu erklären. Finde die
Abkürzung auch in meinem Vhdl nirgends.
Schönen Abend euch und danke für die Hilfe.
Spatestens jetzt bin ich mir 100$ig sicher, dass du nicht weisst, was du
tust.
Sorry, ich will dir nicht auf den Schlips treten, aber du hast einen
Port der Sensor heißt und fragst dann, wie in der Zeile
1
enc_sr<=enc_sr(2downto0)&Encoder;
der SENSOR einsynchronisiert wird.
Siehst du in dieser Zeile irgendwo das Wort "Sensor"? Ich nicht! Und da
ist es doch naheliegend, dass diese Zeile Nullkommanix mit dem Sensor zu
tun hat, oder?
s.w. schrieb:> Für was steht enc_sr?
Schau doch mal deinen (sorry, den abgepinselten und nicht verstandenen)
Code an.
Was ist enc_sr?
Richtig! ein Signal. Ein Signal dass du (oder besser der Autor des
Codes) selbst ausgewählt hat. Das ist also kein VHDL Schlüsselwort oder
sonstwas. Es könnte genauso gut "leberwurst" heißen.
Ich würde es als "Encoder Schieberegister" interpretieren.
Diese Zeile beschreibt ein Schieberegister, durch welches der
Encoder-Port geschoben wird. Mittels dieses Schieberegisters wird zum
einen das asynchrone Signal synchronisiert und dann die steigende Flanke
des Signals erkannt.
Dein Sensor-Signal wird leider nirgends synchronisiert.
Schlumpf schrieb:> Und ich bezweifle sehr stark, dass Lothar dir sowas zur Verfügung> gestellt hat. Jedenfalls nicht in diesem Kontext. In einem synchronen> Prozess auf asynchrone Signale zu vergleichen, das passiert Lothar> nicht.
Aua, da hatte ich wohl eine schwache Sekunde im
Beitrag "Re: 2 Phasen Takt, Wegimpulsverzögerung"
Aber das dürfte tatsächlich nicht passieren. Jedes asynchrone Signal
muss vor Verwendung einsynchronisiert werden. Bei "niedrigen"
Taktfrequenzen bis 100MHz reicht ein Flipflop. Aber sogar das fehlt in
meiner Beschreibung. Ich kehre mich in Sack und Asche...
Lothar Miller schrieb:> Aua, da hatte ich wohl eine schwache Sekunde
Loooothhhaaaar, ich bin entsetzt ;-)
Aber mal abgesehen davon, glaube ich nicht, dass das beschriebene
Fehlverhalten auf ein nicht synchronisiertes Signal zurückzuführen ist.
Der Code ist so aufgebaut, dass primär IMMER gezählt wird und somit auch
irgendwann (nach 20.000 Pulsen) die LED an geht.
Das Einzige, was das Erreichen dieses Zustandes verhindern kann ist,
wenn eine der auscodierten Bedingungen erfüllt wird. Es bedarf also
einer Änderung des Sensor-Vektors UND der neue Wert muss einem der
auscodierten entsprechen.
Wenn das Fehkerverhalten so wäre, dass s.w. sagt, dass er trotz Anlegen
einer der Rücksetzbedingungen die LED nicht aus bekommt, dann könnte das
meines Erachtens noch eher auf ein nicht synchronisiertes Signal
zurückzuführen sein. Aber dass quasi dauerhaft die Bedingung für das
Zurücksetzen anliegt, kann ich mir nicht so recht vorstellen.
Zumal selbst ein statisches Anlegen der Rücksetzbedingung nicht zum
dauerhaften Zurücksetzen führen kann, da die Bedingung für das
Zurücksetzen ja auch immer noch mit einer ÄNDERUNG des Sensor-Vektors
verknüpft ist.
Dieses Verhalten lässt sich meines Erachtens nicht mit einem nicht
synchronisierten Signal erklären.
Ich denke eher, dass da in der externen Beschaltung was faul ist und der
Sensor 0 irgendwie "flattert".
Was meinst du, Lothar?
Durch das Verschieben des Counters nach oben wird sichergestellt, dass
bei Auftreten der Rücksetzbedingung diese auch immer zum Zurücksetzen
führt.
Im Original-Code ist es so, dass der Counter nicht zurückgesetzt wird,
wenn die Rücksetzbedingung gleichzeitig mit der steigenden Flanke des
Encoders auftritt. Denke nicht, dass das so gewünscht ist.
Außerdem weiss ich nicht, ob es tatsächlich gewollt ist, dass das
Zurücksetzen nur bei einer Änderung des Sensor-Vektors erfolgen soll.
Heißt, wenn die Rücksetzbedingung statisch am Sensor-Port anliegt, führt
diese nur EINMAL zum Zurücksetzen. Wenn das so gewollt ist, dann passt
es. Falls nicht, dann einfach den Vergleich sens_sync/=s_alt
rausschmeißen.
Außerdem ist die erneute Zuweisung von s_alt im Bereich des Counters
nicht notwendig, da s_alt sowieso bereits bei jedem Takt zugewiesen
wird.
s.w. schrieb:> Lothar Miller schrieb:>> Was macht die Simulation?>> Das kann ich im Moment nicht probieren, und eine Testbench erstellen ist> für mich noch immer zu schwer. Ich habe die Hardware hier und würde sehr> gern damit testen.
Sorry, aber das einfachste Mittel (wenn der Design einigermassen
synchron laeuft und die Eingaenge auch richtig einsynchronisiert sind)
ist die Simulation!
Was ist so schwer daran, an deine Schaltung 'Eingangssignale' anzulegen
und nachzuschauen, ob die 'Ausgangssignale' sich richtig verhalten? Wir
reden ja schon gar nicht ueber automatisches abtesten in der
Testbench...
Also ohne TB schaue ich mir dein VHDL schon gar nicht an... Das ist fuer
mich Zeitverschwendung...
Schlumpf schrieb:> Ohne genau zu wissen, was s.w. wirklich erreichen will, würde ich> den> code aber mal folgendermaßen modifizieren:> architecture Behavioral of Test_UST96_150205 is> signal s_alt : std_logic_vector (3 downto 0) := "0000";> signal enc_sr : std_logic_vector (3 downto 0) := "0000";> signal cnt : integer range 0 to 19999;> signal sens_sync: std_logic_vector (3 downto 0);>> begin> process begin> wait until rising_edge(CLK);> sens_sync <= Sensor;> s_alt <= sens_sync;> enc_sr <= enc_sr(2 downto 0) & Encoder;>> if enc_sr(2 downto 1)="01" then> if cnt<19999 then> cnt <= cnt+1;> else> Motor <= '1';> LED <= '1';> end if;> end if;>> if sens_sync/=s_alt then> if (sens_sync="1001" or sens_sync="1010" or......) then> Motor <= '0';> LED <= '0';> cnt <= 0;> end if;> end if;>> end process;> end Behavioral;>> Durch das Verschieben des Counters nach oben wird sichergestellt, dass> bei Auftreten der Rücksetzbedingung diese auch immer zum Zurücksetzen> führt.> Im Original-Code ist es so, dass der Counter nicht zurückgesetzt wird,> wenn die Rücksetzbedingung gleichzeitig mit der steigenden Flanke des> Encoders auftritt. Denke nicht, dass das so gewünscht ist.>> Außerdem weiss ich nicht, ob es tatsächlich gewollt ist, dass das> Zurücksetzen nur bei einer Änderung des Sensor-Vektors erfolgen soll.> Heißt, wenn die Rücksetzbedingung statisch am Sensor-Port anliegt, führt> diese nur EINMAL zum Zurücksetzen. Wenn das so gewollt ist, dann passt> es. Falls nicht, dann einfach den Vergleich sens_sync/=s_alt> rausschmeißen.>> Außerdem ist die erneute Zuweisung von s_alt im Bereich des Counters> nicht notwendig, da s_alt sowieso bereits bei jedem Takt zugewiesen> wird.
Hi zusammen,
zu allererst möchte ich mich mal bei euch allen für eure Unterstützung
bedanken.
Ich bin seit Anfang diesen Jahres dabei vhdl mir irgendwie anzueignen
und bin sicher auch noch Welten davon entfernt es in der Gesamtheit zu
verstehen, jedoch bin ich sehr engagiert dies so schnell wie möglich
ordentlich hinzubekommen.
Das Buch vom Professor Schwarz "VHDl Synthese" hab ich mir zugelegt
jedoch die entsprechenden Vorlesungen nicht besucht somit ist es als
Nachschlagewerk sicher sehr nützlich allerdings zum lernen für einen
"Newbie"etwas heftig.
Lange Rede kurzer Sinn, bitte nehmt es mir nicht zu übel wenn ich, für
euch belangloses, im Moment nicht immer nachvollziehen kann, ich bin am
lernen und auch sehr dankbar für dieses tolle / schnelle Forum.
Zurück zum Code:
> Durch das Verschieben des Counters nach oben wird sichergestellt, dass> bei Auftreten der Rücksetzbedingung diese auch immer zum Zurücksetzen> führt.
So wünsche ich mir das! Sobald eine der oben genannten Bedingungen
erfüllt ist soll die LED ausgehen, der counter auf Null gesetzt werden,
bis 20000 zählen und dann die LED wieder angehen.
Nachtrag:
Wenn die Sensoren zum Beispiel für 10 Sekunden eine Bedingung halten
dann soll ab Beginn dieser Bedingung die LED an gehen und der Counter
möchte bitte immer wieder von 0 anfangen zu zählen bis die Bedingung
nicht mehr anliegt. Sobald die Bedingung nicht mehr anliegt kann er bis
20000 durchzählen und dann die LED wieder anschalten. Ich hoffe es ist
verständlich was ich meine?
> Im Original-Code ist es so, dass der Counter nicht zurückgesetzt wird,> wenn die Rücksetzbedingung gleichzeitig mit der steigenden Flanke des> Encoders auftritt. Denke nicht, dass das so gewünscht ist.
korrekt, das ist dann nicht so wie gewünscht!
>> Außerdem weiss ich nicht, ob es tatsächlich gewollt ist, dass das> Zurücksetzen nur bei einer Änderung des Sensor-Vektors erfolgen soll.
Nein, wie oben beschrieben, sobald eine Bedingung erfüllt ist MUSS die
LED ausgehen. Ist die Bedingung dann nicht mehr erfüllt, wird bis 20000
gezählt und die LED geht wieder an.
> Heißt, wenn die Rücksetzbedingung statisch am Sensor-Port anliegt, führt> diese nur EINMAL zum Zurücksetzen. Wenn das so gewollt ist, dann passt> es. Falls nicht, dann einfach den Vergleich sens_sync/=s_alt> rausschmeißen.
Alles klar. 1000 Dank, daran hab ich auch schon ne weile rumgefummelt
und das leider nie hinbekommen!!!
>> Außerdem ist die erneute Zuweisung von s_alt im Bereich des Counters> nicht notwendig, da s_alt sowieso bereits bei jedem Takt zugewiesen> wird.
Alle klar.
Vielen Dank die ganzen hilfreichen Hinweise. Ich werde dies nun umsetzen
doch zunächst noch eine allgemeine Frage!
Benutz ihr alles Xillinx? Ist die Bedienung und das Erzeigen von Code,
zuweisen von Port und Signalen hier etwas einfacher gestaltet als Altera
mit Quartus II und ModelSim? Gibt es denn für Xillinx mehr deutsche
Tutorials oder Anleitungen die für nen blutigen Anfänger leicht
verdaulich sind ? Ich habe im Moment ein DE0-nano Board im Einsatz bin
soweit auch zufrieden. Jedoch hat sich gezeigt, dass ich es nicht ohne
weitere hinbekommen eine Testbench in Modelsim zu schreiben da, fehlt
mir noch zu viel wissen. Geht das in Xilinx quasi halbautomatisch?
Lothar meinte es ginge in Xilinx wesentlich einfacher
(bedienungsfreundlicher) könnt ihr das bestätigen oder gilt diese
Aussage nur für Vollprofis?
So nun bin ich erst mal fertig.
Wünsche allen ein schönes und erholsames Wochenende.
viele Grüße
s.w.
Weißst du, wir helfen hier echt gerne, wenn wir können.
Aber es ist wirklich ärgerlich, wenn man dir in Klartext sagt, was dein
Code macht und du einem sagst: "Das stimmt so nicht, der Code macht was
anderes".
Und dann aber die ganze Zeit durchklingen lässt, dass du den Code nicht
so richtig verstehst.
Entweder verstehst du deinen Code und weisst, was er tut, oder du
verstehst ihn nicht. Aber dann kannst du auch nicht sagen, dass der Code
genau dies oder jenes macht.
Das kommt einfach nicht gut an.
Und jetzt widersprichst du dir schon wieder:
s.w. schrieb:> Sobald eine der oben genannten Bedingungen> erfüllt ist soll die LED ausgehen, der counter auf Null gesetzt werden,> bis 20000 zählen und dann die LED wieder angehen.s.w. schrieb:> dann soll ab Beginn dieser Bedingung die LED an gehen und der Counter> möchte bitte immer wieder von 0 anfangen zu zählen bis die Bedingung> nicht mehr anliegt.s.w. schrieb:> Ist die Bedingung dann nicht mehr erfüllt, wird bis 20000> gezählt und die LED geht wieder an.
Das ist schon wieder ein krasser Widerspruch.
Im ersten Fall soll die LED nach Anlegen der Bedingung sofort aus gehen
und nach Ablauf des Counters wieder an.
Im zweiten Fall soll die LED aber SOFORT angehen...
Im dritten Fall soll offensichtlich darauf gewartet werden, bis die
Bedingung NICHT mehr erfüllt ist, und erst dann wird auf 20.000 gezählt
und erst dann geht die LED wieder an.
Das sind drei grundsätzlich unterschiedliche Anforderungen, die sich
teilweise sogar gegenseitig ausschließen.
Wie soll dir da geholfen werden, wenn du nicht mal formulieren kannst,
was du willst?
>> Und jetzt widersprichst du dir schon wieder:>> s.w. schrieb:>> Sobald eine der oben genannten Bedingungen>> erfüllt ist soll die LED ausgehen, der counter auf Null gesetzt werden,>> bis 20000 zählen und dann die LED wieder angehen.>> s.w. schrieb:>> dann soll ab Beginn dieser Bedingung die LED an gehen und der Counter>> möchte bitte immer wieder von 0 anfangen zu zählen bis die Bedingung>> nicht mehr anliegt.>> s.w. schrieb:>> Ist die Bedingung dann nicht mehr erfüllt, wird bis 20000>> gezählt und die LED geht wieder an.>> Das ist schon wieder ein krasser Widerspruch.> Im ersten Fall soll die LED nach Anlegen der Bedingung sofort aus gehen> und nach Ablauf des Counters wieder an.>> Im zweiten Fall soll die LED aber SOFORT angehen...>> Im dritten Fall soll offensichtlich darauf gewartet werden, bis die> Bedingung NICHT mehr erfüllt ist, und erst dann wird auf 20.000 gezählt> und erst dann geht die LED wieder an.>> Das sind drei grundsätzlich unterschiedliche Anforderungen, die sich> teilweise sogar gegenseitig ausschließen.> Wie soll dir da geholfen werden, wenn du nicht mal formulieren kannst,> was du willst?
Hi,
ja ich sehe grad da ist zumindest Tippfehler drin:
">> dann soll ab Beginn dieser Bedingung die LED an gehen und der
Counter" --> das ist natürlich Unsinn. Die LED soll aus gehen!!!
Das Eine schließt das Andere aber nicht aus. Tausche bitte im zweiten
Abschnitt gedanklich das "an" gegen "aus" und sehe den zweite + dritten
Abschnitt als Erweiterung zum 1. Abschnitt.
So, ich gebe mir nun wirklich mühe alles in einem Rutsch zu formulieren
was ich in der Gesamtheit möchte:
Eine der 6 definierten Bedingungen wurden erreicht, nun soll folgendes
passieren:
1.) Motor <= '0';
LED <= '0';
cnt <= 0;
Dieser Zustand soll so lange verharren bis keine der oben genannten
Bedingungen mehr anliegen
2.) Counter soll bis 20000 zählen
Wird nun eine der oben genannten Bedingungen nochmal erreicht bevor er
bis 20000 gezählt hat dann -> Sprung zu Schritt 1
3.) Motor <= '1';
LED <= '1';
Ich hoffe nun ist klar was gemeint ist?
Gruß,
s.w.
s.w. schrieb:> Das Eine schließt das Andere aber nicht aus.
Doch!
Es ist z.B. ein Unterschied, ob von Beginn an der Bedingung der Counter
immer im Kreis rumzählt, bis die Bedingung nicht mehr anliegt (Punkt 2)
oder ob der Counter zu zählen beginnt, wenn die Bedingung NICHT MEHR
anliegt (Punkt 3)
s.w. schrieb:> und sehe den zweite + dritten> Abschnitt als Erweiterung zum 1. Abschnitt.
So ein Quark!
Im ersten Abschnitt beschreibst du EINDEUTIG, dass der Counter SOFORT
loslaufen soll.
Im dritten Abschnitt forderst du aber, dass der Counter erst loslaufen
soll, wenn die Bedinung nicht mehr anliegt.
Das ist keine ERWEITERUNG, das ist ein Ausschluss.
s.w. schrieb:> Ich hoffe nun ist klar was gemeint ist?
Das ist das erste mal in dem gesamten Thread, dass du es geschafft hast,
deine Anforderung eindeutig und Widerspruchsfrei zu formulieren.
Gratulation! :-)
Und diese Architecture sollte genau das machen, was du gerade formuliert
hast:
Schlumpf schrieb:> s.w. schrieb:>> Das Eine schließt das Andere aber nicht aus.>> Doch!>> Es ist z.B. ein Unterschied, ob von Beginn an der Bedingung der Counter> immer im Kreis rumzählt, bis die Bedingung nicht mehr anliegt (Punkt 2)> oder ob der Counter zu zählen beginnt, wenn die Bedingung NICHT MEHR> anliegt (Punkt 3)>> s.w. schrieb:>> und sehe den zweite + dritten>> Abschnitt als Erweiterung zum 1. Abschnitt.>> So ein Quark!>> Im ersten Abschnitt beschreibst du EINDEUTIG, dass der Counter SOFORT> loslaufen soll.> Im dritten Abschnitt forderst du aber, dass der Counter erst loslaufen> soll, wenn die Bedinung nicht mehr anliegt.> Das ist keine ERWEITERUNG, das ist ein Ausschluss.>> s.w. schrieb:>> Ich hoffe nun ist klar was gemeint ist?>> Das ist das erste mal in dem gesamten Thread, dass du es geschafft hast,> deine Anforderung eindeutig und Widerspruchsfrei zu formulieren.> Gratulation! :-)>> Und diese Architecture sollte genau das machen, was du gerade formuliert> hast:> architecture Behavioral of Test_UST96_150205 is> signal enc_sr : std_logic_vector (3 downto 0) := "0000";> signal cnt : integer range 0 to 19999;> signal sens_sync: std_logic_vector (3 downto 0);>> begin> process begin> wait until rising_edge(CLK);> sens_sync <= Sensor;> enc_sr <= enc_sr(2 downto 0) & Encoder;>> if enc_sr(2 downto 1)="01" then> if cnt<19999 then> cnt <= cnt+1;> else> Motor <= '1';> LED <= '1';> end if;> end if;>> if (sens_sync="1001" or sens_sync="1010" or......) then> Motor <= '0';> LED <= '0';> cnt <= 0;> end if;>> end process;> end Behavioral;
Hallo Schlumpf,
vielen dank für deine ganzen Mühen, ich deinen code so schnell wie
möglich testen, ich habe jedoch noch eine Verständnis Frage:
Mal angenommen ich möchte nun 8 Sensoren anstelle von 4 verwenden würde
der Code dann folgendermaßen aussehen?
Eine Frage habe ich zu der folgenden Zeile:
enc_sr <= enc_sr(2 downto 0) & Encoder;
Warum steht hier nun 2 downto 0 & Encoder und nicht 3 downto 0 & Encoder
wie oben bei "> signal enc_sr : std_logic_vector (3 downto 0) :=
"0000";" ??? Müssen nicht alle Vectoren eingetaktet werden? Ich stelle
mir eigentlich vor, dass (3 downto 0 ) die Anzahl an Leitungen die an
das Schieberegister angeschlossen sind, darstellen. Das verstehe ich
nicht, muss ich mir das einfach merken das die Zahl immer Anzahl Signal
Vector -1 ist?
Schönen Abend noch
s.w. schrieb:> Mal angenommen ich möchte nun 8 Sensoren anstelle von 4 verwenden würde> der Code dann folgendermaßen aussehen?
Beinahe..
Ich begreife nicht, warum du immer wieder dieses Encoder-Schieberegister
mit deinen Sensoren in Zusammenhang bringst? Das eine hat mit dem
anderen GAR NICHTS zu tun.
Ich glaube echt, ohne dir nahe treten zu wollen, dass du mal einen
Schritt weiter unten anfangen solltest. Mir scheint es wirklich so, als
hättest du nicht wirklich verstanden, was der Code macht.
Und es ist doch nicht befriedigend, bei jeder kleinen Änderung wieder
unsicher im Code rumzustochern, weil man nicht wirklich verstanden hat,
was man tut, oder?
Ich könnte jetzt ausholen und dir den Code haarklein erklären, aber dazu
muss ich wissen, welchen Wissenstand ich voraussetzen kann.
Daher bitte ich dich, mir einfach ein paar Begriffe kurz zu erklären,
damit ich einschätzen kann, WO ich anfangen muss, zu erklären.
Ist das ok für dich?
Wenn ja, dann erkläre mir mal bitte folgende Begriffe (kurz und knapp)
- Synchrones Design
- Einsynchronisieren
- Register
- Schieberegister
Dann weiss ich einfach, wo ich mit erklären anfangen muss
Wenn ja, dann erkläre mir mal bitte folgende Begriffe (kurz und knapp)
- Synchrones Design
- Einsynchronisieren
- Register
- Schieberegister
Ich habe jetzt bewusst nicht nach gegoogled sondern erläutere die 4
Begriffe wie ich mir das grad so vorstelle bzw. in Erinnerung habe.
- Synchrones Design: alles läuft CLK gesteuert, sprich Signale etc.
werden mit der steigenden oder fallenden Flanke übernommen und weiter
verarbeitet
- Einsynchronisieren: Wird durchgeführt damit keine Schwebezustände an
den Flipp Flopps auftreten, es müssen immer definierte Zustände
vorliegen
- Register: kann 0 oder 1 sein, 1 Bit
- Schieberegister: hier werden 0 oder 1 bitweise durchgeschoben,
Richtung kann links oder rechts sein
Das denke ich zu den 4 Begriffen im Moment. Nun bin ich gespannt ob du
gleich vom Stuhl fällst ;-) oder mir den Code idiotensicher erklären
kannst ^^
Danke bis hierher.
s.w.
s.w. schrieb:> Ich habe jetzt bewusst nicht nach gegoogled sondern erläutere die 4> Begriffe wie ich mir das grad so vorstelle bzw. in Erinnerung habe.
Prima, das war ja auch Sinn der Sache, um einzuschätzen, was du weisst
und nicht, was du aus dem Netz schnell abgeschrieben hast ;-)
s.w. schrieb:> - Synchrones Design: alles läuft CLK gesteuert, sprich Signale etc.> werden mit der steigenden oder fallenden Flanke übernommen und weiter> verarbeitet
Genau. Also fast richtig.
Exakter wäre es so formuliert: ALLE Register arbeiten mit dem gleichen
Takt.
(Daraus ergibt sich ja dann automatisch, dass die Signale, welche ja die
Ausgänge der Register sind, sich auch genau im Takt des Taktes ändern
;-))
s.w. schrieb:> - Einsynchronisieren: Wird durchgeführt damit keine Schwebezustände an> den Flipp Flopps auftreten, es müssen immer definierte Zustände> vorliegen
Im Grundsatz nicht ganz falsch, aber bissle schwammig formuliert. Und
ich glaube, genau hier liegt dein Verständnisproblem.. dazu aber später
s.w. schrieb:> - Register: kann 0 oder 1 sein, 1 Bit
Richtig, ist aber jedes andere Signal auch ;-) Ein Register ist ein
speicherndes Element, welches immer mit der Takt-Flanke (entweder
steigende oder fallende) den Zustand, der an seinem Eingang anliegt,
speichert und auf seinem Ausgang ausgibt.
s.w. schrieb:> - Schieberegister: hier werden 0 oder 1 bitweise durchgeschoben,> Richtung kann links oder rechts sein
Richtig. Und hier würde ich noch ergänzen, dass auch das aus
hinterinandergeschalteten Registern besteht, welche alle mit dem
gleichen Takt arbeiten.
Soweit so gut.
Und nun zum Thema einsynchronisieren:
Signale, in keinem zeitlichen Bezug zum Systemtakt stehen, müssen
einsynchronisiert werden. Ein Register hat eine sogenannte Setup-Zeit.
Das ist die Zeit, in der das Eingangssignal sich nicht mehr ändern darf,
bis die steigende Taktflanke kommt.
Ändert sich der Eingang innerhalb dieser Zeit, kann man nicht
vorhersagen, was der Ausgang des Registers macht. Es kann sein, der Wert
wird übernommen, oder auch nicht, oder der Ausgang kann für eine kurze
Zeit zu Schwingen anfangen.
Und so ein Schwingen will man nicht in seinem Design haben, da das zu
Fehlverhalten führen kann.
Da aber deine Sensorsignale sich jederzeit ändern können, kann es
durchaus passieren, dass sie das gerade in dem Moment machen, wo dein
Systemtakt seine aktive Flanke hat und schon hast du lauter verrückt
spielende Register in deinem Design.
Daher "opfert" man ein Synchronisationsregister (mindestens eines pro
Signal). Auf dieses führt man das externe Signal.
Dieses Register kann dann durchaus auch anfangen, verrückt zu spielen,
aber das stört nicht, da das Register für die eigentliche Funktion
keine Aufgabe hat. Und bis zum nächsten Takt, wo dann der Ausgang dieses
Registers in das "innere" deines Designs übernommen wird, hat sich das
Register auch wieder "beruhigt".
So stellt man sicher, dass im "inneren" deines Designs nur "saubere"
Signale ankommen.
Anbei eine Skizze dessen, was dein VHDL-Code im FPGA zusammenbaut.
orange sind die Synchronisationsregister
mit den beiden grünen Registern wird die steigende Flanke des
Encoder-Signals erkannt und das graue Register ist unnötig ;-)
Und dein Verständnisproblem mit der folgenden Zeile:
1
enc_sr<=enc_sr(2downto0)&Encoder;
Der &-Operator "pappt" einfach die Bits zu einem Vektor zusammen.
man könnte es auch so hinschreiben:
Also bei jeder Taktflanke passiert folgendes:
Bit 3 übernimmt den Wert von Bit 2
Bit 2 übernimmt den Wert von Bit 1
Bit 1 übernimmt den Wert von Bit 0
Bit 0 übernimmt den Wert von Encoder
Das sieht doch aus, wie das Verhalten eines Schieberegisters, oder? :-)
Hi Schlumpf,
vielen dank für die tolle Erklärung, ich werde mir das ganze aber morgen
erst auf der Zunge zergehen lassen, bin platt heute ^^
Schönen Samstag dir.
s.w.
Guten Morgen Schlumpf,
neue Tag, neues Glück...
Ich habe mir ein paar Gedanken zu deiner sehr ausführlichen Erläuterung
gemacht und an der ein oder anderen Stelle hat es auch "klick" gemacht.
Im weiteren Verlauf gehe ich mal auf die Sachen ein die ich nicht
verstanden habe, den Rest kommentiere ich nicht mehr.
Schlumpf schrieb:>> Daher "opfert" man ein Synchronisationsregister (mindestens eines pro> Signal). Auf dieses führt man das externe Signal.> Dieses Register kann dann durchaus auch anfangen, verrückt zu spielen,> aber das stört nicht, da das Register für die eigentliche Funktion> keine Aufgabe hat. Und bis zum nächsten Takt, wo dann der Ausgang dieses> Registers in das "innere" deines Designs übernommen wird, hat sich das> Register auch wieder "beruhigt".
Das heisst der Code: " sens_sync <= Sensor;" sagt eigentlich nur aus,
dass das "bit" Sensor ins "bit" Sensor_sync weitergeschoben wird, also
nur eine bitweise Verschiebung und noch keine logische Operation? Sehe
ich das auch richtig, dass es sich hier nicht um ein Schieberegister
handelt sondern um ein einfaches Register, sprich das Signal am Eingang
wird mit der Taktflanke an den Ausgang gegeben und verharrt dort solange
bis sich der Eingang ändert?
> Anbei eine Skizze dessen, was dein VHDL-Code im FPGA zusammenbaut.> orange sind die Synchronisationsregister> mit den beiden grünen Registern wird die steigende Flanke des
OK. Angenommen ich legen ein RechteckSignal an (1 Hz, positive
Halbwelle).
1 0 1 0 1 0 1 0 1 0 (1)
Jetzt wandert die erste 1 (die in Klammern stehend) ist das enc_sr(0)
damit die nächsten beiden grünen Register also "sauber" bits bekommen.
Nun denken wir uns 2 bits weiter, dann sollten das Schieberegister
folgende Zustände aufweisen:
enc_sr(0) enc_sr(1) enc_sr(2)
1 0 1
Wie geschieht nun die Flankenerkennung im Detail? Irgend eine Logic im
FPGA (der mit dem Schieberegister verbundene Counter?!? ) liesst das
Schieberegister aus und erkennt quasi sobald das Muster "01" anliegt
muss eine positve Flanke aufgetreten sein und zählt dann cnt+1, wenn das
Muster "11" oder "00" ausgelesen wird ist natürlich keine positive
Flanke vorausgegangen und der Counter zählt auch nicht +1? Richtig
> Encoder-Signals erkannt und das graue Register ist unnötig ;-)> Und dein Verständnisproblem mit der folgenden Zeile:
enc_sr <= enc_sr(2 downto 0) & Encoder;
Wenn ich das nun verstanden haben heisst das, egal wieviel Sensoren ich
im Design angeschlossen haben die Zeile für den Sync des Encoders sieht
immer so aus:" enc_sr <= enc_sr(2 downto 0) & Encoder;" da enc_sr(2
downto 0) das Schiebegeister darstellt (bestehend aus dem Sync bit und
der Flankenerkennung)?
Nochmal für mich, ich lese von recht nach links die Zeile noch einmal in
Prosa vor: Ich komme mit der Hardwareleitung (Encoder) an meinem
Schieberegister an und das wird dann mit dem neuen Signal enc_sr via
Registerausgang verbunden?
>> Der &-Operator "pappt" einfach die Bits zu einem Vektor zusammen.> man könnte es auch so hinschreiben:enc_sr(3 downto 0) = enc_sr(2) &> enc_sr(1) & enc_sr(0) & Encoder.>> Also bei jeder Taktflanke passiert folgendes:>> Bit 3 übernimmt den Wert von Bit 2> Bit 2 übernimmt den Wert von Bit 1> Bit 1 übernimmt den Wert von Bit 0> Bit 0 übernimmt den Wert von Encoder>> Das sieht doch aus, wie das Verhalten eines Schieberegisters, oder? :-)
Puh.... nun bin ich hier soweit erstmal durch und hoffe einiges nun
besser zu verstehen, oder lag ich mit meinen Annahmen total falsch?
Eine Frage habe ich jedoch noch zu deiner vorletzten Antwort:
Du sagtest mein Code stimmt beinahe (es geht um die Sensor Erweiterung
auf 8 Stk).
Ich schreibe den Code nun so wie ich es nach deiner tollen Erklärung
verstanden und begriffen habe.
Ich glaube nun hab ich es.
Wenn ich jetzt die Zeile :" if enc_sr(2 downto 1)="01" then" in " if
enc_sr(2 downto 1)="10" then" ändere dann schaut der Counter nicht mehr
auf die steigende sondern auf die fallende Flanke?
Jut. Nun warte ich geduldig auf Feedback :-)
Schönen Sonntag noch ....
s.w. schrieb:> Wenn ich jetzt die Zeile :" if enc_sr(2 downto 1)="01" then" in " if> enc_sr(2 downto 1)="10" then" ändere dann schaut der Counter nicht mehr> auf die steigende sondern auf die fallende Flanke?
Genau! Und wenn du abfragen wuerdest:
1
ifenc_sr(2)/=enc_sr(1)then
2
...
dann wuerdest du auf eine (zeitverzoegerte wg. dem SR) beliebige Flanke
detektieren...
Hallo s.w.
ALso erstmal zu deiner Erkenntnis mit der Erkennung der negativen
Flanke. Das hast du richtig erfasst.
Und auch der von dir modifizierte Code stimmt jetzt fast.
Lass ihn doch einfach mal compilieren und schaue, was dein Compiler dazu
sagt.
Er wird sich vermutlich beschweren, dass in dieser Zeile
1
enc_sr<=enc_sr(2downto0)&Encoder;
die beiden Größen der Vektoren nicht übereinstimmen.
Du scheinst wirklich ganz grundlegende Wissenslücken in den
Basiskonstrukten von VHDL zu haben. Was ja auch kein Problem ist, wenn
du dich erst seit kurzem damit befasst.
Aber du bist sicher gut beraten, wenn du erst einmal diese Lücken
schließt. Ja, das ist dann eher graue Theorie, aber um die kommst du
nicht drumrum.
Du musst im Wesentlichen den Unterschied zwischen einer concurrenten und
einer sequential Beschreibung verstanden haben. Dann solltest du
weiterhin wissen, was ein getakteter Process ist. Du musst wissen, aus
welchen Konstrukten Register entstehen und aus welchen einfach nur
Kombinatorik entsteht.
s.w. schrieb:> Das heisst der Code: " sens_sync <= Sensor;" sagt eigentlich nur aus,> dass das "bit" Sensor ins "bit" Sensor_sync weitergeschoben wird, also> nur eine bitweise Verschiebung und noch keine logische Operation?
So eine Frage z.B. lässt halt doch vermuten, dass du enorme
Wissenslücken hast. Ein <= ist einfach nur eine Zuweisung von einem
Signal auf ein anderes. Da ist keine logische Operation dahinter.
Wirklich, s.w., tu dir selbst den Gefallen, eigne dir ein bisschen
Theorie über VHDL an, probiere die an ganz einfachen Beispielen aus und
lerne dabei.
Ich habe das Gefühl, dass du dich jetzt irgendwie durch diesen
speziellen Code beißt und versuchst, Zeile für Zeile zu verstehen, was
dir vielleicht auch gelingt, aber das WARUM wird dir dabei eher
verborgen bleiben. Du kannst dann vielleicht an der einen oder anderen
Stelle gezielt eine Veränderung des Codes vornehmen, aber ich glaube
nicht, dass du dabei wirklich kapierst, warum der Code so aufgebaut ist,
wie er ist.
Ich habe halt gerade das Gefühl, dass bei jeder Erklärung von mir neue
Fragen von dir aufkommen, die immer grundlegender werden. Da verzetteln
wir uns irgendwann.
Um mit VHDL "glücklich" zu werden musst du zum einen wenigstens die
grundlegenden Strukturen der Sprache verstanden haben, weiterhin musst
du natürlich die wesentlichen syntaktischen Elemente können und dann ist
es unverzichtbar, dass du von ganz normaler digitaler Schaltungstechnik
auch wenigstens Grundlegende Ahunung hast.
Erst wenn das gegeben ist, kannst du verstehen, wie du mit VHDL die
Dinge beschreibst, die du aus der Digitaltechnik kennst.
Hi Schlumpf,
du schreibst hier permanent das ich dies und das noch alles lernen muss
etc.... Deswegen bin ich ja hier, nenne mir ein Buch oder Tutorial was
ich durchackern kann um das zu verstehen, kein Problem. Das Buch was ich
habe
ist folgendes:
http://www.amazon.de/VHDL-Synthese-Entwurf-digitaler-Schaltungen-Systeme/dp/3486716778
ich finde es als newbie zu hart, es wird alles nur Oberflächlich
erklärt, ich denke die Studenten die den Prof. in der UNI haben werden
daran ihre Freunde haben (da sie auch seine Vorlesungen besuchen und das
Buch sicher darauf aufbaut).
Ich nutze es im Moment nur als Nachschlagewerk, fürs Selbststudium
leider ungeeignet.
>> Er wird sich vermutlich beschweren, dass in dieser Zeile enc_sr> <= enc_sr(2 downto 0) & Encoder;> die beiden Größen der Vektoren nicht übereinstimmen.
Ich bekomme keine Fehlermeldung wenn die Zeile so aussieht: enc_sr
> <= enc_sr(6 downto 0) & Encoder;
Wo kann ich bitte nachlesen warum das so ist? Oder erkläre mir das bitte
abschließend.
Danke.
s.w.
s.w. schrieb:> du schreibst hier permanent das ich dies und das noch alles lernen muss> etc....
Richtig
Und das Buch, das du in den Händen hältst, ist ein gutes Einsteigerbuch.
Wenn dir das zu hart ist, dann musst du eben noch weiter unten anfangen.
Dann brauchst du aber kein Buch über VHDL, sondern eines über digitale
Schaltungstechnik.
(nein, ich habe dazu keine Buchempfehlung)
Oder du strengst dich nicht genügend an, die Sachen zu begreifen. Hast
also nicht den Biss, dich mal selbst drum zu kümmern, warum was
funktioniert, oder auch nicht..
Aber bitte, was erwartest du denn von den Leuten hier? Dass sie dir
jetzt ein maßgeschneidertes Tutorial zusammenstricken... "vom Ohmschen
Gesetz zum ASIC-Entwurf in 30 Tagen"?
s.w. schrieb:> Ich bekomme keine Fehlermeldung wenn die Zeile so aussieht: enc_sr
....
> Wo kann ich bitte nachlesen warum das so ist? Oder erkläre mir das bitte> abschließend.
Nein, ich werde dir das nicht erklären! Nicht, weil ich böse bin,
sondern weil es zu nichts führt.
Ich habe dir bereits gesagt, WAS der Compiler anmeckern wird. richtig?
Und diese Meldung beschreibt klipp und klar, warum in dieser Zeile ein
Fehler ist.
Was soll ich dazu noch sagen? Soll ich mich wiederholen?
Ok: "Die beiden Vektoren links und rechts vom <= haben eine
unterschiedliche Größe"
s.w. schrieb:> Das Buch was ich habe ist folgendes:> http://www.amazon.de/VHDL-Synthese-Entwurf-digitaler-Schaltungen-Systeme/dp/3486716778> ich finde es als newbie zu hart, es wird alles nur Oberflächlich erklärt
Das war das Buch, mit dem ich FPGAs überhaupt mal kapiert habe. Es ist
recht überschaubar geschrieben und sicher auch für Einsteiger zu
verstehen. Natürlich darfst du es nicht einfach nur lesen. Du musst es
auch verstehen. Und dazu brauchst du ebenso natürlich
Grunlagenkenntnisse mit digitaler Hardware. Schließlich ist VHDL eine
Hardware Beschreibungssprache. Du musst also schon im Voraus ein
"Bild" oder eine "Skizze" haben, um etwas beschreiben zu können (oder
es dir wenigstens vorstellen können).
s.w. schrieb:> Wenn ich jetzt die Zeile :" if enc_sr(2 downto 1)="01" then" in " if> enc_sr(2 downto 1)="10" then" ändere dann schaut der Counter nicht mehr> auf die steigende sondern auf die fallende Flanke?
Vorab: der Counter "schaut" nirgendwohin...
In diesen Vektor enc_sr (der nichts anderes ist, als eine
Hintereinanderschaltung von 3 Flipflops) wird mit jedem Takt ein neues
Bit hineingeschoben und die zwei vorigen um eine Stelle nach links
gerückt. Und dann werden die beiden linken Bits auf den Zustand "01"
abgefragt. "01" bdeutet ja, dass da irgendwann in der Vergangenheit eine
0 und danach eine 1 eingetaktet wurden. Und ein Zustandswechsel von 0
nach 1 ist die steigende Flanke.
Siehe das dort:
http://www.lothar-miller.de/s9y/categories/18-Flankenerkennungs.w. schrieb:> enc_sr <= enc_sr(1 downto 0) & Encoder;> Vielleicht hast du noch mal die Lust mir das zu erklären. Finde die> Abkürzung auch in meinem Vhdl nirgends.
In dem Buch steht aber sicher, was der '&'-Operator in VHDL macht: er
ist ein Verkettungs-, Verknüpfungs- oder "Anhänge"-Operator. Er fügt
einfach mehrere einzelne Bits oder Vektoren zu einem längeren Verktor
zusammen.
Und zur Funktion der Zeile steht im ersten Originalcode von mir noch ein
Kommentar dahinter. Sieh dir mal den
Beitrag "Re: 2 Phasen Takt, Wegimpulsverzögerung" an.
Und mit genau diesem Kommentar als Suchbegriff in Google findest du dann
leicht selber was:
https://www.google.de/search?q=Schieberegister+zum+Einsynchronisieren+und+für+die+Flankenerkennung
Und um nach dieser langen Schleife wieder auf dein ursprüngliches
Problem zurückzukommen:
Ich bin überzeugt, dass irgendwas mit deinem Sensorsignal nicht stimmt.
(Sensor 0)
Entweder falsche Pegel, oder es oszilliert oder oder oder
Hast du das zwischenzeitlich mal ausgeschlossen, indem du es
nachgemessen hast?
Wie hoch ist dein Systemtakt?
Schlumpf schrieb:> Und um nach dieser langen Schleife wieder auf dein ursprüngliches> Problem zurückzukommen:> Ich bin überzeugt, dass irgendwas mit deinem Sensorsignal nicht stimmt.> (Sensor 0)> Entweder falsche Pegel, oder es oszilliert oder oder oder>> Hast du das zwischenzeitlich mal ausgeschlossen, indem du es> nachgemessen hast?
Das kann ich leider momentan nicht nachprüfen da ich mich im Urlaub
befinde. Ich habe mir gestern die aktuelle Xilinx Version besorgt und
versuche nun hiermit den Code zu simulieren (hoffentlich kann man hier
leichter eine Testbench erstellen als in Modelsim).
Ich kann mir eigentlich auch nicht vorstellen, dass mit dem Signal etwas
nicht stimmen soll, 100% ausschließen natürlich auch nicht. Es kommt ein
24 V Signal von einem optischen Sensor auf ein Optokoppler 24/3.3 und
der Ausgang geht an mein De0-nano. Die LED leuchtet auch sobald der
Sensor schaltet, das Signal am Ausgang habe ich jedoch nicht gemessen
(werde ich aber nachholen).
Hast du denn den Code in einer Simulation getestet? Hat es da so wie
beschrieben funktioniert?
> Wie hoch ist dein Systemtakt?
50 Mhz
s.w. schrieb:> Hast du denn den Code in einer Simulation getestet? Hat es da so wie> beschrieben funktioniert?
Ne, habe ich im Kopf simuliert... sollte passen.
Ich bin verblüfft wie viel angenehmer es sich mit Xilinx arbeitet. Das
ist ja um Welten einfacher, die Testbench ist ja quasi schon fertig bis
auf das Timing der Sensor Inputs. Ich halte euch auf dem Laufenden...
Die Simulation läuft und macht genau das was sie soll, vielen dank an
Schlumpf und euch anderen für die tolle Hilfe.
Frage an die Profis: Ist das Don´t care bit wirklich nicht
synthetisierbar?
Ist es tatsächlich ein Unterschied bei den folgenden Abfragen?
1
ifsens_sync(12downto0)="01110--------"then...
2
ifsens_sync(12downto8)="01110"then...
Für mich als Leien sollte es doch das gleiche sein.
schönen abend
s.w.
s.w. schrieb:> Ist das Don´t care bit wirklich nicht synthetisierbar?
Sieh dir das Manual zum Synthesizer, den "XST Users Guide" an, da steht
es drin:
Es ist (teilweise) synthetisierbar. Allerdings stimmt dann die
Simulation nicht mehr. Denn das "don't care" ist kein "ignore". Und für
die Simulation ist ein "01110--------" somit etwas ganz anderes als z.B.
ein "0111000001111".
Das
Lothar Miller schrieb:> s.w. schrieb:>> Ist das Don´t care bit wirklich nicht synthetisierbar?> Sieh dir das Manual zum Synthesizer, den "XST Users Guide" an, da steht> es drin:
Das ist ja mal ne feine Lektüre, sowas habe ich schon lange gesucht,
super TIPP !!!!
> Es ist (teilweise) synthetisierbar. Allerdings stimmt dann die> Simulation nicht mehr. Denn das "don't care" ist kein "ignore". Und für> die Simulation ist ein "01110--------" somit etwas ganz anderes als z.B.> ein "0111000001111".
Ich habe das don´t care so verstanden, dass egal welche bits nach
"01110--------" auch kommen der Ausgang wird geschaltet.
Wie würdest du denn einen Vector mit 15 bit auslesen wo dich nur bit 9
bis 4 interessieren? einfach nur so: if sens_sync(9 downto 4)="011101"
then ... ?
Ist das so gängig oder gibt es noch einen anderen Weg?
Hallo,
ich habe nochmal eine Frage. Und zwar möchte ich logische Werte aus
einem 16 bit Vector auslesen. Bei dieser Abfrage interessieren mich nur
die Vektoren 15 downto 14 und 8 downto 7
Jetzt habe ich mir gedacht ich kann das ganze wie folgt abfragen:
if sens_sync(15 downto 14)="11" & sens_sync(8 downto 7)="10" then
Das geht leider nicht und Xilinx haut mir ein paar Fehlermeldungen um
die Ohren :"Syntax error near "="
Kann mir jemand sagen was an der Abfrage bitte falsch ist?
vielen Dank
s.w.
Lothar Miller schrieb:> C ist nicht VHDL, und deshalb ist "&" nicht "AND"...
ich habe es auch mit "and" und "+" versucht, geht alles nicht...
und laut Vorlesung ... sollte es doch gehen, siehe:
https://www.uni-ulm.de/fileadmin/website_uni_ulm/iui.inst.050/vorlesungen/sose08/LaborpraktikumEingebetteteSysteme/Material/Crashkurs_VHDL.pdf
c <= a(0) & “001“; -- Zusammensetzen mit &
2.3.2 Zuweisungen und Verknüpfungen
Mit Vektoren ist es besonders einfach, mit nur einer Anweisung parallel
eine Operation auf
alle Einzelsignale (oder eine Teilmenge davon) auszuführen Einige
Beispiele zeigt Tabelle 3.
Tabelle 3: Arbeiten mit Vektoren
signal a,b,c: bit_vector(0 to 3); -- Deklaration dreier Vektoren
c <= a or b; -- bitweises oder auf alle Elemente
c <= (’1’,’0’,’0’,’0’); -- Zuweisung als Aggregat
c <= “1000“; -- Zuweisung als Bitstring
c <= x“A“; -- Zuweisung als Hexadezimalzahl
c <= a(0) & “001“; -- Zusammensetzen mit &
c(1 to 2) <= “11“; -- Auswahl eines Teilvektors im Ziel
c <= a(0 to 1) & ’1’ & b(0); -- Auswahl eines Teilvektors in der Quelle
(w,x,y,z) <= c; -- Zuweisung von c an Einzelsignale w,x,y,z
Ziel VHDL-Kommando
c(0) c(1) c(2) c(3)
a(0) or b(0) a(1) or b(1) a(2) or b(2) a(3) or b(3) c <= a or b;
1 0 0 0 c <= (’1’, ’0’, ’0’, ’0’);
1 0 0 0 c <= “1000“;
1 0 1 0 c <= x“A“;
a(0) 0 0 1 c <= a(0) & “001“;
unverändert 1 1 unverändert c(1 to 2) <= “11“;
a(0) a(1) 1 b(0) c <= a(0 to 1) & ’1’ & b(0);Crashkurs V1.2 - 8 - Prof.
Dr. Hermann
Beachten Sie dabei besonders, dass Sie sich sowohl aus dem Ziel als auch
aus der Quelle
jeweils Teile herausgreifen können und dass Sie Teile mit ‚&’ zu
breiteren Vektoren
zusammensetzen können. Sie müssen lediglich darauf achten, dass die
Gesamtbreite von Ziel
und Quelle bzw. Quellen jeweils gleich ist. Speziell bei der Zuweisung
konstanter Werte
sehen Sie, dass Sie auch eine Darstellung als Hexadezimalzahl mit
x“zahl“ bzw. als Oktalzahl
mit o“zahl“ wählen können. Die angegebene Zahl wird dabei in einen
Vektor mit binären
Einzelwerten umgerechnet.
Sie können bei der Zuweisung konstanter Werte den Unterstrich zur
besseren Kennzeichnung
von zusammengehörenden Gruppen verwenden. Er hat aber sonst keine
Bedeutung, d.h. er
vertritt keine Position im Vektor. Falls Sie in einem Vektor alle bisher
nicht belegten
Positionen (d.h. Einzelsignale) mit demselben Wert belegen wollen, dann
können Sie das
Kommando (others => ’wert’) verwenden (Abbildung 7).
signal c: bit_vector(0 to 7);
c <= “01001001“; -- diese und die beiden folgenden
c <= “0100_1001“; -- Zuweisungen haben gleiche Wirkung
c <= x“49“;
c <= (others => ’0’); -- allen Einzelsignalen von c wird ’0’
-- zugewiesen
Warum geht das in meinem Fall nicht?
Das geht:
if sens_sync(15 downto 14)="11" and sens_sync(8 downto 7)="10" then...
Es ginge auch so was:
if sens_sync(15 downto 14) & sens_sync(8 downto 7) = "1110" then...
Im ersten Fall werden die zwei Vektorabschnitte verglichen und das
Ergebnis des Vergleichs verUNDet. Im zweiten Fall werden 2 Stück 2
Bit-Vektoren zusammen gehängt (mit &) und mit einem 4 Bit Vektor
verglichen. Das Verhalten ist in beiden Fällen das gleiche.
s.w. schrieb:> ich habe es auch mit "and" und "+" versucht, geht alles nicht...
Und warum nicht mit and? Welche Fehlermeldung gibt es dabei?
Lothar Miller schrieb:> Das geht:> if sens_sync(15 downto 14)="11" and sens_sync(8 downto 7)="10" then...>> Es ginge auch so was:> if sens_sync(15 downto 14) & sens_sync(8 downto 7) = "1110" then...>> Im ersten Fall werden die zwei Vektorabschnitte verglichen und das> Ergebnis des Vergleichs verUNDet. Im zweiten Fall werden 2 Stück 2> Bit-Vektoren zusammen gehängt (mit &) und mit einem 4 Bit Vektor> verglichen. Das Verhalten ist in beiden Fällen das gleiche.>> s.w. schrieb:>> ich habe es auch mit "and" und "+" versucht, geht alles nicht...> Und warum nicht mit and? Welche Fehlermeldung gibt es dabei?
Hi Lothar,
das hat nun geklappt, der Fehler bei mir war, dass an stellen von "then"
am Ende der Zeile ein "or" was die nächste Abfrage quasi einleitete.
jetzt wollte ich folgendes abfragen:
if sens_sync(15)="0" and sens_sync(8)="1" then
das geht nun auch wieder nicht, ich kann auch nirgends mal was finden wo
genau steht was ich wie abfragen kann und wo die Tücken sind.
Warum geht das nun wieder nicht ?!?
Ich verzweifel echt langsam .....
s.w. schrieb:> Warum geht das nun wieder nicht ?!?> Ich verzweifel echt langsam .....
Hör endlich auf, einfach nur ziellos rumzuprobieren!
TIPP:
"x" vs. 'x'
Schlumpf schrieb:> s.w. schrieb:>> Warum geht das nun wieder nicht ?!?>> Ich verzweifel echt langsam .....> Hör endlich auf, einfach nur ziellos rumzuprobieren!>> TIPP:> "x" vs. 'x'
Danke für den Tipp und nein ich werde nicht aufhören, es wird von Tag zu
Tag besser ...
s.w. schrieb:> nein ich werde nicht aufhören, es wird von Tag zu Tag besser ...
Diese Strategie ist recht zermürbend. Man muss nicht jeden klitzekleinen
Fehler selber machen und/oder im Froum beantworten lassen. Nimm einfach
ein Buch, da steht das, was du gerade umständlich durchmachst auf den
ersten paar Seiten drin...
Thread beobachten
Seitenaufteilung abschalten