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


von Läubi .. (laeubi) Benutzerseite


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)

von Falk B. (falk)


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

von Läubi .. (laeubi) Benutzerseite


Lesenswert?

Hm... also so ganz blick ich noch nicht durch.
Momentan hab ich es so gelöst:
1
-- Wenn capturen fertig ist WR sperren
2
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.

von Falk B. (falk)


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

von Läubi .. (laeubi) Benutzerseite


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.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


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   ;-)

von Läubi .. (laeubi) Benutzerseite


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?

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


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.

von Falk B. (falk)


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

von Läubi .. (laeubi) Benutzerseite


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.

von Läubi .. (laeubi) Benutzerseite


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 ;)

von Falk B. (falk)


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/glitch/glitch.html

MfG
Falk

von Läubi .. (laeubi) Benutzerseite


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!

von Falk B. (falk)


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

von Läubi .. (laeubi) Benutzerseite


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

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
Noch kein Account? Hier anmelden.