Fragen/Gedanken zum Hardwarekonzept des Hive
Verfasst: Fr 18. Sep 2009, 18:47
Vorab kurz ein zuerst per PN geführter Dialog mit Drohne235
meine Frage:
Die konkrete Ausführung der Adressierung / Ansteuerung der SRAMs, d.h. die gesamte Erzeugung aller Steuersignale für den SRAM ist die nach Mustern von Parallax oder sonst wem erfolgt, folgt sie bestimmten Notwendigkeiten der Software?
Ich hätte an dieser Stelle Vorschläge zur Erweiterung der Möglichkeiten insbesondere zur erheblichen Erweiterung der Anschlussmöglichkeiten externer Hardware aber würde erstmal gern wissen, welche Freiheitsgrade bestehen.
Antwort von Drohne235
der Anschluss der externen RAM's unterlag keinen Zwängen. Von Parallax ist da auch nichts vorgesehen. Die einzige Grenze war dabei die Hardware, da nicht genug I/O-Pins zur Verfügung standen, musste ich auf ein Adresslatch zurückgreifen. Auch von der Software besteht da keine Richtlinie, da der Propeller, bzw. die RISC-Kerne, von sich aus schlicht und ergreifend überhaupt nicht auf den externen RAM zugreifen können... Man muß also den Zugriff per Software selbst realisieren. In dem einfachen TriOS ist das in Spin realisiert - die Routinen sind im IOS zu finden. Ansonsten besteht noch die Möglichkeit das in PASM zu machen. Dabei kommt man aber schon schnell an die Grenze der Zugriffsgeschwindigkeit der momentan verwendeten RAM's (55 nsec Zugriffszeit <--> 50 nsec Befehlszykluszeit der Kerne).
Nun zu meiner Frage/Überlegung:
Wäre es nicht evtl. sinnvoll/wünschenswert die Ansteuerung des SRAM in einer Art vorzunehmen, ähnlich wie dies z.B. beim Z80 erfolgte, d.h. unter Erzeugung der üblichen Steuersignale /MREQ, /RD,/WR?
Es könnten Pins dafür gewonnen werden, wenn die Adressen anders gelatched würden. Dann könnte ebenfalls ein /IORQ-Signal erzeugt werden, was den Anschluss von 256 und mehr IO-Geräten z.B. auch über Standard-PIOs ermöglichen würde.
Konkret könnte ich mir vorstellen dass die Adressierung folgendermaßen abläuft:
Auf den Adressbuss werden A8 bis A15 gelegt sowie gleichzeitig auf den Datenbus A16 bis A19 (max. bis A23). Dann wird der Latch-Clock angelegt, dann können A0 bis A7 auf den Bus. Die Auswahl der Ram-Chips erfolgt über das höchste genutzte Adressbit. Die jetzigen Pins für A8 bis A10 würden frei.
/RAM1, /RAM2 sind /MREQ1 /MREQ2 (/CS1 bzw /CS2 der RAMs), von den freien Pins könnte eines als /IORQ, eines als /RD (=/OE der RAMs) genutzt werden.
Somit könnte ein großer IO-Raum erschlossen werden.
Wofür?: z.B für einen Drucker
Ich könnte mir unter anderem vorstellen, A/D-Wandler anzuschließen. Damit wäre es möglich ein Softwareoszilloskop zu realisieren und das Parallelprozessing unter anderem dafür zu nutzen, die Daten in Echtzeit zu verrechnen (z.B. indem auf einem Kern eine FFT-Routine läuft, die die Echtzeitdarstellung von Spektren erlaubt). Eine solche Anwendung belegt auch, warum IO-Operationen (auch) an Regnatix stattfinden können sollten.
Gruß Ingo (Drohne103 - Hive-Aufbau gerade begonnen, nach eindrucksvoller Präsentation durch Drohne235 in Wittenberg ).
meine Frage:
Die konkrete Ausführung der Adressierung / Ansteuerung der SRAMs, d.h. die gesamte Erzeugung aller Steuersignale für den SRAM ist die nach Mustern von Parallax oder sonst wem erfolgt, folgt sie bestimmten Notwendigkeiten der Software?
Ich hätte an dieser Stelle Vorschläge zur Erweiterung der Möglichkeiten insbesondere zur erheblichen Erweiterung der Anschlussmöglichkeiten externer Hardware aber würde erstmal gern wissen, welche Freiheitsgrade bestehen.
Antwort von Drohne235
der Anschluss der externen RAM's unterlag keinen Zwängen. Von Parallax ist da auch nichts vorgesehen. Die einzige Grenze war dabei die Hardware, da nicht genug I/O-Pins zur Verfügung standen, musste ich auf ein Adresslatch zurückgreifen. Auch von der Software besteht da keine Richtlinie, da der Propeller, bzw. die RISC-Kerne, von sich aus schlicht und ergreifend überhaupt nicht auf den externen RAM zugreifen können... Man muß also den Zugriff per Software selbst realisieren. In dem einfachen TriOS ist das in Spin realisiert - die Routinen sind im IOS zu finden. Ansonsten besteht noch die Möglichkeit das in PASM zu machen. Dabei kommt man aber schon schnell an die Grenze der Zugriffsgeschwindigkeit der momentan verwendeten RAM's (55 nsec Zugriffszeit <--> 50 nsec Befehlszykluszeit der Kerne).
Nun zu meiner Frage/Überlegung:
Wäre es nicht evtl. sinnvoll/wünschenswert die Ansteuerung des SRAM in einer Art vorzunehmen, ähnlich wie dies z.B. beim Z80 erfolgte, d.h. unter Erzeugung der üblichen Steuersignale /MREQ, /RD,/WR?
Es könnten Pins dafür gewonnen werden, wenn die Adressen anders gelatched würden. Dann könnte ebenfalls ein /IORQ-Signal erzeugt werden, was den Anschluss von 256 und mehr IO-Geräten z.B. auch über Standard-PIOs ermöglichen würde.
Konkret könnte ich mir vorstellen dass die Adressierung folgendermaßen abläuft:
Auf den Adressbuss werden A8 bis A15 gelegt sowie gleichzeitig auf den Datenbus A16 bis A19 (max. bis A23). Dann wird der Latch-Clock angelegt, dann können A0 bis A7 auf den Bus. Die Auswahl der Ram-Chips erfolgt über das höchste genutzte Adressbit. Die jetzigen Pins für A8 bis A10 würden frei.
/RAM1, /RAM2 sind /MREQ1 /MREQ2 (/CS1 bzw /CS2 der RAMs), von den freien Pins könnte eines als /IORQ, eines als /RD (=/OE der RAMs) genutzt werden.
Somit könnte ein großer IO-Raum erschlossen werden.
Wofür?: z.B für einen Drucker
Ich könnte mir unter anderem vorstellen, A/D-Wandler anzuschließen. Damit wäre es möglich ein Softwareoszilloskop zu realisieren und das Parallelprozessing unter anderem dafür zu nutzen, die Daten in Echtzeit zu verrechnen (z.B. indem auf einem Kern eine FFT-Routine läuft, die die Echtzeitdarstellung von Spektren erlaubt). Eine solche Anwendung belegt auch, warum IO-Operationen (auch) an Regnatix stattfinden können sollten.
Gruß Ingo (Drohne103 - Hive-Aufbau gerade begonnen, nach eindrucksvoller Präsentation durch Drohne235 in Wittenberg ).
).
) oder ein bestehendes, das völlig frei nutzbar ist.