Hallo Leute,
ich brauche von euch einen Rat zur Speicherverwaltung, ich hoffe ihr
habt mir da nen Tip.
PROBLEMSTELLUNG:
================
Ich habe 32 Instanzen (welche mir ein Signal vermessen) implementiert
die mir ein Ergebnis, jeweils ein Flag (measured) und zwei Werte
(mem_rising_edge_val_out, mem_falling_edge_val_out) bei Beendigung einer
abgeschlossenen Messung, übergeben:
1
:
2
inst_CAM_MEASURE_V3_00:CAM_MEASURE_V3
3
portmap(
4
clk=>clk,
5
syn_n_reset=>syn_n_reset,
6
new_measure=>new_measure_rising,
7
path_in=>in00,
8
cam_in=>(others=>'0'),
9
counter_in=>in_counter,
10
11
mem_rising_edge_val_out=>xmem_v2(8).reg,
12
mem_falling_edge_val_out=>xmem_v2(9).reg,
13
measured=>xmem_v2(7).reg(0)
14
);
15
:
Die Daten sollen nun in einen gemeinsamen Speicher (xmem_v2) geschrieben
werden:
Jetzt nun meine Frage:
=======================
Wie kann ich den Zugriff auf ein und denselben Speicher handeln?
Gibt es hier eine einfache und gute Methode?
Hat jemand von euch schon mal so etwas gemacht?
Vielen Dank
MemY
@ MemY (Gast)
>Wie kann ich den Zugriff auf ein und denselben Speicher handeln?
Meisten mit der DUAL PORT Funktion, den heute alle FPGA-Speicher haben.
Ein Port schreibt nur die Daten vo deinen 32 Instanzen, der andere macht
R/W Zugriffe vom Bus aus.
>Gibt es hier eine einfache und gute Methode?
Je nach Timing der Messergebnisse reicht eine einfache Statemachine +
MUX, die einfach der Reihe nach deine Module abklappert und bei Bedarf
das Ergebnis speichert. Oder man braucht dazwischen ein paar FIFOs, wenn
die Ergenisse eher burstartig entstehen. Das Grundgerüst ist aber das
Gleiche.
Die Fifos wird man schon brauchen, meine ich, weil sicher irgendwann
einmal zwei gleichzeitig schreiben werden. Da man die FiFos ohnehin
braucht, kann man es auch gleich so machen, dass alle immer schreiben
und eine Leseroutine ausliest.
Die linke Seite des BRAMs muss dann einfach 32x grösser sein, als die
Rechte.
@ Markus Wagner (Firma: Ingenieurbüro) (elektrowagi78) Benutzerseite
>Die Fifos wird man schon brauchen, meine ich, weil sicher irgendwann>einmal zwei gleichzeitig schreiben werden.
Das weiß du gar nicht.
>Die linke Seite des BRAMs muss dann einfach 32x grösser sein, als die>Rechte.
Auch das ist reine Spekulation.
Falk Brunner schrieb:> Meisten mit der DUAL PORT Funktion, den heute alle FPGA-Speicher haben.> Ein Port schreibt nur die Daten vo deinen 32 Instanzen, der andere macht> R/W Zugriffe vom Bus aus.
Ja an so etwas habe ich auch schon gedacht... das sollte gehen. Nur
sollte ich aus Sicht des einen Ports die Daten der 32 Instanzen
zusätzlich per infacher Statemachine + MUX (wie von dir unten
beschrieben) hineinschreiben. Oder? Also bräuchte ich in Summe eine
Statemachine, einen Mux und einen Dual Port Ram?
> Je nach Timing der Messergebnisse reicht eine einfache Statemachine +> MUX, die einfach der Reihe nach deine Module abklappert und bei Bedarf> das Ergebnis speichert. Oder man braucht dazwischen ein paar FIFOs, wenn> die Ergenisse eher burstartig entstehen. Das Grundgerüst ist aber das> Gleiche.
Das wäre mir die liebste und einfachste Methode. Jedoch stellt sich hier
die Frage, ob das Timing für den Avalon MM Bus ausreicht?
Die Module können ja ihre Daten erst mal in jeweils zwei Registen
ablegen und das Flag für neue Daten setzen. Wenn alle Flags gesetzt
sind, rennt die FSM einmal im Kreis und sammelt alle Daten aus den
Registern ein, schreibt die in einen BRAM und löscht das Flag wieder.
MemY schrieb:> Ich habe 32 Instanzen implementiert die mir ein Ergebnis,> bei Beendigung einer abgeschlossenen Messung, übergeben...
Wenn die Messungen jeweils länger als 32 Takte dauern und du den Start
der Messung geschickt steuerst, dann kommen die Ergebnisse nicht
gleichzeitig, sondern nacheinander. Und für einen zeitversetzten
Zugriff auf einen Speicher ist nur ein Multiplexer nötig...
Dann bleibt nur noch der Zugriff vom Prozessorbus. Und der geschieht am
einfachsten über ein DPRAM, das in jedem FPGA implementiert ist.
MemY schrieb:> Das wäre mir die liebste und einfachste Methode. Jedoch stellt sich hier> die Frage, ob das Timing für den Avalon MM Bus ausreicht?
Es ist eher das übliche Semaphoren-Problem: wenn du gleichzeitig vom
Prozessor lesend auf den Speicher zugreifst, währen neu Messwerte
eingetragen werden, dann kann es sein, dass die Daten inkonsistent sind.
Dagegen hilft dann irgendein ein Handshakeverfahren, das einen
exklusiven Zugriff auf den Speicher garantiert.
Duke Scarring schrieb:> Wie oft haben denn Deine Instanzen einen neuen Wert?> Mit jedem Takt? Alle 32 Takte? Unregelmäßig? Gleichzeitig?
Die Instanzen liefern neue Werte im 0,5 bis 1 Sekundenbereich. Ist also
nicht zeitkritisch. Nur können die Werte der einzelenen Instanzen
gleichzeitig auftreten.
Ich bin jetzt derzeit an einer Lösung mit einem DPRAM (so wie schon
mehrfach von Euch erwähnt). Allerdings muss ich ja das DPRAM auch wieder
instanzieren und mit Signalen "verdrahten". Das DPRAM muss ja auch noch
mittels eines nacheinander getakteten MUX gefüttert werden. Das alles
scheint mir schon ziemlich aufwendig... Bin ich da auf nem Holzweg?
MemY schrieb:> Allerdings muss ich ja das DPRAM auch wieder> instanzieren und mit Signalen "verdrahten". Das DPRAM muss ja auch noch> mittels eines nacheinander getakteten MUX gefüttert werden. Das alles> scheint mir schon ziemlich aufwendig...
der Aufwand ist genau der Problemstellung angemessen - und so wild ist
er jetzt auch wieder nicht.
MemY schrieb:> Die Instanzen liefern neue Werte im 0,5 bis 1 Sekundenbereich. Ist also> nicht zeitkritisch. Nur können die Werte der einzelenen Instanzen> gleichzeitig auftreten.
Dann schreib die ankommenden Werte alle zunächst in 32 Register, um mit
dem gleichzeitigen Auftreten neuer Werte klarzukommen, und merke dir die
Ankunft neuer Daten mit 32 Flags. Die Statemachine klappert dann
gemütlich die Flags ab und transferiert neue Werte ins DPRAM - 500ms
sind ja reichlich Zeit dafür. Ob die Instanz auch gleich die Zieladresse
im Speicher mitliefert, oder ob die von der FSM berechnet wird, musst du
wissen.
Oh, ich sehe gerade, dass Christian das auch schon vorgeschlagen hat. Na
ja, macht ja nichts, dann hast du den Vorschlag jetzt halt doppelt.
@ MemY (Gast)
>Die Instanzen liefern neue Werte im 0,5 bis 1 Sekundenbereich. Ist also>nicht zeitkritisch. Nur können die Werte der einzelenen Instanzen>gleichzeitig auftreten.
Gähnend langweilig. Das FPGA friert dabei quasi ein.
>Ich bin jetzt derzeit an einer Lösung mit einem DPRAM (so wie schon>mehrfach von Euch erwähnt). Allerdings muss ich ja das DPRAM auch wieder>instanzieren und mit Signalen "verdrahten". Das DPRAM muss ja auch noch>mittels eines nacheinander getakteten MUX gefüttert werden.
Ja und?
>Das alles>scheint mir schon ziemlich aufwendig... Bin ich da auf nem Holzweg?
Dann such dir eine andere Beschäftigung. Apps downloaden oder
BILD-Zeitung lesen kommen dir da deutlich entgegen.
Achim S. schrieb:> Dann schreib die ankommenden Werte alle zunächst in 32 Register, um mit> dem gleichzeitigen Auftreten neuer Werte klarzukommen, und merke dir die> Ankunft neuer Daten mit 32 Flags. Die Statemachine klappert dann> gemütlich die Flags ab und transferiert neue Werte ins DPRAM - 500ms> sind ja reichlich Zeit dafür. Ob die Instanz auch gleich die Zieladresse> im Speicher mitliefert, oder ob die von der FSM berechnet wird, musst du> wissen.
Die 32 Flags (measured) habe ich bereits (steht irgendwo im ersten Post
von mir). Im Prinzip könnte ich ja auch die Daten kontinuierlich ins
DPRAM ablegen...
> Oh, ich sehe gerade, dass Christian das auch schon vorgeschlagen hat. Na> ja, macht ja nichts, dann hast du den Vorschlag jetzt halt doppelt.
Hab schon damit Angefangen dieses Konzept umzusetzen ;-)
MemY schrieb:> Die 32 Flags (measured) habe ich bereits (steht irgendwo im ersten Post> von mir).
Hm, ich hätte dein Flag "measured" so interpretiert, dass es für einen
Takt (oder länger) auf high geht, wenn die Instanz neue Daten liefert
(kann sein, dass ich daneben liege, das sehe ich deinem Code nicht so
eindeutig an).
Dann brauchst du aber noch ein Flag, das im Prozess der FSM gesetzt
wird, wenn neue Daten ins Register geschrieben wurden. Und es muss im
Prozess der FSM zurückgesetzt werden, wenn die daten vom Register ins
DPRAM transferiert wurden.
MemY schrieb:> Im Prinzip könnte ich ja auch die Daten kontinuierlich ins> DPRAM ablegen
Heißt das, es ist dir egal, wenn Daten mehrfach ins RAM geschrieben
werden, weil sie sowieso auf die selbe Adresse geschrieben werden und
jeder Instanz eine Adresse zugeordnet ist? In dem Fall wird es
tatsächlich noch einfacher. Dann könntest du auch den Vorschlag von
Markus realisieren und die FSM weglassen.
Markus W. schrieb:> Die linke Seite des BRAMs muss dann einfach 32x grösser sein, als die> Rechte.
Achim S. schrieb:> Heißt das, es ist dir egal, wenn Daten mehrfach ins RAM geschrieben> werden, weil sie sowieso auf die selbe Adresse geschrieben werden und> jeder Instanz eine Adresse zugeordnet ist? In dem Fall wird es> tatsächlich noch einfacher. Dann könntest du auch den Vorschlag von> Markus realisieren und die FSM weglassen.
Ja, genau.
MemY schrieb:> Die 32 Flags (measured) habe ich bereits (steht irgendwo im ersten Post> von mir). Im Prinzip könnte ich ja auch die Daten kontinuierlich ins> DPRAM ablegen...
Naja, aber im unwahrscheinlichen aber trotzdem möglichen Fall von zwei
oder mehr Modulen die genau gleichzeitig fertig sind, hast du ein
Problem. So ein DPRAM hat pro Port auch nur einen Adress-Bus, und
gleichzeitig Schreiben an verschiedene Adressen geht natürlich nicht.
MemY schrieb:> Ja, genau.
Heißt das dann im Endeffekt, dass du eigentlich überhaupt keinen
Speicher bräuchtest sondern nur einen MUX, der die Ausgangsregister
deiner Instanzen an den Avalon-Bus anbindet? Aus Sicht des Buszugriffes
würde das immer noch wie ein kleiner Speicher aussehen.
Achim S. schrieb:> Heißt das dann im Endeffekt, dass du eigentlich überhaupt keinen> Speicher bräuchtest sondern nur einen MUX, der die Ausgangsregister> deiner Instanzen an den Avalon-Bus anbindet? Aus Sicht des Buszugriffes> würde das immer noch wie ein kleiner Speicher aussehen.
Ja im Prinzip schon. Ich möchte vom Avalon-Bus in den Speicher schreiben
und lesen. Gleichzeitig von meinen Instanzen in den selben Speicher
schreiben.
Christian R. schrieb:> Naja, aber im unwahrscheinlichen aber trotzdem möglichen Fall von zwei> oder mehr Modulen die genau gleichzeitig fertig sind, hast du ein> Problem. So ein DPRAM hat pro Port auch nur einen Adress-Bus, und> gleichzeitig Schreiben an verschiedene Adressen geht natürlich nicht.
Deshalb brauche ich zwingend eine Statemachine + MUX.
Thread beobachten
Seitenaufteilung abschalten