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
> 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.
(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;
>Einen <> Vergleich in einem CPLD zu machen ist ziemlich >Resourcenfressend. Kapiere ich nicht. Ist das nicht die negierte Gleichheit?
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.
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.
@ (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.
1 | 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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.