Zähler bei jedem event erhöhen

[Andi Z. (duderino65)]

Guten Tag,

hab nun n neues Problemchen.

Ich habe ein Signal welches einen bestimmten Takt hat. Ich möchte nun 
das meine Integer Variable bei jedem Event hochgezählt wird.

Wenn ich nun schreibe:

entity:
LRCK_IN : in std_logic;
...

arch:
signal CH_CNT : integer range 1 to 4 := 1;
...

wait until LRCK_IN'event and (LRCK_IN = '1' or LRCK_IN = '0');
                                if CH_CNT = 4 then
          CH_CNT <= 1;
        elsif CH_CNT < 4 then
          CH_CNT <= CH_CNT + 1;
        end if;

...meldet der Compiler einen Fehler. Ist ja verständlich das es so 
sinnlos ist weil der letzte Ausdruck immer 1 ist. Nur wie kann ich denn 
nun so hochzählen lassen das er bei jedem Wechsel zählt??

MfG

Andi

[Schrotty (Gast)]

Die Zeile

wait until LRCK_IN'event and (LRCK_IN = '1' or LRCK_IN = '0');

würde bedeuten, dass du ein FF brauchst, das mit steigender UND 
fallender Flanke schaltet. Und sowas gibt es nicht!

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

> Und sowas gibt es nicht!
DDR-FFs?

> Nur wie kann ich denn nun so hochzählen lassen das er bei jedem Wechsel
> zählt??
Welche Zielplattform (FPGA, CPLD, Hersteller)?
Welche Frequenz hat LRCK_IN?
Hast du einen Haupt-Takt? Welche Frequenz hat der?

[Schrotty (Gast)]

>Nur wie kann ich denn
>nun so hochzählen lassen das er bei jedem Wechsel zählt??

Führe das Zählen mit einem Systemtakt durch (der deutlich höher ist, als 
die Frequenz deiner Events

Dann erkennst du deine Events durch eine Flankenerkennung am 
Eventeinang.
Dazu schiebst du deinen Eingang durch zwei FFs, die mit dem Systemtakt 
getaktet sind. Sind die beiden FFs unterschiedlich, trat ein 
Signalwechsel auf deinem Eventsignal auf.

EVENT_AUFGETRETEN <= FF1 XOR FF2;

Mit diesem EVENT_AUFGETRETEN enablest du den Zähler
so in der Art:

if (CLK'event and CLK = '1') then
   if CH_CNT = 4 then
      CH_CNT <= 1;
   elsif (CH_CNT < 4 and EVENT_AUFGETRETEN = '1' then
      CH_CNT <= CH_CNT + 1;
   end if;

[Andi Z. (duderino65)]

hi,

ist für nen MachXO von lattice. aber der ganz kleine 256C.

die frequenz liegt bei 96 kHz denk ich (höchstens 192kHz). sonst habe 
ich keinen takt. diesen bekomme ich von einem receiver mitgeliefert.

der zähler ist für eine case anweisung bei der ich je nach zahl das den 
takt an andere FIFOs verteile.

habe nun 4 FIFOs im design und auf dem FPGA/CPLD ist nicht mehr viel 
platz für irgendwelche grossen algorithmen.

MfG

Andi

[Andi Z. (duderino65)]

mh ok werd ich mal versuchen.

danke!

[Schrotty (Gast)]

Wenn du keinen Takt zur Verfügung hast und auch keinen spendieren 
willst, dann kannst die von mir oben genannte Methode abwandeln (aber 
das ist echt ganz happig)

Führe das Eingangssignal über ein paar Inverter im deinem Chip 
(Constraints so setzen, dass sie nicht wegoptimiert werden)

Dann den ersten und letzten Inverter XOR verknüpfen.

Du erhältst dann beim Flankenwechsel des Eingangssignals einen kurzen 
Spike (der ist so lang, wie du Summe der Laufzeiten deiner in Reihe 
geschalteten Inverter.

Diese Spikes kannst dann zählen (sind immer positiv, egal ob sie von 
einer steigenden oder fallenden Flanke herrühren)

also

if (SPIKE'event and SPIKE = '1') then
  --COUNTER.....

Das ist aber alles andere als eine "schöne Lösung"!!!!!!!

[Andi Z. (duderino65)]

ah ja ich habe doch noch einen takt zur verfügung. ganz vergessen :-D

einen Bit Takt bekomme ich auch. die mit der fallenden flanke des Bit 
Taktes fängt ein neues bit an.

allerdings möchte er bei einem process immer ein wait drin haben.

mfg

Andi

[Schrotty (Gast)]

>allerdings möchte er bei einem process immer ein wait drin haben.

Wer will das? Du, dein Auftraggeber, deine IDE?

mach in deinen Process eine anständige Sensitivity List und den Prozess 
dann getaktet. Dann brauchst du kein Wait

BTW: ein "wait until" ist zwar synthetisierbar, aber mehr als unschön!

>ah ja ich habe doch noch einen takt zur verfügung. ganz vergessen :-D

Der muss halt deutlich schneller sein, als deine Daten kommen, sonst 
kannst nicht vernünftig abtasten!

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

> 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 einen takt zur verfügung. ganz vergessen :-D
Läuft der dauernd durch?
Welche Frequenz hat der?

EDIT:
> BTW: ein "wait until" ist zwar synthetisierbar, aber mehr als unschön!
Naja, es hat m.E. signifikante Vorteile.
Aber über Schönheit lässt sich streiten... ;-)

[Schrotty (Gast)]

>EDIT:
>> BTW: ein "wait until" ist zwar synthetisierbar, aber mehr als unschön!
>Naja, es hat m.E. signifikante Vorteile.
>Aber über Schönheit lässt sich streiten... ;-)

Lach, genau Lothar, da hat jeder eben so seinen persönlichen Stil.
Ich bevorzuge sowieso generell die "zwei-process-methode" und trenn so 
schön meine Register von der Logik, auch wenn es unter´m Strich bisschen 
mehr schreibarbeit ist.
Ja und spätestens im kombinatirischen Prozess, in dem kein FF mehr 
abgebildet wird, musst du eh deine sensitivityliste "up to date" halten.
hat eben jede Methode ihre vor- und nachteile.
Und vielleicht war es ein wenig zu schnell geschossen, wenn ich schrieb, 
dass es "mehr als unschön" ist.
von "wait until" ist es halt net weit zum "wait for" und spätestens da 
rebelliert die Synthese :-)

Aber wie du schon sagst: über Schönheit lässt sich streiten :-)

Mein Vorschlag mit dem generieren und auswerten eines Spikes ist auch 
alles anderere als schön :-)

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

> Mein Vorschlag mit dem generieren und auswerten eines Spikes ist auch
> alles anderere als schön :-)
Unbestritten...  ;-)

> Führe das Eingangssignal über ein paar Inverter im deinem Chip
> (Constraints so setzen, dass sie nicht wegoptimiert werden)
Aber diese Xilinx-Appnote mit dem kombinatorischen Ringoszillator, die 
hat auch was. Mich hat sie auf jeden Fall, naja, sagen wir mal 
überrascht    :-o
Eine bereinigte und übersichtlichere Version dort:
http://www.lothar-miller.de/s9y/categories/29-Ringoszillator
Hier sieht man auch schön das KEEP Attribut, das dafür sorgt, dass 
Signale nicht wegoptimiert werden. Das würde bei dem Spike-Takt auch 
helfen...