Tristate Bus Umschaltzeitpunkt

> 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? :)

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

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

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.

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.

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)