Hallo Ich habe einen 8 bit Datenbus. Dieser bringt regelmäßig eine Bitfolge von FF 00 00. Wie kann ich mit einer, sagen wir mal, If anweisung prüfen ob diese Bitfolge kommt? MfG
2 Buffer in für die Bytes n-1 und n-2, bei neu empfangenem Datenbyte n die if-Abfrage, wenn Bedingung nicht erfüllt wird alles wieder in Buffer schieben, n-1 zu n-2 und n zu n-1.
das versteh ich nicht...ich würde es so schreiben. variable trigger1 : integer :=0; variable Bus : out std_logic_vector(7 downto 0); If (Bus = x"FF" and Bus = x"00" and Bus = x"00") then trigger1 := 1; end If;
Hallo Wie kann denn Bus gleichzeitig 00 und FF sein? Die "alten" Zustände mußt du zwischenspeichern. Siehe X-Rocka. Gruß Joachim
also quasi so: temp1 := bus(7 downto 0); temp2 := bus(7 downto 0); temp3 := bus(7 downto 0); If (temp1 = x"FF" and temp2 = x"00" and temp3 = x"00") then trigger1 := 1; end If;
Martin schrieb: > also quasi so: Mal ohne die Zeitlichen Abläufe zu betrachten: eigentlich ja. Aber...! Du wirst damit aber nicht glücklich werden, denn an dem Bus werden niemals alle Bits gleichzeitig umschalten, und deshalb kannst du durchaus sowas bekommen: FF FF 3E 00 00 oder beliebige andere Zustände... Und was machst du dann? Fazit: du brauchst eigentlich irgendein Signal, das sagt, wann die Pegel auf dem Bus stabil sind. Und nur zusammen mit diesem Signal kannst du dann stabile und gültige Zustände einlesen.
... und warum benutzen hier neuerdings alle (die vermutlich gerade mit VHDL anfangen) Variablen? Find' ich sch$%^^$ und eigentlich zeigt es, dass man HW-Design nicht wirklich versteht...
berndl schrieb: > ... und warum benutzen hier neuerdings alle (die vermutlich gerade mit > VHDL anfangen) Variablen? Wenn man sich die durchschnittlichen Vorlesungen zu VHDL an den Uni's ansieht erklärt sich so manches, ...
D. I. schrieb: > Wenn man sich die durchschnittlichen Vorlesungen zu VHDL an den Uni's > ansieht erklärt sich so manches, ... Oh Mann, dann sollten die Profs mal schnell den Googleberg machen...
aber um dem TO mal ein praktisches, millionenfach erprobtes Beispiel zu geben:
1 | sklaventreiberprozess: process (sklaventreiberwillvielleichtwas) |
2 | begin
|
3 | wait until rising_edge (sklaventreiberwillvielleichtwas); |
4 | if dawilleinerwas = '1' then |
5 | waswillerdenn <= bus (7 downto 0); |
6 | waswollteervorher <= waswillerden; |
7 | koennteesseindass <= waswollteervorher; |
8 | bingo <= '0'; |
9 | if waswillerdenn = x"00" and |
10 | waswollteervorher = b"0000_0000" and |
11 | koennteesseindass = "11111111" then |
12 | bingo <= '1'; |
13 | end if; |
14 | end if; |
15 | end process; |
Mist, und das 'waswillerdenn' sollte eigentlich := sein und damit eine Variable...
berndl schrieb: > und warum benutzen hier neuerdings alle > (die vermutlich gerade mit VHDL anfangen) Variablen? Ich meine, irgendwo ein "Kochrezept" (in Form eines Buches) gesehen zu haben, wo die (annähernde) 1:1 Übersetzung von C nach VHDL mit Hilfe von Variablen erklärt wird. Das ist zwar ein durchgehend bescheuertes, aber offenbar sehr erfolgreiches Konzept... :-/ In der Praxis gefallen Anfängern Variablen deshalb so gut, weil sie sich "anfühlen" wie Variable in einer Programmiersprache: sofort nach der Zuweisung ist der Wert "übernommen". Logisch, dass die dann recht bald auf die Nase fallen und die Welt nicht mehr verstehen... berndl schrieb: > Mist, und das 'waswillerdenn' sollte eigentlich := sein Es geht auch ohne:
1 | sklaventreiberprozess: process (sklaventreiberwillvielleichtwas) |
2 | begin
|
3 | wait until rising_edge (sklaventreiberwillvielleichtwas); |
4 | if dawilleinerwas = '1' then |
5 | waswillerdenn <= bus (7 downto 0); |
6 | waswollteervorher <= waswillerden; |
7 | koennteesseindass <= waswollteervorher; |
8 | end if; |
9 | end process; |
10 | |
11 | bingo <= '1' when waswillerdenn = x"00" and |
12 | waswollteervorher = b"0000_0000" and |
13 | koennteesseindass = "11111111" |
14 | else '0'; |
Man könnte das auch mit einer FSM machen, sollte registersparender sein.
Naja, wenn es sauber sein soll, dann wie von Lothar beschrieben. Braucht 24 FlipFlops und ein paar LUTs für den Vergleich. Wo soll man da Register einsparen?
D. I. schrieb: > Man könnte das auch mit einer FSM machen So etwa:
1 | signal treffer : integer range 0 to 2; |
2 | |
3 | sklaventreiberprozess: process (DasValidierungssignal) |
4 | begin
|
5 | wait until rising_edge(DasValidierungssignal); |
6 | bingo <= '0'; |
7 | if treffer = 0 then |
8 | if bus = x"ff" then treffer <= 1; |
9 | end if; |
10 | elsif treffer = 1 then |
11 | if bus = x"00" then treffer <= 2; |
12 | else treffer <= 0; |
13 | end if; |
14 | elsif treffer = 2 then |
15 | treffer <= 0; |
16 | if bus = x"00" then |
17 | bingo <= '1'; |
18 | end if; |
19 | end if; |
20 | end process; |
Und dann gibt es noch mindestens 31 andere Wege... Christian R. schrieb: > Wo soll man da Register einsparen? Die Idee mit der FSM ist gar nicht mal so schlecht... ;-) Allerdings sollte man jetzt noch darauf achten, dass DasValidierungssignal evtl. nicht synchron zum restlichen FPGA ist...
Lothar Miller schrieb: >> Wo soll man da Register einsparen? > Die Idee mit der FSM ist gar nicht mal so schlecht... ;-) Hm stimmt, ich hatte gleich wieder eine Latch-Schweinerei vermutet. Schlimm, wenn man immer vom schlimmsten ausgeht. Für einen CPLD ist sowas sparsames sicherlich sinnvoll. Dann nehm ich alle bösen Vermutungen zurück ;)
Oh weh da hab ich ja was angestellt... zum Thema Variablen udn VHDL allgemein. Meine VHDL Vorlesung lief wie folgt: Bauen Sie eine digitale Weckuhr die folgendes kann. Dort ist die Bibliothek die haben VHDl Bücher. Abgabe in 9 Wochen. Das war die Vorlesung. Das Wissen kommt von Reichardt | Schwarz => VHDL Syntehese was ich mir angelesen habe. So nun wisst ihr erstmal wie der Sach- und Kenntnisstand ist. Nun zum Thema. Ich will mit der Abfrage der Bitfolge einen Startwert setzen. Wenn der Wechsel von FF 00 00 AB zu FF 00 00 9D kommt, soll er sich das merken. Dieser Wechsel ist das erste Pixel im sichtbaren Bereich des 1. Halbbildes in eine ITU 656 Videodatenstrom.
Das erklärt aber noch nicht folgendes: Woher kommt der Takt? Woran erkennst du, dass auf dem Bus gerade ein gültiges Datum anliegt?
das Problem beim Bytewechsel prüfen ist, dass ich ein OUT Signal wohl nicht prüfen kann er meckert dann und sagt: Error (10309): VHDL Interface Declaration error in build_itu.vhd(428): interface object "ITU_OUT" of mode out cannot be read. Change object mode to buffer. Error: Quartus II Analysis & Synthesis was unsuccessful. 1 error, 6 warnings Error: Peak virtual memory: 189 megabytes Error: Processing ended: Fri Mar 04 08:13:02 2011 Error: Elapsed time: 00:00:09 Error: Total CPU time (on all processors): 00:00:08
Nein auf einem out kann man nicht lesend zugreifen. Das löst man üblicherweise über ein internes Signal, dies kannst du dann lesen und schreiben und dieses Signal gibst du auf den out. Dazu kannst du das deklarierte TMP_ITU verwenden. Ersetze alle ITU_OUT durch TMP_ITU und gib TMP_IPU concurrent an ITU_OUT aus. Aber in dem Code ist ja mal wieder alles enthalten was den Anfänger garantiert bumsen wird... Von der Verwendung der alten Synopsis-Lib über Variablen bis hin zum asycnhronen Reset. Na Prost Mahlzeit.
Waaahnsin... :-o Was man heutzutage nicht alles in einen (in Zahlen 1) Prozess packen kann! Das passiert, wenn diese Variablen, die ja nur im Prozess sichtbar sind) gehäuft ins Spiel kommen. In der Praxis bewährt es sich, mehrere Prozesse zu verwenden. Der Hacker (oder der C-Umsteiger) käme jetzt auf die Idee, Shared Variables zu nehmen, die dann global sichtbar sind, um diese Aufteilung in mehrere Prozesse zu ermöglichen... :-/ Martin schrieb: > ...ja so ist das wenn man sich fast alles selber anliest... :) Naja, ich denke eher, der Schritt von einer Uhr zu diesem ITU-Dingens ist einfach zu groß. Und gerade bei VHDL kommt das "Gefühl", ob was funktionieren könnte oder nicht, nur aus der Praxis, nicht aus Büchern. Also: Üben, üben, üben...
so ich habs mal umgeschrieben... If (ITU_TEMP = "11111111") then trigger1 := 1; If (trigger1 = 1 and ITU_TEMP = "00000000") then trigger2 := 1; If (trigger1 = 1 and trigger2 = 1 and ITU_TEMP = "00000000") then trigger3 := 1; If (trigger1 =1 and trigger2 = 1 and trigger3 = 1 and ITU_TEMP = "10101011") then trigger4 := 1; Elsif (trigger1 = 1 and trigger2 = 1 and trigger3 = 1 and ITU_TEMP = "10011101") then trigger5 := 1; End If; End If; End If; End If; If (trigger4 = trigger5) then picture_clk := 1; else picture_clk := 0; End If; Kann ich mir mit SignalTap die Zustände von trigger 1 - 5 und picture_clk anzeigen lassen?
könnte ich nicht auch einen 40 Bit vector erstellen, der dann gleich die Bitreihenfolge prüft. variable ITU_TEST : std_logic_vector (39 downto 0); variable ITU_TEMP : std_logic_vector (7 downto 0); ITU_TEST < ITU_TEMP; If (ITU_TEST = "11111111000000000000000010101011"= then trigger := 1; else trigger := 0; End If;
Martin schrieb: > Kann ich mir mit SignalTap die Zustände von trigger 1 - 5 und > picture_clk anzeigen lassen? Vielleicht verwendest Du erstmal einen Simulator und bringst es dort richtig zum Laufen, ehe das Design auf die Hardware kommt?!? Duke
...kaputt machen kann man ja nix...also ab auf die HW...meine Erfahrung zu Simulationen...kosten Zeit uns Nerven und auf der HW läufts dann doch immer anders... Und zu meiner Frage...ja man kann die trigger ausgeben...:)
Martin schrieb: > kaputt machen kann man ja nix...also ab auf die HW So wird heutzutage Software gemacht... Martin schrieb: > .meine Erfahrung zu Simulationen...kosten Zeit uns Nerven > und auf der HW läufts dann doch immer anders... Mag sein... Aber dann weißt du wenigstens, ob es überhaupt gehen könnte... :-/
...das zeigt mir die HW aber schneller als wenn ich die Testbench jedesmal anpassen muss. :-)
Martin schrieb: > ...das zeigt mir die HW aber schneller als wenn ich die Testbench > jedesmal anpassen muss. :-) Ja du bist schlauer als die geballte Forenkompetenz hier und die gesamten VHDL-Entwickler, das hast du schon sehr zur Schau gestellt. Jedoch was machst du wenn Synthesen mal 4 Stunden oder gar Tage dauern? Na dann Prost Mahlzeit
D. I. schrieb: > Jedoch was machst du wenn Synthesen mal 4 Stunden oder gar Tage dauern? So weit kommt es nicht. Mit seiner Kompetenz ist er schon viel früher in die Leitungsebene aufgestiegen [1]. Wenn nicht sogar zum CTO. Duke [1] http://de.wikipedia.org/wiki/Peter-Prinzip
Duke Scarring schrieb: > D. I. schrieb: >> Jedoch was machst du wenn Synthesen mal 4 Stunden oder gar Tage dauern? > > So weit kommt es nicht. Mit seiner Kompetenz ist er schon viel früher in > die Leitungsebene aufgestiegen [1]. Wenn nicht sogar zum CTO. > > Duke > > [1] http://de.wikipedia.org/wiki/Peter-Prinzip ehehehe, vorausgesetzt er sieht eine Firma von innen :D
4 stunden synthese...püh...für modelsim muss ich das projekt ja auch nur komplett compilieren....immer dieses sinnlose rumsimulieren Hey ich will kein programmierer werden nur meine sinnlose abschlußarbeit fertig machen. Zum programmierenden kellerkind sind andere geboren. LOL
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.