VHDL Grundlagen Ram

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-core-generator

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:

1

sysclk

2

3

adr0

4

dataIn0

5

dataOut0

6

wr0

7

rd0

8

ready0

9

10

adr1

11

dataIn1

12

dataOut1

13

wr1

14

rd1

15

ready1

Was meint Ihr?

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

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

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-asked-questions-about-async-dual-ports

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/00_hw/src/pibla.vhd?annotate=2 
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/redz0mb1e/src/vhdl/video_ram.vhd?view=markup

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/application_notes/xapp463.pdf

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

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

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 ;-)

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

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.

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=PA336&lpg=PA336&dq=FPGA+++tristate+bus&source=bl&ots=16b9dpI9zm&sig=1iWC4efNNUq3f_jO_azTv-uzk7o&hl=de&sa=X&ved=0ahUKEwi7tKmk9JLXAhULExoKHWo7BfQQ6AEIfzAJ#v=onepage&q=FPGA 
tristate bus&f=false
https://www.quora.com/Can-Z-in-VHDL-be-synthesized-for-FPGAs

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.

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

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

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.

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

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.

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.