Verbindung von 64Kx16-Bit-SRAM mit Qsys

Ich habe zwei 64Kx8-Bit-Speicherchips, die ich mit einem FPGA verbunden habe, das mit Qsys als ein einziger 64Kx16-Block konfiguriert ist. Ich habe einen generischen Tri-State-Controller als Schnittstelle verwendet, wobei sowohl die Adressbreite als auch die Datenbreite auf 16 eingestellt sind:

Geben Sie hier die Bildbeschreibung ein

Leider führt dies nicht zu dem gewünschten Ergebnis (das heißt, einen einzelnen 128-KB-RAM-Block mit 16-Bit-Zugriff zu haben). Mein Controller belegt nur 64 KB Adressraum. Es sieht so aus, als würde Qsys meinen SRAM als 32Kx16-Block mit 16-Bit-Adressbus behandeln, der die Adressierung einzelner Bytes ermöglicht.

Gibt es eine Möglichkeit, meinen Controller so zu konfigurieren, dass die gesamten 128 KB Speicher zugänglich sind? Hier ist ein Diagramm der Verbindungen zwischen den Chips:

schematisch

Simulieren Sie diese Schaltung – Mit CircuitLab erstellter Schaltplan

Um sicher zu sein - Chips sind SRAM (24512-15), nicht DRAM und nicht SDRAM? Warum dann nicht einfach einen sehr einfachen Speichercontroller entwerfen, der die Adresse setzt, die erforderliche Anzahl von Zyklen wartet und Daten liest (oder Daten schreibt)?
@Anonymous, aber das liefert keine Antwort, das versucht, die Frage neu zu definieren :-)
@ TonyM absolut richtig, manchmal ist es besser, die Vorgehensweise / Strategie / Architektur so zu ändern, dass schwierige Fragen einfach nicht auftauchen. Warum gegen die Wand schlagen, wenn es genauso einfach ist, Dinge etwas anders zu machen? :)
@Anonymous Ja, schlicht und einfach SRAM. Dieser "generische Tri-State-Controller" soll genau das tun, was Sie beschreiben. Ich weiß, dass ich selbst einen entwerfen könnte, aber das würde mehr als 5 Minuten dauern, die die Verwendung dieses Assistenten dauern würde.
Dmitry, Sie haben bereits mehr als 5 Minuten damit verbracht :) Die allgemeine Anwendbarkeit dieses Moduls wird durch die Art und Weise definiert, wie Sie Chips physisch mit FPGA verbinden. Bitte Schaltplan beifügen.
Entschuldigung @Anonymous, ich war mit dem Kommentieren unten beschäftigt. Richtig, aber bedenken Sie das Gewicht Ihrer Vorschläge, wie unten beschrieben. Verlassen wir das Schiff nicht beim ersten Anblick von Schwierigkeiten :-)
@Anonymous Das ist eine Lernkurve, die ich bereit bin zu akzeptieren, damit ich nicht immer wieder trivialen Verilog-Code schreiben muss, wenn ich einen Speicherblock an mein System anhängen muss.
Welche Art von Zugriff wünschen Sie? Ein Zugriff auf Byteebene ist nicht möglich, da es keine Bytefreigaben gibt (wenn Sie beide CS2-Pins separat mit dem FPGA verbunden hätten, könnten diese Ihre Bytefreigabe bilden). Aber Sie sollten über die 16-Bit-Schnittstelle Zugriff auf die gesamte 64k-Karte haben - Sie müssen nur sicherstellen, dass alle Ihre Zugriffe immer 16-Bit sind, um Datenverluste zu vermeiden.
Oh, duh. Sie sollten die Adressbreite auf 17 Bit einstellen und das LSB nicht verwenden. Die Adressen auf dem Tri-State-Controller sind immer Byteadressen, keine Wortadressen. Solange Sie immer beide Bytes gleichzeitig schreiben und immer auf gerade Adressen schreiben, ist es sicher, das LSB zu verwerfen.
(ps, das duh war auf mich selbst gerichtet, ich erinnerte mich plötzlich an die Adressierungsmodi, als ich einen anderen Kommentar eintippte).
@TomCarpenter Diese Idee kam mir irgendwann in den Sinn, aber es sah aus wie eine schmutzige Problemumgehung. Sagen Sie, wenn ich die Bridge wie von Ihnen vorgeschlagen verwende, wird sie Einzelbyte-Zugriffe für mich handhaben? Oder wird es einfach das LSb fallen lassen? (Ich brauche in diesem Projekt keinen Byte-Zugriff, aber ich brauche ihn vielleicht in zukünftigen Projekten)
@DmitryGrigoryev So wie Sie Ihren RAM angeschlossen haben, ist ein Einzelbytezugriff nicht möglich (Sie müssten manuelles Lesen, Ändern und Schreiben durchführen). Das Avalon-MM-Fabric, das zwischen der Pipeline-Brücke und dem Speicher hinzugefügt wird, wandelt das LSB in ein Byte-Enable-Signal um. Wenn Sie also in Zukunft Byte-Enable-Signale zu Ihren Speicher-ICs hinzufügen, müssen Sie nichts neu kompilieren .
@TomCarpenter Also, Read-Modify-Write ist nichts, was eine Avalon-Brücke alleine herausziehen könnte? Nicht, dass ich überrascht wäre, es ist nur lustig, dass ein ganzer IP-Core da sein wird, um im Wesentlichen ein LSb für mich fallen zu lassen.
@DmitryGrigoryev Leider musst du RMW selbst machen. Qsys-Systeme haben am Ende ziemlich viele zufällige IP-Kerne, die so ziemlich nichts anderes tun, als Signale neu anzuordnen. Es ist der Preis, den Sie für grafische Schnittstellen zahlen. Das riesige System, das ich im Laufe der Jahre entwickelt habe, hat so ziemlich 1000 IP-Core-Instanzen, von denen wahrscheinlich 50-75 % rein benutzerdefinierte Pass-Through-Cores sind, die nur dazu dienen, Qsys dazu zu bringen, die Dinge richtig zu verbinden.

Antworten (2)

Das Problem ist, wie Qsys Adressen behandelt. Es gibt zwei Möglichkeiten, wie eine Avalon-MM-Schnittstelle ihre Adresse darstellen kann – als „Symboladresse“ und als „Wortadresse“.

Für Slaves, die mit einer Adresseinheit von SYMBOLS definiert sind, repräsentiert das LSB ein Symbol (auch bekannt als die Breite einer Einheit im Datenbus, zB ein Byte). Für eine Adresse, die in Einheiten von WORDS definiert ist , repräsentiert das LSB ein Wort (auch bekannt als die Breite des Datenbusses). Im Fall des generischen Tristate-Controllers ist seine Avalon-MM-Schnittstelle in Form von Symbolen definiert, wie im folgenden Screenshot angegeben:

Adresseinheiten

Das bedeutet, dass das LSB ein einzelnes 8-Bit-Symbol darstellt. Sie haben 128.000 Speichersymbole, was bedeutet, dass Sie eine 17-Bit-Adresse und keine 16-Bit-Adresse angeben müssen. Das zusätzliche Bit ist darauf zurückzuführen, dass Sie zwei Symbole pro Wort haben.

Um sich mit Ihrem Speicher zu verbinden, ignorieren Sie dann einfach das LSB. Das einzige, worauf Sie dabei achten müssen, ist, dass Sie immer auf die richtige Adresse zugreifen (mit LSB auf Null gebunden) und immer 16-Bit-Datenzugriffe durchführen, indem Sie sicherstellen, dass beide Byte-Enable-Bits hoch sind.

Wenn Sie die Adresseinheiten in WORDS umwandeln möchten , ist der einfachste Weg, eine Avalon-MM Pipeline Bridge einzufügen. Stellen Sie die folgenden Parameter ein:

  • Datenbreite auf 16
  • Symbolbreite auf 8
  • Adresseinheiten zu WORTEN
  • Aktivieren Sie das Kontrollkästchen "Automatisch ermittelte Adressbreite verwenden".
  • Deaktivieren Sie sowohl "Pipeline-Befehlssignale" als auch "Pipeline-Antwortsignale".

Sie sollten feststellen, dass eine Wortadressenbreite von 16 Bit berechnet wird. Alle Zugriffe auf den Slave der Pipeline-Brücke erfolgen nun in Form von Wortadressen, was bedeutet, dass er einen 16-Bit-Adressbus haben wird. Durch Deaktivieren der „Pipeline“-Kästchen enthält der resultierende IP-Kern überhaupt keine Logik – er wird einfach alle Signale direkt durchleiten.

Qsys fügt automatisch Avalon-MM-Fabric-Komponenten ein, um den wortadressierten Master der Pipeline-Brücke dem symboladressierten Slave des generischen Tristate-Controllers zuzuordnen, und übernimmt für Sie die Übersetzung der 16-Bit-Wortadresse in eine 17-Bit-Symboladresse.

Falls Sie sich fragen, ich weiß, dass dies funktioniert, weil ich bei einem der von mir verwendeten Entwicklungskits auf dasselbe Problem mit einem CFI-Gerät gestoßen bin, bei dem es sich um zwei separate ICs handelte, die parallel miteinander verbunden waren - obwohl es in diesem Fall zwei 16-Bit-ICs waren Bilden eines 32-Bit-Busses, und ich brauchte Zugriff auf Byte-Ebene, damit die Verbindungen etwas kniffliger wurden.

Ausgezeichnete und endgültige Antwort, positiv bewertet. Warum in aller Welt konnten sie nicht das allgemein akzeptierte Wort „Byte“ anstelle von „Symbol“ verwenden?
@TonyM Da ein Symbol nicht unbedingt ein Byte ist, kann es eine beliebige Breite haben. Ein Wort ist die Breite des Datenbusses, daher können Wort und Symbol auch gleich breit sein.
Ah, ich habe das falsche Ende des Sticks erwischt :-) Danke, Tom.
Hallo Tom, ich habe es zum Laufen gebracht, indem ich dem Tri-State-Controller eine 17-Bit-Adresse zugewiesen und das LSb ignoriert habe. Interessanterweise hatte das Einfügen einer Brücke zwischen dem Controller und der CPU, um Wörter in Symbole umzuwandeln, keine Wirkung: Egal, wie ich die Adresseinheiten und die Adressbreite konfiguriert habe , ich muss meinem Controller immer noch eine 17-Bit-Adresse für das RAM geben Prüfung zu bestehen. Also habe ich die Brücke komplett entfernt.
@DmitryGrigoryev Angenommen, Sie verwenden Nios, sind alle Adressen immer Byte-Adressen in Nios, unabhängig von der Schnittstelle (es führt die Konvertierung intern durch).
Ja, das tue ich, und ja, das verstehe ich. Ich hatte erwartet, dass die Bridge eine 17-Bit-Adresse auf der Nios-Seite in eine 16-Bit-Adresse auf der Tri-State-Controller-Seite übersetzt. Das ist nicht passiert; Ich musste den Controller noch so konfigurieren, dass er eine 17-Bit-Adresse hat, damit er richtig funktioniert, also hat die Bridge überhaupt nichts gemacht. Nebenbei bemerkt, ich scheine eine andere Version von Quartus zu verwenden (13.0, die letzte mit Cyclone II-Unterstützung), vielleicht ist das der Grund, warum ich nicht die gleichen Ergebnisse erhalte wie Sie.

Ich habe diese IP nicht verwendet, aber was ich auf dem Bild sehe:

  • Adressbreite: 16 Bit, das heißt, es gibt 65536 Worte Datenbreite ;
  • Datenbreite: 16 Bit, also 2 Byte;
  • Bytes pro Wort: 2, was 16/2 = 8 ist, scheint der richtige Wert zu sein;
  • Byte-Aktivierungsbreite: 2, d. h. 2 Drähte, die die Aktion auf Hi-Low-Bytes mit einer Datenbreite von 16 Bit deaktivieren/aktivieren (jedoch ist die Byte-Aktivierung deaktiviert = die Steuerung liest/schreibt den gesamten 16-Bit-Datenbus, kein Teilzugriff).

Der Controller sieht 65536 Wörter mal 16 Bytes, also 128 Kilobyte, und geht davon aus, dass er auf 16 Bits gleichzeitig zugreifen kann, ohne das jeweilige Byte im Wort maskieren zu können.

Wie hast du SRAM-Chips angeschlossen? Gerade zwei Chips mit Adressleitungen und CE/OE parallel geschaltet?

So:

Mein Controller belegt nur 64 KB Adressraum

Richtig.

und ein nicht ausgerichteter Zugriff auf diesen RAM schlägt fehl

Der Controller sieht 16-Bit-Daten und kann nur in 16-Bit-Wörtern lesen/schreiben. Um ein Byte daraus zu bekommen, müssen Sie das niedrigste Bit der 17-Bit-Adresse (wobei sich die höchste 16-Bit-Adresse auf den Leitungen A0-A15 befindet) prüfen und den jeweiligen Chip (mithilfe seines CE) für den Betrieb aktivieren und dann die Daten von / nach multiplexen jeweiligen Datengruppe (A0-A7 oder A8-A15). Aber wenn Sie CEs miteinander verbunden haben, können Sie nicht separat auf Chips zugreifen.

CEs sollten als 17. Bit der Adresse fungieren. Was ich oben erklärt habe, ist nur eine der Möglichkeiten, wie es implementiert werden kann. Sie müssen Ihre Schaltung überarbeiten, und wie ich im Kommentar zu Ihrer Frage sagte, wäre es viel einfacher und effektiver, einen eigenen Controller zu entwerfen (und dieser Controller ist möglicherweise vorhersehbarer).

Update nach Schaltplanergänzung:

In dieser Konfiguration sind ganze 128 Kilobyte adressierbar, allerdings nur in 16-Bit-Worten. Sie können RAM nicht in einzelnen 8-Bit-Wörtern (Bytes) adressieren.

Was Sie jedoch damit tun können: Sie können die Byte-Aktivierung aktivieren und die Chipauswahl an Byte-Aktivierungssignale anhängen. Wie auch immer, Sie müssen Daten von D7-D0 oder D15-D8 in 8-Bit-Register im FPGA multiplexen.

Es ist nur einfacher, wenn das OP die Erfahrung und das Vertrauen hat, einen Controller zu definieren, und es ist nur effektiv, wenn es die Zeit und die Mittel hat, es zu entwerfen, zu entwickeln, zu testen, zu beweisen und zu dokumentieren. Letzteres richtig zu machen, ist mindestens ein paar Tage Arbeit, vielleicht eine Woche. Wie ist das einfacher und effektiver als das Abrufen von IP, das eine Stunde dauern sollte? Dieses OP hat Probleme, aber viele Leute werden es so schnell benutzt haben. Kannst du mir das erklären? :-)
@TonyM sicher hast du recht, deshalb sind diese Bausteine ​​drin. Die Verbindungsschaltung definiert die genaue Antwort. Wie ist die Adresse verbunden, CE, OE?
Richtig und der Rest der Sachen, die Sie beantworten, ist gute Sachen.
Ich könnte ein 17-tes Bit der Adresse hinzufügen, aber das klingt nach einer schmutzigen Problemumgehung, da ich nicht auf einzelne Bytes zugreifen möchte (und in meiner Konfiguration ist es sowieso unmöglich).
Siehe Update zur Antwort. Was meinen Sie dann, wenn Sie in Frage sagen, dass "nicht ausgerichteter Zugriff auf diesen RAM fehlschlägt"? Sie möchten, dass der Zugriff auf was ausgerichtet ist? Sie haben 65536 Wörter mit einer Breite von 16 Bit.
Kann es helfen, "byteenable width" auf 1 zu setzen?
@Anonym Danke für den Vorschlag. Leider bedeutet das Hinzufügen von bytefähigen Signalen, dass ich meine Platine modifizieren muss. Vergessen Sie den nicht ausgerichteten Zugriff, es funktioniert tatsächlich gut. Ich sehe nur die Hälfte des gewünschten RAM.
@Anonymous Das Setzen von byteenable width auf 1 führt zu Error: sram_controller_0.tdt.avalon_universal_slave_0: byteenable[1] width must be 2 (data width/8).
Okay, danke für den Versuch. Fassen wir also zusammen: Ihre RAM-Hardware ist rein 65536 x 16 (externe Konfiguration), aber Sie können nur auf die Hälfte zugreifen. Es könnte entweder 32768 x 16 sein, wie Sie in Frage sagten, oder 65536 x 8. Kann es vorkommen, dass Sie diesen Controller fälschlicherweise an andere Interna innerhalb des FPGA anschließen? (z. B. ist der Datenbus intern als 8 Bit organisiert, oder es wird angenommen, dass der Datenbus 15 Bit und nicht 16 Bit hat)?
Ich bezweifle sehr, dass ich etwas falsch verbinden könnte: Der Assistent generiert eine Komponente, die diese A OE WEund DQSignale enthält, die ich direkt an Pins exportiere. Ich bin mir ziemlich sicher, dass ich hier ein Kontrollkästchen übersehen oder den falschen Controller verwendet habe.
Nein, nicht die Signale, die in die SRAM-Richtung schauen. Ich meine die andere Seite dieser Avalon Tri-State Conduit- Schaltung, die "in" das FPGA hineinschaut.
Verbindung von 64Kx16-Bit-SRAM mit Qsys
AntwortenHierDatenschutz-Bestimmungen1y, 0v