Beste Nutzung des M9K-Speichers in Max10 oder anderen Altera-FPGAs

Ich habe einen max10 mit eingebautem Nios-Prozessor, meine Speicherauslastung auf dem Teil ist: 414.198 / 562.176 ( 74 % ), aber ich habe jeden M9K-Block auf dem FPGA verbraucht. Hier ist eine Tabelle für die Auslastung

Geben Sie hier die Bildbeschreibung ein

Wie Sie sehen können, werden viele der M9K-Blöcke für einen kleinen Puffer auf einigen der nios II-Komponenten verwendet. Meine Frage ist: Gibt es eine Möglichkeit, jeden M9K-Block besser auszulasten? Es wäre schön, wenn ich sie irgendwie kombinieren könnte, und es scheint ein wenig lächerlich, dass ich einen ganzen Block für 256 Byte Speicher verwenden würde.

Nein, sie können nicht kombiniert werden, es sei denn, sie befinden sich in derselben Adresszuordnung. Es gibt nur zwei Ports (mit jeweils nur einer Adresse), sodass Sie sie nicht zusammenführen können.
Es ist auch nicht lächerlich, einen großen Block nicht auszulasten. Denken Sie an die Alternative - Ihr 256-Byte-Speicher würde 2048 Register plus Nachschlagetabellen verbrauchen, was eine riesige Menge an Ressourcen darstellt. Sie sollten bei Ihrem Design eher daran denken, wie viele Blöcke Sie benötigen, als Bits.

Antworten (1)

Die einfache Antwort ist vielleicht, aber wahrscheinlich nicht. Es hängt wirklich davon ab, was den Speicher verwendet.

Es ist wichtig, die Struktur des Gedächtnisses zu berücksichtigen. Die M9K-Speichermodule sind echte Dual-Port-Module. Das bedeutet, dass sie über zwei unabhängige Schreib-/Leseports verfügen. Jeder dieser Ports hat einen Adressbus, einen Lesedatenbus und einen Schreibdatenbus. Das bedeutet, dass jeder Speicher entweder zwei unabhängige Single-Port-Speicher oder einen Dual-Port-Speicher hosten kann.

Um zwei zu hosten, ist jeder nicht größer als die Hälfte des M9K, und aufgrund der Tatsache, dass Sie das MSB an einem der Ports auf 1 und auf dem anderen auf 0 binden können, können Sie immer einen Port haben greift auf die obere Hälfte zu und der andere Port greift immer auf die untere Hälfte zu, und somit haben Sie zwei unabhängige Speicher (sie können sogar unterschiedliche Takte haben, da die Ports unabhängige Takteingänge haben).

Allerdings sind alle bis auf zwei Ihrer Speicher Dual-Port, was bedeutet, dass jeder in separaten M9Ks gehostet werden muss, da jeder eine unabhängige Kontrolle über beide Ports benötigt, sodass es keine Möglichkeit gibt, sie gemeinsam zu nutzen. Das Ergebnis ist, dass Sie den von diesen Blöcken verwendeten Speicher bei Bedarf kostenlos erhöhen können (bis zur Größe des M9K).

Das Schlüsselwort im obigen Absatz ist "unabhängig". Es gibt eine Ausnahme: Wenn jeder Speicher genau die gleichen Daten, Adressen und Steuersignale verwendet, wäre es möglich, sie auf den gleichen M9K abzubilden, solange Platz vorhanden ist. Dies wäre jedoch eine Optimierung, die Sie manuell vornehmen müssten, und es ist höchst unwahrscheinlich, dass sie möglich ist. Normalerweise stammen diese kleinen Erinnerungen von Dingen wie Pipeline-Stufen, die jeweils unabhängig gesteuert werden müssen.


Was sind die Möglichkeiten? Nun, zunächst akzeptieren Sie, dass es selbstverständlich ist. Jedes FPGA hat eine endliche Anzahl von "Blöcken" und Ihr Design erfordert eine bestimmte Anzahl von "Blöcken". Ob Sie jeden Block vollständig füllen oder nicht, ist irrelevant - dies ist einer der Hauptunterschiede zwischen dem FPGA-Design und dem ASIC-Design. Ressourcenverschwendung wird so ziemlich immer passieren, da dies die Strafe für so viel Konfigurierbarkeit ist.

Alternativ versuchen Sie herauszufinden, was genau den Speicher verwendet, und sehen, ob es möglich ist, anderen Speicher wie MLABs oder LCs zu verwenden. Dies sind verteilte Speicherressourcen, die eine viel geringere Kapazität für den Bereich haben - sie eignen sich gut für sehr kleine RAMs wie die 64-Byte-RAMs, die Sie beispielsweise haben. Sie haben jedoch unterschiedliche Fähigkeiten, und es kann sein, dass die hergeleiteten RAMs die Pipelining- und Latenz- oder Portkonfiguration erfordern, die in MLABs nicht unterstützt wird. In diesem Fall siehe den obigen Absatz.