Entfernen von Spikes ohne Eintakten

[Andi Z. (duderino65)]

hallo,

kennt jemand eine methode einen spike aus einem signal zu entfernen ohne 
ein zusätzliches FF zu verwenden?

durch einen zähler entsteht kurz ein zählerstand bei dem die 
nachfolgende logik mit einem spike reagiert. dieser spike setzt einen 
anderen zähler zu früh zurück. mit einem FF wird es sonst etwas knapp da 
dieses signal einen rücksetzt-impuls trägt und dieser impuls dann noch 
später kommt. durch das rücksetzen werden enable signale für einen RAM 
gesetzt. leider kommt dann auch die flanke zum einlesen. d.h. mein 
enablesignal würde fast zeitgleich mit dem schreibtakt des ram 
auftauchen.

ich hab nur die idee, das signal auf zu splitten und eines der beiden 
signale zu verzögern. beide signale dann auf ein UND. so wäre der spike 
vllt kleiner oder ganz weg und mein resetsignal ist trotzdem noch da.

mfg

Andi

[Hogo F. (Firma: Bailout Inc.) (atze_vom_bau)]

- den Zähler richtig designen.
- Synchrone Logik verwenden.

Murks bleibt immer murks. Gruß!

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

> durch einen zähler entsteht kurz ein zählerstand bei dem die
> nachfolgende logik mit einem spike reagiert.
Das ist kein Spike, das ist ein Glitch.
Lass doch mal dein Design sehen, das hört sich arg asynchron und 
hingebastelt an...  :-o

> so wäre der spike vllt kleiner oder ganz weg
Im Temperaturbereich von 15 bis 21°C...
Allein die Hoffnung trägt uns voran, oder wie?

BTW: Welche Zielplattform?

[Andi Z. (duderino65)]

hallo,
hier der code:

COUNTER_PROC : process(TXC)
begin
  if falling_edge(TXC) then          --Zähler
    if counter_i_reset = '1' then      
      counter_i <= (others => '0');
    else
      counter_i <= counter_i + 1;
    end if;
  end if;
end process;


counter_i_reset <= reset_enable_i and reset_cnt_i;  

COUNTER_RST_PROC : process(counter_i, reset_cnt_i, wclk_i)
begin
  if (counter_i > 255) and (counter_i < 592) then    --untere und obere Grenze 
        reset_cnt_i <= wclk_i;              --gültiger Reset im Fenster
    elsif (counter_i > 592) then            --Reset nach Ablauf  
      reset_cnt_i <= '1';  
  else
    reset_cnt_i <= '0';              --des maximalen Zählerstandes
    end if;
end process;


with counter_i select
  reset_enable_i   <=   '0' when "0000000000",
            '1' when others;

meine zielplattform ist ein lattice machxo 2280C.
ich habe meine asynchronen I2S signale alle 2mal eingetaktet. der takt 
TXC läuft mit 25 MHz.


danke


mfg Andi

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

Was machen denn diese vielen Resets da?

Und der hier macht Probleme, oder: reset_cnt_i
Weil er irgendwo auf einen asynchronen Reset geht?
Das würde mich nicht wundern.

> der takt TXC läuft mit 25 MHz.
Und was ist dein Systemtakt?
Woher kommt der TXC?


BTW:

with counter_i select
  reset_enable_i  <=   '0' when "0000000000",
            '1' when others;

Das könntest du leserlicher so schreiben:

  reset_enable_i  <= '0' when counter_i="0000000000" else '1';

Und auch das sieht sehr hingebastelt aus....

[Falk B. (falk)]

Siehe Glitch

[Andi Z. (duderino65)]

hi,

ja genau der geht auf einen asynchronen reset. mein systemtakt sind die 
25 MHz und kommt von einem ethernetchip. die eingetaktete Bitclock vom 
i2s signal wird zum Zählen und eintakten der daten in den ram verwendet.
hinter diesem zähler hängt logik zum erzeugen der adresse und der 
wr-enable-signale.
der zähler wird, durch eben dieses counter_i_reset signal, zu jedem 
neuen i2s frame asynchron zurückgesetzt.

mfg

Andi

[Andi Z. (duderino65)]

Falk Brunner schrieb:
> Siehe Glitch

habe das signal eingetaktet und jetzt gehts natürlich auch. mein problem 
ist nur, dass das signal vllt zu spät kommt wenn ich eine höhere 
samplerate einstelle. das kann ich gerade aber nicht testen.

mfg
Andi

[Klaus F. (kfalser)]

Andi Z. schrieb:
> Falk Brunner schrieb:
>> Siehe Glitch
>
> habe das signal eingetaktet und jetzt gehts natürlich auch. mein problem
> ist nur, dass das signal vllt zu spät kommt wenn ich eine höhere
> samplerate einstelle. das kann ich gerade aber nicht testen.
>
Wieso testen?
Ob ein Signal zu spät kommt kann man sich entweder überlegen (Papier und 
Bleistift) oder simulieren.

[Andi Z. (duderino65)]

hallo,

wäre es dann sinnvoller bzw. besser die schreibadressen mit 
enable-signalen hoch zu zählen und die daten mit diesen dann auch in den 
ram zu schreiben? das würde das problem mit dem asynchronen reset lösen.

bei lothar miller auf der seite gibts ein bsp für eine flankenerkennung 
mit einem schieberegister. diese würde ja auch mit einem 2 bit 
schieberegister funktionieren, oder?? ich habe ja eh keine prellungen im 
signal. somit würde ich dann die enablesignale zum zählen und die 
wr_enables generieren und mit meinem systemtakt zählen bzw einlesen.

ist diese ansatz ok?


mfg

Andi

[Falk B. (falk)]

@ Andi Z. (duderino65)

>wäre es dann sinnvoller bzw. besser die schreibadressen mit
>enable-signalen hoch zu zählen und die daten mit diesen dann auch in den
>ram zu schreiben? das würde das problem mit dem asynchronen reset lösen.

Du hast es erfasst. Siehe Taktung FPGA/CPLD.

>ist diese ansatz ok?

Ja.

MFG
Falk

[Jürgen S. (engineer)]

Wie wäre es denn mal mit einem konventionellen Tiefpass? Wenn es 
wirklich ein spike ist und er kurz genug ist, um ihn zu entfernen und es 
nicht gelingt, dessen Ursache zu beheben, dann hilft ein RC-Glied und 
ein Schmitttrigger, wenn es ein Takt ist.

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

Es geht offenbar um einen internen, selbst gebastelten und hausgemachten 
Glitch in einem der vielen Reset-Signale...

> Flankenerkennung...
> diese würde ja auch mit einem 2 bit schieberegister funktionieren, oder??
Ja, würde sie. Allerdings habe ich den Eindruck, du selber steuerst da 
irgendwas und erzeugst auch selbst die Flanke. Dann weißt du aber auch 
ganz genau, wann die Flanke passiert ist, denn du selber hast sie ja 
ausgelöst...

> ich habe meine asynchronen I2S signale alle 2mal eingetaktet
Zum Einlesen ist das eigentlich unnötig, denn du kannst ja an der 
Word-Select-Leitung synchronisieren und die Daten für den linken bzw. 
rechten Kanal übernehmen. Wikipedia:

Wesentliche Eigenschaft ist, dass diese Schnittstelle synchron ist.

BTW: Woher kommt dein 25MHz-Takt?

[Andi Z. (duderino65)]

hallo,

ja stimmt die flanke erzeuge ich selbst. ich habe einen zähler und 
dahinter eben vergleichs-kombinatorik. und die reagiert eben kurz und 
erzeugt den glitch weil eine bedingung kurz wahr wird.

habe die die reset-signale nach der kombinaorik jetzt neu eingetaktet 
und alles angepasst und jetzt läuft es sauberer.

die I^2S leitungen muss ich eintakten. da hatte ich anfangs probleme. 
das ist denk ich schon ok.

sollte ich eigentlich hinter jede kombinatorik ein FF schalten? die 
durch kombinatorik erzeugten signale jitter ja. sollte ich nach jeder 
kombinatorik und bevor ich ein signal an die output pins lege, die 
signale erstmal durch FF lassen?

ah ja der 25 MHz Takt kommt von einem Ethernetchip. hab ich glaub 
schonmal erwähnt ;-).

mfg

Andi

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

> die I^2S leitungen muss ich eintakten. da hatte ich anfangs probleme.
> das ist denk ich schon ok.
Kann man machen, aber weil der I2S seinen Takt mitbringt, könnte man 
diese Daten mit dem I2S-Takt einlesen, mit dem Word-Select 
zwischenspeichern und diese gespeicherten Daten über eine 
einsynchronisierte Word-Select-Flanke übernehmen.

> habe die die reset-signale nach der kombinaorik jetzt neu eingetaktet
> und alles angepasst und jetzt läuft es sauberer.
Nur "sauberer", aber noch nicht sauber?
Sieh dir jeden einzelnen asynchronen (und allerschlimmstenfalls noch 
kombinatorisch aus einem Zähler) erzeugten Reset genau an. Und entferne 
ihn. Denn du wirst mit kombinatorischen, asynchronen Resets garantiert 
niemals glücklich.

[Andi Z. (duderino65)]

so mach ich das auch. nur muss ich zu begin des i2s wortes die 
schreibadresse zurück setzen. deshalb wird die wordclock abgetastet und 
auf die steigende flanke dieser reset-impuls erzeugt welcher die 
schreibadresse eben an den anfang stellt. das speichern wird mit der 
eingetakteten bitclock gemacht.

ausserdem wird die wordclock ausgewertet da ich die informationen 
benötige welche clock gerade anliegt. da gibts ja mehrere (44,1 - 48 - 
96 khz). parallel wird dann eben noch ein rahmen versendet sobald dieser 
reset-impuls anliegt.

habe gerade noch nachgesehn... das is der einzigste reset in meinem 
design. alles andere ist getaktet und in kombinatorik. nur der 
adresszähler hat einen asynchronen reset.

mfg

Andi