mikrocontroller.net

Forum: FPGA, VHDL & Co. Pegel um halbe Taktrate verlängern mit CPLD


Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Folgendes "Problem":

Angesteuert werden soll ein SRAM mit 15ns Zykluszeit, Takt des CPLDs 
(Xilinx 9572XL) ist 60Mhz soweit so gut.
Jezt soll aber die breite des WR Signals 10ns betragen, erzeugt wird 
diese z.Z. durch Verknüpfung mit dem Takt und einem Schreibsignal ist 
also 7,5ns lang.

Kann ich jezt irgendwie erreichen (vieleicht durch Synthese/Fitter 
Optionen?) das das Signal auf (etwa) 10ns verlängert wird?

Das Problem ist halt das ich im CPLD nicht genug Platz für großartige 
Experimente habe (z.B. einfach ne doppelte Taktrate nehmen)

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Läubi .. (laeubi) Benutzerseite

>Kann ich jezt irgendwie erreichen (vieleicht durch Synthese/Fitter
>Optionen?) das das Signal auf (etwa) 10ns verlängert wird?

Optionen nicht, aber einen Trick.
Das WR Signal mit einem zweiten FlipFlop auf der anderen (fallenden?) 
Flanke abtasten, aus dem originalen + verzögerten über eine 
UND-Verknüpfung das verlängerte WR Signal gewinnen. Kostet 2 
Makrozellen, ist aber wasserdicht, macht keine Glitches.

MfG
Falk

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm... also so ganz blick ich noch nicht durch.
Momentan hab ich es so gelöst:
-- Wenn capturen fertig ist WR sperren
nWR   <= clk OR captureDone;
clk ist mein Takt, captureDone ist so lange 0 (syncron zur steigenden 
Flanke) wie geschrieben werden soll (ohne Flanken) sonst 1.

Ich sehe nur nicht wie ich da durch die fallende Flanke etwas 
konstruiere das zwischen zwei Flanken liegt... wr ist ja schon nur eine 
halbe Periode aktiv. Wenn WR so breit wie clk_low+clk_high wäre würde 
ich das verstehen aber so komm ich nicht dahinter.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Läubi .. (laeubi) Benutzerseite

>-- Wenn capturen fertig ist WR sperren
>nWR   <= clk OR captureDone;

AUA! Soche Tricks solltest du dich fix abgewöhnen! Das geht mit den 
heutigen sauschnellen CPLDs und FPGAs regelmässig schief!

Und jetzt schreibst du eintausend mal.

Ein Takt ist ein Takt und keine Signal!

>clk ist mein Takt, captureDone ist so lange 0 (syncron zur steigenden
>Flanke) wie geschrieben werden soll (ohne Flanken) sonst 1.

WR muss über ein FlipFlop, wleches mit clk getaktet wird erzeugt werden!

>Ich sehe nur nicht wie ich da durch die fallende Flanke etwas
>konstruiere das zwischen zwei Flanken liegt... wr ist ja schon nur eine
>halbe Periode aktiv.

> Wenn WR so breit wie clk_low+clk_high wäre würde
>ich das verstehen aber so komm ich nicht dahinter.

So war es auch nicht gemeint. Mach dein WR solide wie beschrieben eine 
60 MHz Periode lang und alles wird gut. Das sind nämlich auch "zufällig" 
16ns, überaus passend für einen 15ns SRAM.

MfG
Falk

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:
> AUA! Soche Tricks solltest du dich fix abgewöhnen! Das geht mit den
> heutigen sauschnellen CPLDs und FPGAs regelmässig schief!
Naja das hat mir Lothar geraten das so zu machen :)

> WR muss über ein FlipFlop, wleches mit clk getaktet wird erzeugt werden!
> So war es auch nicht gemeint. Mach dein WR solide wie beschrieben eine
> 60 MHz Periode lang und alles wird gut. Das sind nämlich auch "zufällig"
> 16ns, überaus passend für einen 15ns SRAM.
Ja kein Problem aber wenn WR immer auf 1 ist ohne eine Flanke dazwischen 
wird kein neuer Schreibzyklus angestoßen :-\

Daher hatte Lothar in einem anderen Thread mir geraten das Schreibsignal 
mit dem Takt (ausnahmsweise) zu verknüpfen.

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

Bewertung
0 lesenswert
nicht lesenswert
> Naja das hat mir Lothar geraten das so zu machen :)
Aber hallo, ich meine, dazu gesagt zu haben, dass man da wegen möglicher 
Glitches sehr vorsichtig sein sollte... Es gibt immer einen Unterschied 
zwischen einem "Guten Rat" und einem "Würg-Around".

@ Falk:
> Kostet 2 Makrozellen, ist aber wasserdicht, macht keine Glitches.
Die hat Läubi nicht mehr...


> Und jetzt schreibst du eintausend mal.
> Ein Takt ist ein Takt und keine Signal!
Du bist ein unerkannter Poet   ;-)

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja ich hab angeblich noch 2 Macrozellen frei versuchen könnte ich es 
mal.
Aber dann hab ich doch immer noch nur eine Breite von der halben 
Taktfrequenz oder nicht?

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

Bewertung
0 lesenswert
nicht lesenswert
> Aber dann hab ich doch immer noch nur eine Breite von der halben
> Taktfrequenz oder nicht?
Ja, du verzögerst das Signal und verknüpfst die beiden. Weil die sich 
dann immer um einen halben Takt überlappen, hast du garantiert keine 
Glitches.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Lothar Miller (lkmiller)

>> Kostet 2 Makrozellen, ist aber wasserdicht, macht keine Glitches.
>Die hat Läubi nicht mehr...

Pech gehabt.

>> Und jetzt schreibst du eintausend mal.
>> Ein Takt ist ein Takt und keine Signal!
>Du bist ein unerkannter Poet   ;-)

Huch, hab ich selber gar nicht gesehen :-0

@  Lothar Miller (lkmiller)

>Ja, du verzögerst das Signal und verknüpfst die beiden. Weil die sich
>dann immer um einen halben Takt überlappen, hast du garantiert keine
>Glitches.

Schon, aber reichen ~8ns WR Pulse für einen 15ns SRAM?
Hab mal fix bei Cyprss nachgeschaut, dort braucht der CY7C109BN bei 15ns 
Write Cycle Time 12ns WR Pulse width.
Ich würde das Ganze nicht überstapazieren wollen. Lieber einen Tick 
langsamer als instabil!!!

Nimm einen 80 MHz Oszillator, dann kannst du ganz offiziell die 
Pulsbreite einhalten. Ein Schreibzyklus dauer dann ganz normal zwei 
Takte. Sauber und synchron. Wenn man es tatsächlich ausreizen will, 
nimmt man einen 120 MHz Takt und macht den WR 1,5 Takte breit und 
erreicht echte 60 MHz Schreibtakt.

MFG
Falk

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller schrieb:
>> Aber dann hab ich doch immer noch nur eine Breite von der halben
>> Taktfrequenz oder nicht?
> Ja, du verzögerst das Signal und verknüpfst die beiden. Weil die sich
> dann immer um einen halben Takt überlappen, hast du garantiert keine
> Glitches.
Aber dann fehlt mir doch immer noch die Flanke im Signal :-\
Oder ich seh gerade überhaupt nicht wie ich das umsetzen kann, weil das 
Schreibsignal ja konstant 1 ist also noch keine Flanken enthält.

@Falk:
Der von mir verwendete SRAM hätte gerne 10ns: 
Beitrag "Frage zu SRAM Timing"

Klar wäre ein höhere Takt besser und sauberer geht hier aber auch nicht 
ohne einen größeren/schnelleren CPLD und ich würds halt gerne mit diesem 
Umsetzen da der noch einigermaßen Handlich zu löten ist und bis auf das 
WR Signal "passt" zur Zeit ja alles rein.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab nochmal ne Frage bezüglich des Glitches:
Warum und Wann tritt der den auf?

Hab mir gerade mal das 'Technologie Schematic' angeschaut.

Clk geht auf ein IBUF, dann auf ein 2-Fach OR zusammen mit dem stop 
Signal welches aus einem Q-Ausgang des FF kommt welches auf der 
Steigenden Flanke seine Daten übernimmt.

stop ist dabei größtenteil konstant auf 0 und ändert sich nur in zwei 
Situationen:
- Beim zurücksetzen des Zählers wobei dieser Reset mehrere Takte anliegt 
wechsel von 1->0 während der steigenden Flanke
- Wenn das schreiben bis zum nächsten Reset gestoppt wird wechsel von 
0->1 während der steigenden Flanke

-> konstant => das OR-Gatter gibt einfach den Takt mit einer gewissen 
Verzögerung aus (da dürfte es ja kein Problem geben).
-> reset => Für die Zeit die das FF braucht um den neuen Wert zu 
erhalten ist der zweite Eingang ggf. noch auf 1 obwohl er 0 sein sollte, 
solange der Takt 1 ist und der Ausgang bleibt etwas länger auf High => 
da High der inaktive Zustand ist solte das auch kein Problem sein
-> stop => gleiches wie oben nur das hier ggf. ein weiterer (kurzer) 
spike erzeugt wird wenn das FF länger als die halbe Taktperiode benötigt 
bis der neue Wert übernommen ist un am Gatter anliegt => letzter SRAM 
Wert ggf. doppelt gespeichert oder ungültig.

Ist das soweit korrekt oder habe ich was übersehen? Das der lezte Wert 
ggf. ungültig ist könnte ich verkraften ;)

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Läubi .. (laeubi) Benutzerseite

>Hab nochmal ne Frage bezüglich des Glitches:
>Warum und Wann tritt der den auf?

Immer dann, wenn man sie am wenigsten gebrauchen kann ;-)

http://www.geocities.com/jacquesmartini/digital/gl...

MfG
Falk

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:
> Immer dann, wenn man sie am wenigsten gebrauchen kann ;-)
:D Ja logisch, die Frage ist doch ob das in meinem Falle (s.o.) 
überhaupt relevant ist!
In dem Link geht es ja um veränderliche Signale die wiederum andere 
Aktionen zu Folge habe.
Hier habe ich aber ein (weitestgehend) statisches Signal, und dort wo es 
sich ändert hätte ein falsches Zwischensignal nicht zur Folge das die 
Funktion fehlschlägt.
Das das "böse" im Allgemeinen ist ist mir schon klar!

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Läubi .. (laeubi) Benutzerseite

>:D Ja logisch, die Frage ist doch ob das in meinem Falle (s.o.)
>überhaupt relevant ist!

Aber sicher.

>Hier habe ich aber ein (weitestgehend) statisches Signal, und dort wo es
>sich ändert hätte ein falsches Zwischensignal nicht zur Folge das die
>Funktion fehlschlägt.

Bite? Dein WR ist statisch und ein Zwischensignal hätte keine Folgen? Du 
bist naiv.

>Das das "böse" im Allgemeinen ist ist mir schon klar!

Da bin ich mir nicht so sicher.

MFG
Falk

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:
> Bite? Dein WR ist statisch und ein Zwischensignal hätte keine Folgen?

Das RAM hat 32kiB Speicherzellen und wird von 0...n fortlaufend 
beschrieben. In dieser gesamten Zeit ist das Signal (captureDone) mit 
dem der Takt verodert wird konstant auf logisch 1.
Der Ausgang nWR folgt in diesem Falle doch einfach dem Takt wo soll da 
ein Glitch entstehen? Es ist kein weiteres getaktetes/speicherndes 
Element in der Kette vorhanden.

Ist der Zählzyklus vorbei wechselt captureDone einmalig von 0 auf 1 
während der Addreszähler seinen Wert beibehält, tritt hier ein 
zwischensignal auf ist das letzte Sample ggf korrupt --> damit kann ich 
leben.

> Du bist naiv.
Möglich, ich sehe nur nicht wo in meinem Fall ein Problem auftreten 
kann. (und Warum)

>>Das das "böse" im Allgemeinen ist ist mir schon klar!
>
> Da bin ich mir nicht so sicher.
Ich aber, wenn ich die Recourcen und die passende Taktrate hätte würde 
ich es 100% syncron und ohne Tricks lösen... leider übersteigt TQF100+ 
etwas meine Ätz- und Lötmöglichkeiten

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.