|
Anzeige
|
Zähler bei jedem event erhöhenGuten 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:
...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
Gast
#1425885
Die Zeile
würde bedeuten, dass du ein FF brauchst, das mit steigender UND fallender Flanke schaltet. Und sowas gibt es nicht! > 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?
Gast
#1425896
>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.
Mit diesem EVENT_AUFGETRETEN enablest du den Zähler so in der Art:
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 mh ok werd ich mal versuchen. danke!
Gast
#1425917
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
Das ist aber alles andere als eine "schöne Lösung"!!!!!!! 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
Gast
#1425948
>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! > 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... ;-)
Gast
#1425988
>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 :-) > 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... Antwort schreiben |
Anzeige
|
