mikrocontroller.net

Forum: FPGA, VHDL & Co. Tristate Bus Umschaltzeitpunkt


Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe eine Frage zu einem Tristate Bus zwischen einem PSDRAM 
(MT45W8MW16) und einem Spartan3E.

Ich habe den Bus derzeit so realisiert, wie ich es auch in einigen Foren 
gefunden habe:

Folgendes steht in einem asynchronen Prozess:
if (ram_oe = '0') then
   RAM_DB <= (others => 'Z');
   ram_do <= RAM_DB;
else
   RAM_DB <= ram_di; 
end if;

Nun habe ich eine kleine Frage zum "Umschaltzeitpunkt":

Nehmen wir an ich setze ram_oe von 0 auf 1, treibt dann für kurze Zeit 
der RAM gegen den FPGA?
Im Datenblatt steht für "Output disable to DQ High-Z output" 8ns und für 
die Gegenrichtung "Output enable to Low-Z output" 3ns.

Sind diese Zeiten so gering, dass man sie in der Praxis vernachlässigen 
kann oder sollte ich in diese Umschaltung noch jeweils 1 Takt 
Verzögerung einbauen?

Gruß

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

Bewertung
0 lesenswert
nicht lesenswert
> Folgendes steht in einem asynchronen Prozess:
Das könntest du auch abkürzen und ohne Prozess schreiben:
ram_do <= RAM_DB;
RAM_DB <= (others => 'Z') when (ram_oe = '0') else ram_di;
Dabei angenommen, do wäre der Eingang ins FPGA und di der Ausgang... :-/


> sollte ich in diese Umschaltung noch jeweils 1 Takt Verzögerung einbauen?
Schöner wäre das wohl...

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Dabei angenommen, do wäre der Eingang ins FPGA und di der Ausgang... :-/
Oh, da hab ich wohl die Sichtweise verdreht, in folgendem Beispiel hab 
ichs auf die FPGA-Sicht korrigiert.

>> sollte ich in diese Umschaltung noch jeweils 1 Takt Verzögerung einbauen?
>Schöner wäre das wohl...
busdrv: process(CLK)
begin
   if rising_edge(CLK) then
      ram_oe_last <= ram_oe;
   end if;
end process;
   
RAM_OE      <= '1' when (ram_oe_last = '1') else ram_oe;
RAM_DB      <= (others => 'Z') when (ram_oe = '0') or (ram_oe_last = '0') else ram_di;
ram_di   <= RAM_DB;
(großgeschrieben sind die Ports nach aussen)

Ok, so hätt ichs jetzt implementiert. Schaut aber etwas aufgeblasen aus, 
geht das auch eleganter? :)

Autor: Iulius (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab das bisher immer so gemacht das es sofort wechselt.

Hat bspw auch Altera auch im Referenz Design vom DE1 Board genau so 
drinne.


Welches Problem sollte sich dabei denn ergeben ?

Vielleicht weiß das jemand, würde ungern potentiell meine FPGAs oder 
CPLDs riskieren....

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, kurzzeitig arbeiten die Ausgangstreiber dann schon gegeneinander. 
Im schlimmsten Fall kann durch das Schalten vieler Leitungen, die 
gegensätzliche Pegel haben, schon eine recht heftige Stromspitze 
entstehen, die, wenn die Abblock-Kondensatoren nicht ausreichen 
irgendwas zum Absturz bringt. Aber die 10ns Spitze sollte jeder schnelle 
C schlucken. Die Ausgangstreiber an sich werden da wohl kaum kaputt 
gehen.

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

Bewertung
0 lesenswert
nicht lesenswert
Ich würde das auch erst mal pragmatisch machen: lass die Treiber 
aufeinander los. Wenns tatsächlich klemmt, wird der Baustein warm... ;-)

Zudem sind die DB-Angaben idR. worst-case Werte. In der Praxis ist die 
Überlppung wesentlich geringer...

Autor: Klaus Falser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Im Datenblatt steht für "Output disable to DQ High-Z output" 8ns und für
> die Gegenrichtung "Output enable to Low-Z output" 3ns.

Es gilt 4 Zeiten zu berücksichtigen :
- die Zeit, die das FPGA braucht hochohmig zu werden und das RAM 
niederohmig
  Die Zeit, die das FPGA braucht, kann man direkt aus dem Datenblatt 
ablesen.
  Die Zeit für das RAM ergibt sich aus der Summme von 2 Zeiten:
  a) das OE Signal erscheint am Pin des FPGA (Datenblatt FPGA)
  b) das OE Signal wird vom RAM gesehen, und macht seine Pins 
niederohmig
    (Datenblatt RAM).

  Meistens ist die Zeit, die das FPGA braucht relativ lang, es kommt 
also schon zu Kollisionen, aber, wie gesagt, man muß beide Zeiten 
vergleichen.

- die Zeit die das FPGA braucht, um niederohmig zu werden und
  die Zeit die das RAM braucht, um wieder hochohmig zu werden.
  Selbes Spiel wie oben, in diesem Fall ist das FPGA meist schnell, und
  es vergeht mehr Zeit, bis das RAM das OE auf 0 sieht und die Pins 
wieder
  hochohmig schaltet.
  Meist ist die der Fall, bei dem es länger zu Kollisionen kommt.

Ich würde die Kollisionen zu vermeiden suchen, aber es ist nicht nur 
damit getan, das OE zu verzögern, sondern die anderen Signale wie WR 
müssen dann auch später kommen, bzw. beim Einlesen muss man einen 
gültigen Zeitpunkt wählen.

Autor: Klaus Falser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag :
> Welches Problem sollte sich dabei denn ergeben ?
> Vielleicht weiß das jemand, würde ungern potentiell meine FPGAs oder
> CPLDs riskieren....

Das Probleme ist nicht, dass die HW kaputt geht, sondern dererhöhte EMV 
Pegel.
Im professionellen Bereich sollte man in dieser Hinsicht sauber 
arbeiten.

Autor: Iulius (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
D.h. solange keine Verhaltensprobleme auftreten, was bei den minimalen 
Strömen und der niedrigen Spannung wohl so meist sein wird(ich hatte 
zumindest nie welche), ist es egal ?

Gut, kommt sicher auf den Einsatzbereich an, aber bei manchen 
Anwendungen würde ich ungern den Taktzyklus Verzögerung in Kauf nehmen.

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die vielen Antworten, ich glaube ich entscheide mich für das 
saubere Design. Zumal ich den Ram im synchronen Burstmodus ansteuern 
möchte, da kann ich das OE problemlos einen Takt verzögern, ohne dass es 
Auswirkungen auf die Geschwindigkeit hat.
(Der PSDRAM fügt am Anfang des Burstzyklus Wait states ein, während 
dessen refresht er im Hintergrund. Bis diese Wait-Takte vorbei sind ist 
der OE auf jeden Fall schon aktiv und die Ausgänge treiben)

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.