Hallo, laut meinem Compiler werden im angehängten VHDL Programm die Inputs <<clock>> und <<busyadc>> nicht verwendet ... was ich nicht nachvollziehen kann. Bin wohl mittlerweile betriebsblind, sehe den Fehler einfach nicht. Falls irgend jemand einen Fehler entdecken kann --- großartig :o) Ich werde ebenfalls weiter tüfteln ... Sämtliche Erläuterungen spar ich mir ersteinmal, wenn Fragen auftauchen, bitte stellen. MfG Sebastian
In den Zeilen elsif count=17 and busyadc<='0' then und elsif count>=34 and busyadc<='0' then wird busyadc kleiner gleich '0' verglichen. Ich weiss nicht genau, kann das Signal vom Typ std_logic kleiner '0' werden? Da gibts glaube ich nur noch schwache 0 (L), aber die kann nicht kleiner 0 werden.
...der Vergleich auf gleich '0' ändert an dem angeblich nicht verwendeten Input leider nichts.
Die Deklaration der Signale
signal clock1: std_logic;
signal systemzeit,zeitpunkt: integer range 0 to 1000000000;
signal
Wert_Druck,Wert_Feuchte,Wert_Druck_Vorwahl,Wert_Feuchte_Vorwahl:
bit_vector(0 to 11);
signal count : integer range 0 to 34;
signal count1 : integer range 0 to 1334;
steht in der entity-Deklaration, hm, das habe ich noch nie gesehen.
Wundert mich jetzt auch, dass es überhaupt so geht...
Und was passiert, wenn du die Signale an der gewohnten Stelle in der
architecture deklarierst?
...den punkt der signaldeklaration schau ich mir noch einmal an, da hast du wohl recht. das war aber nicht das problem. ich hatte count und count1 in den beiden if schleifen nicht durchgehend korrekt bezeichnet ... definitiv betriebsblind :o)
Hallo Sebastian, ich kann nicht genau nachvollziehen was da passieren soll. Kann es sein, daß die ganze Logik wegoptimiert wird? Wie sieht es in der Simulation aus? Irgendwie könnten ja die Inputs garkeinen Einfluß auf die Outputs haben. Führe doch mal clock1 auch mal raus und gucke was passiert. Viele Grüße TobiFlex
Deine Prozedur ist falsch. Du benutzt sie wie ein Makro. Kompiliert der das bei Dir überhaupt? Ersetz mal überall Dein AUS mit den tatsächlichen Signalzuweisungen und dann sollte es laufen. Tut es bei mir zumindest, mit Xilinx Webpack.
Beschreib mir mal bitte etwas genauer was du mit wegoptimieren meinst ... zur simulatiom ... ich teste das programm direkt auf dem entwicklungsboard und oszilloskopiere alle interessanten signale.
...ja, da gibt es wohl noch ein paar unstimmigkeiten, der takt schaut nicht wirklich wie erwartet aus ...
count1 wird nicht genutzt count erzeugt einen Takt clock1 der wiederum count zählen lässt. Das gibst net. somit fliegt alles was clock treibt raus und clock is unused. Bitte nur ein *_edge pro Process. Da wirst du zwar Fehlermeldungen bekommen, aber da sind wirklich fehler (dieser selbstreiber von oben). Einen Process für den Takteiler clock -clock1 und einen für clock1. Dann wirst du bestimmt die Warening gated clock bekommen. Das ist schlecht aber erst mal OK.
...mit angehäntem programm läuft der Takt wie gewünscht. die messung der ausgangssignale <<cs>> <<rd>> <<convst>> und <<clockad>> entspricht meinen vorstellungen. trotz zweier edges in einem prozess ...
OK, dann kommt die Synthese mit den 2 Flanken zurecht. In der Simu sind aber getrennte Prozesse für jede Flanke schneller. Ich hab den Code geändert und angehängen: -beautify durch emacs VHDL mode für bessere Lesbarkeit -counter in eignes if then konstrukt -> meist kleiner und schneller -für inkrementierende Variablen brauchst kein größer/kleiner -> kleineres design -bei *adc ungleich '0' läuft dein counter über -> gefixed - <'0' meint `u` und `x` -> gibts net in echt, also vergleich auf '0' Das *adc Signal sollte durch mind. zwei FF gehen, das zweite Taktnetzwerk für den 0... 43 counter kann man sich auch sparen. Aber dazu vielleicht später
Vielen Dank der Mühe. Ich komme jetzt erst dazu, mir das einmal anzuschauen und zu testen. ... bis dahin ...
...hm, der Grundtakt sieht sehr sauber aus. beim zweiten counter gibt es jedoch genau so schwankungen, wie auch bisher, soll heißen, er springt, mal nen taktzyklus mehr und mal einen weniger.
@Sebastian woraus schließt Du, dass der 2. Counter springt ? Du kannst ihn von außen doch gar nicht messen. Die Outputs sind alle irgendwie von busyadc abhängig, also Du müsstest busyadc auf 0 legen und dann z.B. switch messen, welches dann für 18 Takte 0 sein sollte und den Rest der Zeit 1. Dieses Signal müsste auf einem Scope ein stabiles Rechteck bringen mit entspr. Duty-Cycle, dann läuft der Counter auch.
...ich messe die signale rd und switch (z.b.), erhalte auch stabile rechtecke aber: bei rd erscheint jedes zweite rechteck doppelt, bei genauerer auflössung kann man erkennen,dass es mal nach 17 und mal nach 18 takten auf null fällt. das signal swich hingegen ist ein tadelloses rechteck. einen messfehler/bzw. messungenauigkeiten schließe ich nicht aus ... ?!
ist busyadc nun konstant oder mit dem ADC-Signal verbunden? der Unterschied ist ja: das Timing von switch ist nicht von busyadc abhängig, das von rd aber sehr wohl! Also wenn switch sauber ist, gehe ich davon aus, dass die Logik im CPLD/FPGA läuft
...sie läuft sehr wohl, vielleicht, ich kann ja auch den 30kHz takt einwandfrei messen, mich stören halt nur die sprünge. vielleicht sollte ich sie aber auch ein fach nur als messungenauigkeit deklarieren ...
ich hab mal einen neuen Code drangehangen. Da läuft alles auf einem Takt und das adc Signal wird einsynchronisiert. Allerdings dürfte bei dem Code rd zweimal auf '1' gehen und meistens auf '0' stehen. So wie im Ursprungscode.
Sehr schön! zu der Synchronisierung: die entzieht sich,mir als neuling in sachen programmierung vorallem in vhdl, meinem verständnis. die erste der beiden signalzuweisungen geht klar, busyadc(0) wird der wert des eingangssignals zugewiesen. doch dann, welche zustand hat der bitvektor (2 downto 0) ... bit(0) ist null, und die anderen beiden bits? sind doch eigentlich nicht definiert, oder? ja, du siehst, ich kann der synch nicht ganz folgen :o(
Da kein PowerUp reset vorhanden ist, ist am Anfang der vector wirklich undefiniert. Da er wie ein schieberegister wirkt, (in jedem Takt wandert der eingelesene Zustand von adc um ein FF), füllt er sich langsam mit dem Wert von ADC. Warum der Spass? Nun ich nehme an, das busyadc irgendwann ändert, also auch genau zu dem Zeitpunkt in dem clk wechselt. Also zu dem Zeitpunkt in dem sich die Logik entscheiden muss, ob busy_adc '0' oder '1' ist. Das geht dann meistens schief und führt zum sogenannten Metastabilen Zustand. Dieser wird meist nach einigen psec oder nsecs stabil, aber bis dahin reisst es auch die folgenden FF in den metastabilen oder falschen Zustand. Deshalb sollte einige Zeit vor und nach der Taktflanke (Setup- und Holdziet) busyadc seinen wert nicht ändern. Ich geh mal davon aus, das das hier nicht geht da busyadc ungetaktet in den fpga geführt wird. Deshalb die schiebekette. Wird das Timing verletzt (also setup und holdzeit) flippt das erste FF (sync(0)) aus. Falls es weidererwarten länger als eine Taktperiode zum normal werden braucht, reisst es das zweite FF sync(1) in den metastabilen. dieses zweite sollte sich dann aber bald fangen, so dass ab sync(2) richtige werte stehen. der Vergleicher auf "00" garantiert nun, das durch das einsynchronisieren enstandende Spikes (Nadelimpulse auf '1' oder '0') ausfeiltert werden. Letzlich garantiert (zu 99,9999...%) der synchronisier, das die Logik a) stabile werte sieht b) ein externer Wechsel (z.B. ... '1' -> '1' -> '0' -> '0' ...) auch als solcher intern ankommt und nicht zu z.B. ... '1' -> '0' -> '1' -> '0' -> '0' .. mutiert. Insbesondere bei statemschiense sollte man alle von extern eintreffenden Signale über FF Schieberegister einsynchronisieren, da sonst die Gefähr des Festhängens der FSM in einem illegalen state besteht.
@ FPGAküchle: gibt es auch einen guten synchronisierer für ins fpga eingeführte externe Takte?!? ich habe die takte über 3 ff und der höheren ff-clock eingetaktet, bekomme aber wohl noch skews. wie kann ich die metastabilen zustände des ersten ff umgehen?!? die externen signale sind auch asynchron zur höheren ff-clock.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.