Betriebsblind

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.