mikrocontroller.net

Forum: FPGA, VHDL & Co. VHDL Grundlagen Ram


Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für die Grundlagen fehlt noch das Thema "Ram".

Es gibt ja die sehr schönen Beispiele von Lothar, die den Unterschied 
zwischen "distributed"- und Block-Ram zeigen, sowie die Implementierung 
eines FIFOs:

http://www.lothar-miller.de/s9y/archives/21-FIFO.html

Nun stellt sich aber die Frage, wie realisiert man am besten ein 
Dual-Port-Ram?

Autor: Bitwurschtler (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
chris schrieb:
> Nun stellt sich aber die Frage, wie realisiert man am besten ein
> Dual-Port-Ram?

mit dem Coregenerator von Xilinx oder dem Äqivalent der anderer 
Toolchains.
https://embeddedmicro.com/tutorials/mojo/using-cor...

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

Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> Nun stellt sich aber die Frage, wie realisiert man am besten ein
> Dual-Port-Ram?
Im Synthesizer Users Guide steht drin, wie man eine 
Hochsprachenbeschreibung gestalten muss, dass der Synthesizer ein RAM 
draus macht.
https://www.xilinx.com/support/documentation/sw_ma...
https://www.xilinx.com/support/documentation/user_...
http://ece-research.unm.edu/jimp/vhdl_fpgas/slides...

Ich instantiiere die Dinger üblicherweise nicht als generische 
VHDL-Beschreibung und nehme auch nicht den Core Generator, sondern mache 
es manuell mit den entsprechenden Templates...

Autor: chris (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Von Altera gibt es auch so einen Block. Im Bild sieht man das Diagramm 
von Altera.

Aber ich hätte lieber einen in VHDL der auf allen Architekturen läuft.

Für eine Version in VHDL scheinen mir ein paar Synchronisationssignale 
zu fehlen.

Ich stelle mir gerade die Frage, welche Signal man wirklich bräuchte:
sysclk

adr0
dataIn0
dataOut0
wr0
rd0
ready0

adr1
dataIn1
dataOut1
wr1
rd1
ready1

Was meint Ihr?

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

Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> Ich stelle mir gerade die Frage, welche Signal man wirklich
> bräuchte: ...
> Was meint Ihr?
Kommt auf die Aufgabe an...

> Aber ich hätte lieber einen in VHDL der auf allen Architekturen läuft.
Vergiss es. Du musst das Ding sogar anfassen, wenn du beim gleichen 
Hersteller bleibst und das Design ein paar Jahre später "upgraden" 
musst.

Autor: Bitwurschtler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
>> Aber ich hätte lieber einen in VHDL der auf allen Architekturen läuft.
> Vergiss es. Du musst das Ding sogar anfassen, wenn du beim gleichen
> Hersteller bleibst und das Design ein paar Jahre später "upgraden"
> musst.

Deshalb empfehle ich ja auch den CoreGen. Der funktioniert auch für 
DPRAM Strukturen für die es kein sauberers VHDL-template gibbet (bspw. 
unterschiedliche aspect ratios der beiden Ports) und unsinnige Werte für 
Parameter sind nicht eingebbar.

In VHDL kann man allen möglichen Mist angegeben der nicht 
synthetisierbar ist, oder obwohl korrekt synthetisierbarer code trotzdem 
nicht vom Synthesizer erkannt wird. Siehe die dutzenden Beschwerden über 
den fragilen Mechanismus der RAM-inference in diversen Foren:

https://github.com/clash-lang/clash-compiler/issues/127

Autor: Weltbester FPGA-Pongo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> Für die Grundlagen fehlt noch das Thema "Ram".

Du machst jetzt aber nicht für alles, was in einen FPGa reinginge, ein 
Grundlagenthema auf oder? Sowas gibt es auf den FPGA-Seiten zuhauf!

Die Hersteller haben auch allesamt genaueste mehrseitige Anleitungen, 
wie so etwas eingesetzt werden kann, wie es formuliert werden soll und 
muss, damit es funktioniert und welche Variationen es gibt. Das ist 
Lesestoff für Stunden und Material zum Ausprobieren für etlichen Wochen, 
wenn Du das alles behandeln und ausprobieren willst.

https://www.fpgarelated.com/forums

Zielführender fände Ich solche Themen wie:

"Wie bekomme Ich einen FPGA mit einem Microcontroller verbunden"
"Wann schalte Ich einen FPGA vor einen Microcontroller"
"Wann benutze Ich überhaupt einen FPGA bei den immer weiter wachsenden 
Funktionen der Microsontroller"

Das täte auch besser zum Forumsthema passen.

Vielleicht ist aber auch das das richtige für Dich:
http://www.fpga-talk.de/forum/viewforum.php?f=4

Autor: C. A. Rotwang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eigentlich ist RAM ganz einfach, du instanziierst das RAMprimitive so 
wie du es brauchst. Eventuell ist das dein Problem, zu erkennen wo man 
welche RAM-primitive einsetzt, insbesonders wo im Alltagsgebrauch immer 
nur von singleport ram die rede/Verwendung ist.

da steht was:
 http://www.cypress.com/products/dual-port-srams
 https://www.idt.com/document/apn/91-most-commonly-...

Registerbänke für prozessoren die Befehle wie ReggB := RegA + RegB 
ermöglichen kann man aals DualPort RAM aufbauen; für die 
Picoblazevariante dort wird distributed RAM verwendet:
https://www.mikrocontroller.net/svnbrowser/pibla/0... 
Zeile 200 - 232

Dort laufen die ports am selben Takt. Weitere Anwendungen sind dadurch 
gekennzeichnet das sie mit unterschiedlichen Takt laufen, FIFO ist da 
der primitive Fall eines DP-RAMS zur Synchronisation.
Ein anderer wäre die Bildwiederholspeicher von Vidointerface. Dort wird 
der eine Port, der in Richtung Monitor nur als readonly benutzt, der 
andere dagegen als write aber auch als readwrite. Code-Beispiel: 
https://www.mikrocontroller.net/svnbrowser/redz0mb...

Dieses ältere Xilinx dokument erklärt wie der Blockram aufgebaut ist, 
welche Schnittstellen er besitz und welche typischen Anwendungen es 
dafür gibt: 
https://www.xilinx.com/support/documentation/appli...

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Eigentlich ist RAM ganz einfach, du instanziierst das RAMprimitive so
>wie du es brauchst. Eventuell ist das dein Problem, zu erkennen wo man
>welche RAM-primitive einsetzt, insbesonders wo im Alltagsgebrauch immer
>nur von singleport ram die rede/Verwendung ist.

Es gibt im Moment eigentlich noch keine Probleme. Ich habe eher 
strukturelle Fragen und will erst mal sehen, wie andere das Problem 
gelöst haben.
Was mir bisher auffällt: Die Ram-Designs haben fast nie 
Tristate-Datenanschlüsse so wie es bei physischen RAM-Bausteinen der 
Fall ist, sondern immer getrennte Ein- und Ausgänge. Sehe ich das 
richtig?
Meine Vermutung: wenn es getrennte Daten Ein- und Ausgänge gibt, kann 
man schneller Designs machen, braucht aber mehr Glue-Logic, weil man 
keinen Tri-State-Bus verwenden kann.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Aber ich hätte lieber einen in VHDL der auf allen Architekturen läuft.
Lothar Miller schrieb:
>Vergiss es. Du musst das Ding sogar anfassen, wenn du beim gleichen
>Hersteller bleibst und das Design ein paar Jahre später "upgraden"
>musst.

Das würde bedeuten, dass Dein Fifo-Design
http://www.lothar-miller.de/s9y/archives/21-FIFO.html
nicht "generisch" ist, sondern z.B. nur auf Xilinx-FPGAs läuft.

Scheinbar läuft es aber auch auf meinem MachX02.
Ich bin auf der Suche nach einen Dual-Port-Ram, welches allen FPGAs ( 
mit genügend Speicher ) läuft.

Als mögliche Realisierung fällt mir das Round-Robin-Verfahren ein:
Abwechselnd jeden Port des Rams "pollen" und dann die Verfügbarkeit des 
Ergebnisses mit einem Ready-Flag melden.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Weltbester FPGA-Pongo (Gast)
>Zielführender fände Ich solche Themen wie:
>"Wie bekomme Ich einen FPGA mit einem Microcontroller verbunden"
>"Wann schalte Ich einen FPGA vor einen Microcontroller"
>"Wann benutze Ich überhaupt einen FPGA bei den immer weiter wachsenden
>Funktionen der Microsontroller"

Ich sehe da jetzt nichts, was dagegen spricht, entsprechende Threads zu 
eröffnen, falls Fragen in der Richtung bestehen ;-)

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Nun stellt sich aber die Frage, wie realisiert man am besten ein
>> Dual-Port-Ram?
Autor: Bitwurschtler (Gast)
>mit dem Coregenerator von Xilinx oder dem Äqivalent der anderer
>Toolchains.

Kann es sein, dass die erzeugten Cores nur auf Xilinx laufen?
Eigentlich sollte VHDL ja für alle FPGAs kompilierbar sein. Ich vermute, 
dass viele Hersteller FPGAs mit ähnlichen Eigenschaften produzieren und 
dass sie zunehmend Versuchen, mit proprietären Tools die Benutzer an 
sich zu binden. Wenn man ein größeres Design mit einem der Tools gemacht 
hat, wird es einem sehr schwer fallen auf das FPGA eines anderen 
Herstellers umzuziehen.
Dem möchte ich entgegen wirken, in dem ich nach "generischen" Designs 
suche, die überall laufen.

Autor: C. A. Rotwang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
>>> Nun stellt sich aber die Frage, wie realisiert man am besten ein
>>> Dual-Port-Ram?
> Autor: Bitwurschtler (Gast)
>>mit dem Coregenerator von Xilinx oder dem Äqivalent der anderer
>>Toolchains.
>
> Kann es sein, dass die erzeugten Cores nur auf Xilinx laufen?
> Eigentlich sollte VHDL ja für alle FPGAs kompilierbar sein.

Nein, VHDL ist garnicht für FPGA-Synthese gemacht sondern für die 
Verifikation von Digitaler Logic (egal ob TTL-Grab oder ASIC). Ferner 
sollte der Coregen eine Netzliste (*.ncd) rauswerfen, den VHDL-code den 
du da siehst ist für die Simu oder ein Wrapper damiti die primitive in 
den Top-level passen.


> Ich vermute,
> dass viele Hersteller FPGAs mit ähnlichen Eigenschaften produzieren und
> dass sie zunehmend Versuchen, mit proprietären Tools die Benutzer an
> sich zu binden.

Nein, die Hersteller binden den Kunden mit spezif Eigenschaften ihres 
FPGA's und über den Preis. Da die tools eh meist verschenkt sind kann 
man damit keine Kunden binden. bestenfalls die dummen/faulen die die 
Portierung Ihres design scheuen.

> Wenn man ein größeres Design mit einem der Tools gemacht
> hat, wird es einem sehr schwer fallen auf das FPGA eines anderen
> Herstellers umzuziehen.

Nein.

> Dem möchte ich entgegen wirken, in dem ich nach "generischen" Designs
> suche, die überall laufen.

Das ist doch easy, mach einfach für jede Architektur jeweils den 
passendn Code und schalte per Präprozessor (#ifdef) um. Oder 
benutze/entwickle einen Coregenerator der den für die jeweilige 
Architektur optimalen VHDL-Code auswirft.

Autor: C. A. Rotwang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:

> Was mir bisher auffällt: Die Ram-Designs haben fast nie
> Tristate-Datenanschlüsse so wie es bei physischen RAM-Bausteinen der
> Fall ist, sondern immer getrennte Ein- und Ausgänge. Sehe ich das
> richtig?

Nicht ganz, bis auf historische FPGA's (Spartan/Virtex 2?) sollte kein 
FPGA interne Tristates besitzen.

> Meine Vermutung: wenn es getrennte Daten Ein- und Ausgänge gibt, kann
> man schneller Designs machen, braucht aber mehr Glue-Logic, weil man
> keinen Tri-State-Bus verwenden kann.

wenn du "schnell designs machen" meinst dann nein wenn du aber 
schnell*ere* designs machen" meinst dann ja. Der Tristatebus ist einfach 
erweiterbar, denk mal an Steckkarten und wirklich aufwendig sind 
multiplexer im FPGA nicht wirklich.
Beitrag "Open Collector und Tristate"
Beitrag "Problem mit tristate Bus"
https://books.google.de/books?id=D0_pBQAAQBAJ&pg=P... 
tristate bus&f=false
https://www.quora.com/Can-Z-in-VHDL-be-synthesized-for-FPGAs

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

Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> Das würde bedeuten, dass Dein Fifo-Design
> http://www.lothar-miller.de/s9y/archives/21-FIFO.html
> nicht "generisch" ist, sondern z.B. nur auf Xilinx-FPGAs läuft.
> Scheinbar läuft es aber auch auf meinem MachX02.
Glück gehabt, Lottoschein her!
Natürlich wird der Fifo dort auf jedem FPGA implementiert. Nur kann es 
eben sein, dass kein RAM-Block verwendet wird, sondern alles auf 
Flipflops abgebildet wird.

C. A. Rotwang schrieb:
> Nein, VHDL ist garnicht für FPGA-Synthese gemacht sondern für die
> Verifikation von Digitaler Logic
Es funktioniert meiner Ansicht nach aber trotzdem gar nicht mal so 
schlecht...

: Bearbeitet durch Moderator
Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C. A. Rotwang schrieb:
> Nein, VHDL ist garnicht für FPGA-Synthese gemacht sondern für die
> Verifikation von Digitaler Logic

Tatsächlich, das steht hier beschrieben:
http://www.gaisler.com/doc/vhdl2proc.pdf
"When the language was first put to use, it was used for high-level 
behavioural simulation only . ’Synthesis’ into VLSI devices was made 
by manually converting the models into schematics using gates and 
building blocks from a target library."


Jetzt erklärt sich mir auch die seltsame "Zweiteilung" dass manche 
Ausdrücke wie z.B. die "sensivity list ( process )" nur Einfluss auf die 
Simulation nicht aber auf die Synthese haben.

Das Ganze ist schlich historisch gewachsen.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Das würde bedeuten, dass Dein Fifo-Design
>> http://www.lothar-miller.de/s9y/archives/21-FIFO.html
>> nicht "generisch" ist, sondern z.B. nur auf Xilinx-FPGAs läuft.
>> Scheinbar läuft es aber auch auf meinem MachX02.
Lothar Miller schrieb
>Glück gehabt, Lottoschein her!
>Natürlich wird der Fifo dort auf jedem FPGA implementiert. Nur kann es
>eben sein, dass kein RAM-Block verwendet wird, sondern alles auf
>Flipflops abgebildet wird.

Ich finde, dass sollte hier ein ausdrücklicher Hinweis hin, dass das nur 
für Xilinx-FPGAs gilt:
http://www.lothar-miller.de/s9y/archives/20-RAM.html

Autor: Markus F. (mfro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> Ich finde, dass sollte hier ein ausdrücklicher Hinweis hin, dass das nur
> für Xilinx-FPGAs gilt:
> http://www.lothar-miller.de/s9y/archives/20-RAM.html

Ich finde, da sollte ein ausdrücklicher Hinweis hin, dass man beim 
allerersten Satz mit Lesen (und Verstehen) anfangen sollte.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja mit dem Lesen ist das so eine Sache. Denn wer schaut denn heute noch 
genau hin und versucht, etwas genau zu verstehen?

Da steht:
"Wer mit Xilinx FPGAs anfängt, der braucht früher oder später mal ein 
RAM."

Da steht nicht, wer sich mit Lattice FPGAs beschäftigt, braucht kein 
Ram. Oder es steht auch nicht da, dass folgende Zeilen nur für Xilinx 
FPGAs gemacht sind.
Es kann zwar vermutet werden, dass der Autor sich mit Xilinx FPGAs 
beschäftigt hat und vermutlich alle Beispiele auf Xilinx-FPGAs getestet 
sind. Das ist aber keinerlei Hinweis darauf, dass es mit FPGAs anderer 
Hersteller grundsätzlich so nicht geht.

Autor: Markus F. (mfro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> Es kann zwar vermutet werden, dass der Autor sich mit Xilinx FPGAs
> beschäftigt hat und vermutlich alle Beispiele auf Xilinx-FPGAs getestet
> sind. Das ist aber keinerlei Hinweis darauf, dass es mit FPGAs anderer
> Hersteller grundsätzlich so nicht geht.

... und ebensowenig einer, dass es mit FPGAs anderer Hersteller 
genauso geht

ich persönlich bin froh (deshalb hier nochmal ein "Danke"), dass der 
Lothar das so einfach und übersichtlich aufgeschrieben hat (auch wenn 
ich möglicherweise mit meinen Alteras noch was ändern muss) und käme nie 
auf die Idee dranrumzumäkeln, dass ich doch tatsächlich noch ein wenig 
selber denken muss.

Vielleicht solltest Du deine Anspruchshaltung kurz überdenken.

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

Bewertung
0 lesenswert
nicht lesenswert
Ich verweise mal ganz lapidar auf die Doku der jeweiligen Toolchain. 
Denn etwas, das vor ein paar Jahren geschrieben wurde gilt nicht 
unbedingt immer und ewig. Manche sind auch heute noch der Meinung, ein 
"wait for rising_edge()" könne nicht synthetisiert werden...

Autor: Gustl Buheitel (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> Ja mit dem Lesen ist das so eine Sache. Denn wer schaut denn heute noch
> genau hin und versucht, etwas genau zu verstehen?
>
> Da steht:
> "Wer mit Xilinx FPGAs anfängt, der braucht früher oder später mal ein
> RAM."
>
> Da steht nicht, wer sich mit Lattice FPGAs beschäftigt, braucht kein
> Ram. Oder es steht auch nicht da, dass folgende Zeilen nur für Xilinx
> FPGAs gemacht sind.
> Es kann zwar vermutet werden, dass der Autor sich mit Xilinx FPGAs
> beschäftigt hat und vermutlich alle Beispiele auf Xilinx-FPGAs getestet
> sind. Das ist aber keinerlei Hinweis darauf, dass es mit FPGAs anderer
> Hersteller grundsätzlich so nicht geht.

Sag mal selber ausprobieren oder die Dokumentationen der Hersteller 
lesen ist nicht so Dein Ding? Die Beschreibung die Lothar auf seiner 
Seite hat funktioniert auch prima bei Alters/Intel. Dual Port sollte 
auch möglich sein ohne Coregen wenn man es sauber hinschreibt so dass es 
die Toolchain versteht. Probiere das doch mal aus und gucke was die 
Software macht.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Sag mal selber ausprobieren oder die Dokumentationen der Hersteller
>lesen ist nicht so Dein Ding?
Das mit der Mühe ist so eine Sache. Nicht jeder macht sich z.B. die 
Mühe, so einen Thread durchzulesen.

>Die Beschreibung die Lothar auf seiner
>Seite hat funktioniert auch prima bei Alters/Intel.

sonst hättest Du meine Bemerkung oben nicht übersehen:
chris schrieb
>Scheinbar läuft es aber auch auf meinem MachX02.

Autor: Weltbester FPGA-Pongo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C. A. Rotwang schrieb:
> Nicht ganz, bis auf historische FPGA's (Spartan/Virtex 2?) sollte kein
> FPGA interne Tristates besitzen.
Das waren FPGAs aus der Steinzeit. Genau genommen waren es keine FPGAs, 
sondern PLDs. Das Thema kann man abhaken.

Dennoch gibt es selbstredend Tristates:


C. A. Rotwang schrieb:
> chris schrieb:
>> Meine Vermutung: wenn es getrennte Daten Ein- und Ausgänge gibt, kann
>> man schneller Designs machen, braucht aber mehr Glue-Logic, weil man
>> keinen Tri-State-Bus verwenden kann.
> wenn du "schnell designs machen" meinst dann nein wenn du aber
> schnell*ere* designs machen" meinst dann ja.
Redet ihr aneinander vorbei?

Was hat denn ein schnelles design mit Tristates zu tun?

@chris: Nochmal: Lies Dir bitte die einschlägigen Herstellerangaben 
durch, statt hier einen Anfängerartikel nach dem anderen aufzumachen.

FPGAs haben sehr wohl Tristates und zwar an praktisch allen Ein-und 
Ausgangen. Gerade die Trennung in Ein-Aus IST die Voraussetzung für eine 
Tristatefunktion, nämlich, indem man den Ausgang wegschaltet und den 
Eingang aktiv lässt. Sonst ginge das nämlich gar nicht.

Sieh Dir einfach mal die IO-Schaltung der Pins an.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Was hat denn ein schnelles design mit Tristates zu tun?
Bsp: Eine MasterDevice hat getrennte Daten Ein- und Ausgänge. Es kann 
daher gleichzeitig lesen und Schreiben, während mit einem Tristate-Bus 
immer nur eine Richtung möglich wäre.

Kleiner Merker für mich selbst:

VHDL Signaldefintion "buffer" => nur Ausgang mit Tristate Möglichkeit, 
man kann den geschriebenen Wert auch lesen, nicht aber den von außen 
zugeführten Wert, wenn hochohmig geschaltet.

VHDL Signaldefintion "inout" => Kann hochohmig geschalten werden, 
externer Wert wird kann im hochohmigen Zustand gelesen werden.

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

Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
> Kleiner Merker für mich selbst: ...
Ist insofern falsch, als natürlich jeder Ausgang am FPGA-Pin (egal ob 
out, buffer oder inout) hochohmig geschaltet werden kann.

Autor: C. A. Rotwang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Weltbester FPGA-Pongo schrieb im Beitrag #5192146:

> Dennoch gibt es selbstredend Tristates:
>
>
> C. A. Rotwang schrieb:
>> chris schrieb:
>>> Meine Vermutung: wenn es getrennte Daten Ein- und Ausgänge gibt, kann
>>> man schneller Designs machen, braucht aber mehr Glue-Logic, weil man
>>> keinen Tri-State-Bus verwenden kann.
>> wenn du "schnell designs machen" meinst dann nein wenn du aber
>> schnell*ere* designs machen" meinst dann ja.
> Redet ihr aneinander vorbei?
>
> Was hat denn ein schnelles design mit Tristates zu tun?

> FPGAs haben sehr wohl Tristates und zwar an praktisch allen Ein-und
> Ausgangen.

Es geht hier um interne Tristates, also die Ausgänge der RAM-Blöcke im 
FPGA und die haben keine Tristates, da wird alles gemuxed. Gründe dafür 
sollen "Signal integrety" und Stromaufnahme sein, 
https://www.quora.com/Can-Z-in-VHDL-be-synthesized-for-FPGAs ; wobei ich 
aber auch denke das point2point Verbindungen schneller takt- und 
umschaltbar sind als Busse.

Autor: Weltbester FPGA-Pongo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C. A. Rotwang schrieb:
> Es geht hier um interne Tristates
das hatte Ich durchaus aufgenommen und auch beantwortet, zudem nur noch 
hinzugefügt, dass es ja die Externen gibt um das Thema vollständig 
darzustellen.

Zu der Frage, ob Tristates schneller wären, würde Ich sagen: Auch für 
die Internen "Nein", weil Ich auf 2 Leitungen keine laufzeitbedingten 
Umschaltpausen brauche und mit 100% streamen kann.

Es braucht nur viele Verschaltungsresourcen - besonders bei 
SOC-Systemen!

Sowas wie 2 hoch n+1 , bei n = Zahl der Zeilnehmer.

Wenn man aber weiß, wie FPGAs intern aufgebaut sind und dass sie aus 
topologischen Gründen mit sehr viel Verschaltungstechnik im Vergleich 
zur Logik daherkommen (müssen, wegen der vielen Optionen), der versteht, 
warum man dort nicht auch noch bidirektionale Leitungen gebrauchen kann.

Die Informationen werden durch Relaisstationen allenthalben 
aufgefrischt, vor allem die Takte und Resets und dies geht nur in eine 
Richtung.

Echte lange Leitungen, die von zwei Seiten getrieben werden gibt es dort 
nur über 1-2mm und weniger und damit ist nichts anzufangen. Bei PLDs zog 
sich das quer durchs Design. Mit einer Schleife über mehrere Knoten 
hinweg hattest Du da mal gegatete und umgedrehte Signalinformatinoen 
aber dafür gerne mal 10ns an der Backe.

Das kann man in modernen Schaltungen nicht gebrauchen, in denen ein 
Signal wenn möglich binnen 100ps an jeder Ecke im FPGA sein muss.

Das steht allerdings alles schon in den Grundlagenartikeln hier und 
anderswo. Immer noch mehr chris-Themen brauchen wir dafür wohl nicht.

Autor: Markus W. (dl8mby)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Lothar Miller

Hallo Lothar,

ist dann Deine Aussage auch aufs FPGA Wiki im MC-Forum anwendbar?

>Denn etwas, das vor ein paar Jahren geschrieben wurde gilt nicht
>unbedingt immer und ewig. Manche sind auch heute noch der Meinung, ein
>"wait for rising_edge()" könne nicht synthetisiert werden...

siehe
https://www.mikrocontroller.net/articles/VHDL

Richtlinien Für VHDL Anfänger
>Kein "after", "wait for" o.ä. verwenden, das ist nicht synthetisierbar

oder muss der o.g. Beitrag aktualisiert werden?


Danke für Deine Erklärung im Voraus

Markus

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

Bewertung
0 lesenswert
nicht lesenswert
Markus W. schrieb:
> oder muss der o.g. Beitrag aktualisiert werden?
Nein, denn ein "wait for" ist tatsächlich noch nicht synthetisierbar. 
Das war  ein Typo, ich meinte ein "wait until"... :-/

Und das geht schon lange, zwischenzeitlich dürfte das jeder können:
http://www.lothar-miller.de/s9y/archives/16-Takt-i...

Es ghte aber evtl. noch einiges mehr, wobei sowas dann schnell in 
Richtung "Trickserei" geht:
http://www.lothar-miller.de/s9y/archives/47-wait-i...

Autor: Markus W. (dl8mby)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für Die Links!

Markus

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.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.