Forum: FPGA, VHDL & Co. Tristate Bus Umschaltzeitpunkt


von Andreas (Gast)


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:
1
if (ram_oe = '0') then
2
   RAM_DB <= (others => 'Z');
3
   ram_do <= RAM_DB;
4
else
5
   RAM_DB <= ram_di; 
6
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ß

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


Lesenswert?

> Folgendes steht in einem asynchronen Prozess:
Das könntest du auch abkürzen und ohne Prozess schreiben:
1
ram_do <= RAM_DB;
2
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...

von Andreas (Gast)


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...
1
busdrv: process(CLK)
2
begin
3
   if rising_edge(CLK) then
4
      ram_oe_last <= ram_oe;
5
   end if;
6
end process;
7
   
8
RAM_OE      <= '1' when (ram_oe_last = '1') else ram_oe;
9
RAM_DB      <= (others => 'Z') when (ram_oe = '0') or (ram_oe_last = '0') else ram_di;
10
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? :)

von Iulius (Gast)


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....

von Christian R. (supachris)


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.

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


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...

von Klaus Falser (Gast)


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.

von Klaus Falser (Gast)


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.

von Iulius (Gast)


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.

von Andreas (Gast)


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)

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.