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)
@ 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
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.
@ 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
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.
> 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 ;-)
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?
> 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.
@ 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
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.
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 ;)
@ 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
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!
@ 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
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.