RAM Controller in FPGA implementieren

[Markus H. (dasrotemopped)]

Hallo zusammen,

bei meinem Bastelprojekt schliesse ich an ein FPGA Board extern einen 
Prozessor an, der auf den Speicher des FPGA Boards zugreifen soll. Zum
einfachen Debuggen hängen an den Adress/Daten/Steuerleitungen noch LEDs
und 7-Segment Anzeigen. Die Adress- und Steuerleitungen anzuschliessen
ist kein Problem, die Datenleitungen machen mir allerdings Probleme.
Da die Datenleitungen bidirektional sind habe ich beim kompilieren des
Designs immer die Fehlermeldungen, das Ausgänge aufeinander treiben oder
Eingänge zusammengeschaltet sind und keinen Treiber haben. Irgendwie
muss ich einen bidirektionalen Port in einen Ausgang und Eingang
aufsplitten, habe aber bis jetzt noch keine Idee, wie. Auch mit Tristate
Buffern wie auf dem Bild zu sehen bekomme ich immer Kompilierungsfehler.
Wie kann ich das Problem lösen ?

Gruß,

dasrotemopped.

[Daniel M. (daniel__m)]

Markus Horbach schrieb:
> Irgendwie
> muss ich einen bidirektionalen Port in einen Ausgang und Eingang
> aufsplitten, habe aber bis jetzt noch keine Idee, wie.

Der Port bleibt wie er ist (bidir). Du musst ihn im FPGA auftrennen. Am 
besten gleich auf Top-Level-Ebene, so in der Richtung:

entity ...
  port (
    ...
    data_port : inout std_logic_vector;
    ...
  );
end entity;

...
data_port   <= data_out when rw = W else (data_out'range => 'Z');
data_in     <= data_port;
...

Im FPGA hast du dann einen Lese- (data_in) und einen Schreibbus 
(data_out).

grüße

[Markus H. (dasrotemopped)]

ich mache mein Design auf FPGA Schaltplan Ebene, nicht in VHDL ( habe
noch nicht genug Kenntnisse in VHDL ). Wie würde ich einen Bus auf
Schaltplanebene aufteilen und ggf. wieder zusammenführen ?

Gruß,

dasrotemopped.

[J. S. (engineer)]

Daniel M. schrieb:
> besten gleich auf Top-Level-Ebene
nicht "am besten" sondern definitiv auf Topebene, weil es sich anders 
praktisch garnicht sinnvoll verdrahten lässt. Die 
buffer/bidir-Funktionalität in die Designtiefe zu schleppen, ist nicht 
nur unschön beim Simulieren, sondern in vielen Fällen nicht 
synthesisierbar. Gfs kommt dann auf den Daten nichts raus.

Im VHDL-Design muss dazu ein TriState-Buffer eingebaut werden. Entweder 
implizit durch das Beschreiben mit Ausgang = "Z" im Falle der 
Inaktivität und Ausgang = DATA beim Senden oder man baut den buffer 
explizit nach Hersteller-Lib ein, wozu ich raten würde.

Ich empfehle hier nochmal mit Nachdruck, generell Physik und Logik zu 
trennen und alles, was Übergang von Logik auf Physik darstellt (Pegel, 
loactive-Thema, Treiberverhalten, DiffSig, LVDS und solche Themen wie 
SERDES, GTP etc.) ganz oben auf Topebene aufzubauen und das eigentliche 
Logikdesign zu wrappen.


Markus Horbach schrieb:
> Wie würde ich einen Bus auf
>
> Schaltplanebene aufteilen und ggf. wieder zusammenführen ?
Das wird schwerlich gehen, es sei denn, Dein Tool "weiss" dass das Zeug 
ins FPGA geht, in welches und wie es buffer bauen muss,

Das, was Du brauchst, ist nicht Logikdesign, die man funktionell 
beschreiben und dann im FPGA nachbilden kann, sondern es ist Physik, die 
vorhanden sein muss. Die ist im FPGA implementiert. Die meisten 
IO-Zellen der meisten FPGAs sind bidir nutzbar, d.h. sie verfügen über 
den besagten Tristate-Buffer, also einen parallelen Datenpfad für IN und 
OUT, wobei der OUT abtrennbas ist. Lies Dir mal die FPGA BEschreibung 
durch.

Wenn Du sowas per Hand aufbauen wolltest, brächtest Du ein Triste-Latch 
in Form eines Chips, den Du im Schaltplan reinmalst.

[Daniel M. (daniel__m)]

kurze Antwort: keine Ahnung.

So wie du (zur Zeit) schematisch arbeitest, arbeite ich zu 99% mit VHDL. 
Die Lösung hängt sicherlich davon ab, welches Tool du verwendest 
(Xilinx/Altera/MentorGraphics/Aldec nur um ein paar zu nennen).

Daher meine Empfehlung: schau dir mal VHDL an. Ist erheblich leichter 
als man vielleicht denken mag und standardisiert.

grüße

PS: der Lösungsvorschlag ist im Endeffekt nur ein Muxer, welcher 
entweder einen internen Datenbus auf den Port gibt, oder 'Z', welches 
bedeutet, der FPGA-Ausgang soll hochohmig sein. Vielleicht kann man das 
grafisch nachbauen.

[Markus H. (dasrotemopped)]

ja, Tristate Buffer, genau die habe ich ja in dem Schaltplanausschnitt
auch verwendet. Über die R/W Leitung schalte ich die Tristate Buffer
um ( einer ist Low Aktiv, der ander High Aktiv ). Altium meckert aber
an, das der IO Port gegen den Ausgang eines Tristate Buffers treibt.
Dadurch kann ich das Design nicht kompilieren und komme nicht weiter.
Die roten Kringel unter den Ports zeigen den Fehler an.

Gruß,

dasrotemopped.

[Daniel M. (daniel__m)]

Es scheint so, dass du diese Buffer nicht direkt miteinander verbinden 
darfst.

Ich habe das/den Altium noch nie verwendet aber das hier scheint in die 
Richtung zu gehen:
http://wiki.altium.com/display/ADOH/Schematic+Bus

Man soll anscheinend sog. "bus joiners" verwenden.

IMHO: Daher nehme ich direkt VHDL ;) . Bis ich das alles zusammen habe, 
Symbole aus den Bibliotheken gesucht habe, die Symbole und die Leitungen 
"schön" angeordnet habe, bin ich mit VHDL längst fertig. Aber ich gebe 
recht, wenn alles fertig ist, siehts besser aus.

grüße

[Markus H. (dasrotemopped)]

das Dokument zu den Bus Joiner kenne ich. (Habe die Altium Hilfe schon
durchsucht aber nichts für mich gefunden). Die Joiner können nur
Buselemente vereinen oder aufsplitten, also einen Bus mit x Elementen in 
einen Bus mit y und z Elementen aufteilen usw.
Aber die Richtung der Buselemente bleibt dabei immer unberührt. Habe
das schon öfter benutzt.
Ich kann mir einfach nicht vorstellen, das im Schematic die Möglichkeit
fehlt, einen Bus nach seinen Richtungen aufzusplitten. Nur das gewusst 
wie
fehlt halt.

Gruß,

dasrotemopped.

[Markus H. (dasrotemopped)]

ich glaube, ich habs gefunden. Es ist der IO Buffer, der
IO Busse in Input und Output aufteilt. Werde das heute abend erst mal
testen.

Gruß,

dasrotemopped.

[Weltbester FPGA-Pongo (Gast)]

Das Ganze scheint mir eher ein externes Verdrahtungsproblem auf 
Schaltplanebene zu sein und mit dem FPGA nichts zu tun zu haben.