mikrocontroller.net

Forum: FPGA, VHDL & Co. Prozess hier nötig oder Signalzuweisung ausreichend?


Autor: (Gast) == (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

in einen XC95144XL (Oszillator 66MHz, Videotakt=66MHz/12=5,5MHz) soll 
ein Videocontroller. Also SRAM als Videospeicher, der abwechselnd dem 
angeschlossenen µC und dem Videoteil zur Verfügung steht. Da der Platz 
knapp wird und ich keinen größeren Baustein verwenden möchte, werden 
einige Sync-Signale per Signalzuweisung der Form:

SPL <= '1' when (HCNTs > 72 and HCNTs < 75) else '0';

und nicht (mehr) als Prozess:

SPL_PROC : process(CLK_IN, HCNTs)
begin
  if falling_edge(CLK_IN) then
    if(HCNTs > 72 and HCNTs < 75)then
      SPL <= '1';
    else
      SPL <= '0';
    end if;
  end if;
end process SPL_PROC;

generiert.

Alles funktioniert über lange Zeit mit verschiedenen TFTs stabil. Werden 
Glitches (wenn HCNTs in einem weiteren Prozess weitergezählt wird) nur 
nicht wirksam wegen dem Tiefpass aus CPLD-Treiberwiderstand und 
parasitäre TFT-Einganskapazität? Sind die Glitches erfahrungsgemäß so 
kurz, dass sie nach draussen eh unwirksam sind?

Kurz: Bin ich auf der sicheren Seite?

Danke - Frank

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Werden Glitches (wenn HCNTs in einem weiteren Prozess weitergezählt wird)
> nur nicht wirksam wegen dem Tiefpass aus CPLD-Treiberwiderstand und
> parasitäre TFT-Einganskapazität?
Ja.

> Sind die Glitches erfahrungsgemäß so kurz,
> dass sie nach draussen eh unwirksam sind?
Das kannst du nur an der realen Hardware messen und beantworten.

BTW:
SPL_PROC : process(CLK_IN, HCNTs)
Dieser Prozess ist eigentlich nur auf CLK_IN sensitiv.
HCNTs ist in der Liste überflüssig.

Autor: Klaus Falser (kfalser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
(Gast) == schrieb:
> Kurz: Bin ich auf der sicheren Seite?

Kurz : Nein, wenn Du dir keine Glitches erlauben kannst.

Einen <> Vergleich in einem CPLD zu machen ist ziemlich 
Resourcenfressend.
Vielleicht ist es günstiger, bei HCNT = 72 einen weiteren Zähler zu 
starten, und warten bis dieser abläuft.

SPL_PROC : process(CLK_IN)
begin
  if falling_edge(CLK_IN) then
    CNT <= CNT - 1;
    if SPL = '1' and CNT = 0 then
       SPL <= '0'
    end if;
    if(HCNTs = 72 then
      SPL <= '1';
      CNT <= 3;
    end if;
  end if;
end process SPL_PROC;

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Einen <> Vergleich in einem CPLD zu machen ist ziemlich
>Resourcenfressend.

Kapiere ich nicht. Ist das nicht die negierte Gleichheit?

Autor: (Gast) == (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für Eure Antworten. Werde das Oszi am CPLD (ohne TFT als Last) in 
der Hoffnung beobachten, möglichst wenig Unruhe zu sehen und ich mach 
einen Resourcenvergleich mit schlankerem "CNT"-Zähler.


>Einen <> Vergleich in einem CPLD zu machen ist ziemlich
>Resourcenfressend.

Damit meint Klaus nicht Ungleichheit ( x/=y ), sondern 
Kleiner-Größer-Vergleiche.

Autor: Guido (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ah, danke.

Autor: Klaus Falser (kfalser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guido schrieb:
>>Einen <> Vergleich in einem CPLD zu machen ist ziemlich
>>Resourcenfressend.
>
> Kapiere ich nicht. Ist das nicht die negierte Gleichheit?

Falsch beschrieben.
Mit <> meinte ich in diesem Fall nicht "ungleich", sondern die 
Vergleiche auf kleiner oder größer.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  (Gast) == (Gast)

>SPL <= '1' when (HCNTs > 72 and HCNTs < 75) else '0';

>und nicht (mehr) als Prozess:

Das spart effektiv nix, denn die Macrozelle brauchst du sowieso. In 
ersten Fall ist dein FlipFlop ungenutz und vergammelt.
In CPLDs sollte man das anders kodierern, die VHDL Compiler sind nicht 
unbedigt so schlau, das selber rauszufinden.
SPL <= '1' when (HCNTs = 72 or HCNTs = 73 or HCNs =74) else '0';

Das Ergebnis ist gleich, der Resourcenverbrauch NICHT! Probiers aus.

>Alles funktioniert über lange Zeit mit verschiedenen TFTs stabil. Werden
>Glitches (wenn HCNTs in einem weiteren Prozess weitergezählt wird) nur
>nicht wirksam wegen dem Tiefpass aus CPLD-Treiberwiderstand und
>parasitäre TFT-Einganskapazität?

Kann sein, muss nicht.
> Sind die Glitches erfahrungsgemäß so
>kurz, dass sie nach draussen eh unwirksam sind?

NEIN!!!

>Kurz: Bin ich auf der sicheren Seite?

Nein. Wenn du ein Signal SICHER glitchfrei haben willst, muss du 
entweder

* Graycode nutzen
* Ein FlipFlop nachschalten

Alles andere ist Zufall oder Glück.

MFG
Falk

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.