Hallo,
bei meinem Versuch eine cache qsys Komponente zu entwerfen (source im
Anhang) bin ich auf das Problem gestoßen das der compiler Register für
RAM pass-through logic für arrays einfügt, obwohl meiner Meinung nach
niemals ein gleichzeitiger Lese- und Schreibzugriff statt findet.
Warning (276020): Inferred RAM node
"system:cpu0|icache:inst_cache|cacheTags_rtl_0" from synchronous design
logic. Pass-through logic has been added to match the read-during-write
behavior of the original design.
Info (276014): Found 3 instances of uninferred RAM logic
Info (276007): RAM logic "system:cpu0|icache:inst_cache|cacheTags"
is uninferred due to asynchronous read logic File:
C:/altera_lite/cache001/system/synthesis/submodules/icache.vhd Line: 45
Info (276007): RAM logic
"system:cpu0|icache:inst_cache|cacheBlocksMemory" is uninferred due to
asynchronous read logic File:
C:/altera_lite/cache001/system/synthesis/submodules/icache.vhd Line: 48
Info (276004): RAM logic
"system:cpu0|system_mm_interconnect_0:mm_interconnect_0|altera_avalon_sc
_fifo:sdram_controller_s1_agent_rdata_fifo|mem" is uninferred due to
inappropriate RAM size File:
C:/altera_lite/cache001/system/synthesis/submodules/altera_avalon_sc_fif
o.v Line: 108
Error (276003): Cannot convert all sets of registers into RAM
megafunctions when creating nodes. The resulting number of registers
remaining in design exceeds the number of registers in the device or the
number specified by the assignment
max_number_of_registers_from_uninferred_rams. This can cause longer
compilation time or result in insufficient memory to complete Analysis
and Synthesis
Kann mir das jemand versuchen zu erklären?
Ich könnte mir noch vorstellen das es daher kommt das ich nur einen
Prozess habe (die state-machine) und darin natürlich auf die arrays
lesend und schreibend zugegriffen wird, aber durch das case Konstrukt
ist das ja wieder gar nicht möglich.
Ich konnte den Fehler beheben in dem ich die arrays etwas zuasmmengefasst habe, jedoch jetzt wird das design viel zu groß (> 59000 LE, >25000 CF, >35000 LR) liegt das etwa an den if Konstrukten?
Christian G schrieb: > jetzt wird das design viel zu groß (> 59000 LE, >25000 CF, >35000 LR) > liegt das etwa an den if Konstrukten? Bist du sicher, dass das allein von genau diesem Modul kommt? Hast du mal nur genau dieses Modul ins FPGA gepackt (das.Ist ja kein allzu großer Aufwand...)? Üblicherweise "explodiert" ein Design nämlich dann, wenn der Synthesizer es nicht schafft, RAM zu verwenden, sondern alles aus einzelnen Flipflops zusammenbasteln muss. Die letzte Meldung aus dem ersten Post deutet das an...
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Christian G schrieb: >> jetzt wird das design viel zu groß (> 59000 LE, >25000 CF, >35000 LR) >> liegt das etwa an den if Konstrukten? > Bist du sicher, dass das allein von genau diesem Modul kommt? Hast du > mal nur genau dieses Modul ins FPGA gepackt (das.Ist ja kein allzu > großer Aufwand...)? nein, es ist noch ein qsys basis-system mit nios, sdram controller, jtag uart etc vorhanden. > Üblicherweise "explodiert" ein Design nämlich dann, wenn der Synthesizer > es nicht schafft, RAM zu verwenden, sondern alles aus einzelnen > Flipflops zusammenbasteln muss. Die letzte Meldung aus dem ersten Post > deutet das an... ja genau das ist auch passiert, habe den RTL viewer gefunden und gesehen das es ein riesen Knäul aus Registern, FlipFlops selector etc geworden ist... also im Grunde habe ich da murks gebaut. Bin dann aber noch mal in mich gegangen und habe versucht das ganze etwas, ja wie soll ich sagen, auseinander zu ziehen, die einzelnen arrays sind nun eigene Komponenten geworden die auch entsprechend in Sync Rams umgesetzt wurden, keine loops mehr, weniger Typ Konvertierungen, einfach nicht so viel auf einamal in einem Takt tun, mal die Jahrzehnte Softwareprogrammierung weiter nach hinten in die Birne verschoben... Ich habe den Teil wo ein cache block aus dem sdram geladen und intern gespeichert wird noch nicht wieder eingebaut, und bis jetzt bin ich bei ~2900LE, ~2250 CF, ~1800 Register inklusive dem Qsys system (auf das der Hauptanteil der resourecen abfällt). und im RTL viewer ist es jetzt auch viel aufgeräumter, mal gucken was passiert wenn der Rest implementiert ist. Zu den Sync RAMs die da aus meinen cache Komponenten erstellt wurden hätte ich noch ne Frage... Die sehn ungefähr so aus
1 | >clock |
2 | >reset (benötige ich eigentlich nur bei einem) |
3 | >index |
4 | >read |
5 | >write |
6 | <outData |
7 | >inData |
8 | |
9 | read_proc :proc (clock, read, write) |
10 | if rising edge clock then |
11 | if read = 1 then |
12 | outData <= array(index) |
13 | elsif write = 1 then |
14 | array(index) <= inData; |
15 | end if |
16 | end if |
17 | end proc ... |
um jetzt zu lesen setzte ich in einem Takt read = 1 und den index Wert, im nächsten Takt setze ich read = 0, und lese dann im folgenden Takt das Datum ...also benötigt das ganze 3 Takte, geht das auch schneller? Meinem Verständniss nach sieht das "RAM" beim zweiten Takt das read = 1 und setzt den outData Wert welcher dann im nächsten Takt stabil ist und gelesen werden kann also die Komponente an sich benötigt nur 2 Takte zum lesen und schreiben aber durch das steuern von aussen aus der state-machine kommt ein weiterer Takt hinzu. Sehe ich das so richtig? VG Christian G.
Ich glaube ich habe es hinbekommen, passt alles super von den Resourcen, jetzt noch ausgiebig testen... wie kann man in dieser Quartus Software denn nun eigentlich die "Güte" des ganzen vernünftig feststellen? Max Signallaufzeiten etc. ?
Christian G schrieb: > wie kann man in dieser Quartus Software denn nun eigentlich die "Güte" > des ganzen vernünftig feststellen? Wenn du keine Vorgaben (Constraints) machst, dann gibt sich die Toolchain hinsichtlich des Timings keine "Mühe". Es reicht ihr aus, wenn sie das Design implementiert bekommt. Denn das war bis dahin nach ihrem "Wissen" dein einziger Wunsch... Zuerst und mindestens muss man also ein Timing Constraint auf den verwendeten Takt angeben, mit dem das Design laufen soll. Wenn das Design dann diesen gewünschten Takt erreicht, ist auch wieder alles "gut". Es wird nicht versucht, das "beste" Design zu bekommen. > Max Signallaufzeiten etc. ? Wenn die gewünschte Taktfrequenz nich erreicht wird, muss die statische Timinganalyse (STA) her. die zeigt dann, wo der kritische Pfad liegt, und wie dicht andere ähnlich langsame Pfade daran liegen.
Lothar M. schrieb: > Wenn du keine Vorgaben (Constraints) machst, dann gibt sich die > Toolchain hinsichtlich des Timings keine "Mühe". Es reicht ihr aus, wenn > sie das Design implementiert bekommt. Denn das war bis dahin nach ihrem > "Wissen" dein einziger Wunsch... > Zuerst und mindestens muss man also ein Timing Constraint auf den > verwendeten Takt angeben, mit dem das Design laufen soll. Wenn das > Design dann diesen gewünschten Takt erreicht, ist auch wieder alles > "gut". Es wird nicht versucht, das "beste" Design zu bekommen. Danke Lothar M. für die ganzen Tips, die timing analyse sagt zwar timing not met in allen 3 Modellen (slow 85C, slow 0C und fast 0C) aber es ist jeweils immer die altera_reserved_tck (JTAG UART) welche Rote Werte anzeigt bei setup (negativ slack). Fmax ist bei slow 85C ~109 MHz, bei slow 0C ~120 MHz und fast 0C ~180 MHz. Da ich für das endgültige Vorhaben nicht mehr als 100 MHz Takt benötige bin ich doch im Moment auf der sicheren Seite, oder? Es ist wirklich eine ganze Menge mir bisher unbekannter Dinge die es bei der Entwicklung zu berücksichtigen und zu beherzigen gilt, dieses habe ich echt unterschätzt. Gut ne LED zum blinken zu bringen war zu Anfang nach ein, zwei tutorials und etwas Eingewöhnung an die Programmiersprache und Entwicklungsumgebung eigentlich kein Hexenwerk, von daher hatte ich echt gehofft das es so easy weiter geht. Aber bei diesem Vorhaben war das echt Wunschdenken. Der ein oder andere hätts vielleicht inner Stunde fertig gehabt und sich dann gelangweilt, aber für meine ersten Gehversuche ist es schon anspruchsvoll. Jetzt muss es am Ende nur noch genau das tun was es auch soll :) VG Christian G.
Wozu wird denn der Reset genau verwendet? Um die Register zu setzen? Das RAM wird man nur resetten können, wenn es aus Distri besteht. Ich würde das eher weglassen. Wahrscheilich muss es aber rein, weil sonst das vordefinierte IF nicht läuft.
Weltbester FPGA-Pongo schrieb im Beitrag #4612406: > Wozu wird denn der Reset genau verwendet? Um die Register zu setzen? Das > RAM wird man nur resetten können, wenn es aus Distri besteht. eigentlich ist es überflüssig, habe es nur benutzt um im reset Zustand den cache auch wirklich zu resetten (cacheblock valide bit wird auf 0 gesetzt) Beim TAGmem und CACHEmem habe ich es weg gelassen. Da die BITmems nur 32 Einträge haben könnte ich im Prnzip genauso gut auch einen std_logic_vector(31 downto 0) nehmen, aber ob das einen Mehrwert hat...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.