Hi Habe vor kurzen einen Bericht über Open Core Protocol (OCP) gelesen mit den man den man IP Cores ausstatten kann und dann unabhängig vom verwendenten Bussystem kommunizieren kann. Nun würde es mich interessieren ob es zu OCP noch weiter alternativen gibt die den Physical Layer abstrahieren?!?! Danke im vorhinein für alle Antworten. Mfg fresh
Hi Fresh, ja es hat mal (vor 15 Jahren oder so) eine OCP-IP Spezifikation von der Virtual Socket Alliance (http://www.vsi.org) gegeben. In meinem früheren Siemens Leben haben wir uns eine Weile damit beschäftigt. Es war aber damals immer schon m.E. etwas akademisch und elitär. d.h. die grosse Firmen haben Vertreter hingeschickt, die schöne Vorträge gehalten haben, sich einen gemütlichen Abend gemacht haben usw.. Es ist aber nichts wirklich handfestes daraus geworden. Im Prinzip waren drei Ausprägung definiert (je nach gewünschte Komplexität bzw. Bandbreite), Peripheral, Basic und Advanced Irgendwann hat dann Sonics Inc. (deren Vertreter waren zufällig auch dabei) einen GUI Tool auf Grundlage der letzten Spezifikation entwickelt. Offiziell pflegt die Fa. Sonics die Spec noch. Eine Lizenz ist aber meines Wissens schweine teuer. (fünfstellig EUR). So viel ich weiss, zählen Nokia, TI und einige andere zu den Lizenznehmern. In der Praxis leisten z.B. Amba von ARM (http://www.amba.com) mit der Kombination APB/AHB/AXI bzw. CoreConnect von IBM mit der Kombination PLB/OPB m.E. so ziemlich das gleiche. Zumindest bei Amba sind die Specs kostenlos (ausser Hinterlegung der Email-Adresse/Firmen-Name). Ich glaube die CoreConnect Specs bekommt man von PowerOrg oder Xilinx (oder natürlich auch IBM). Hier gibt es halt meistens nur firmeneigene GUI Tools zur Verdrahtung. Mentor hat schon ein Tool im Program (mir fällt der Name gerade nicht ein) aber der ist auch ziemlich teuer. IP-XACT / IEEE 1685 (vormals Spirit Consortium) versuchen eine generische Lösung auf XML Basis zu etablieren. IP-XACT wird auch mehr oder minder von ARM, NXP et al. unterstützt. So viel ich weiss, gibt es zumindest experimentelle Beispiele, wie eine IP-XACT XML Beschreibung per XSLT in VHDL/Verilog umgesetzt werden kann. Bin aber noch nicht dazugekommen sie auszuprobieren. Die IP-XACT Spec gibt es unter http://standards.ieee.org/getieee/1685/download/1685-2009.pdf. S. a. die Accellera Webseite (http://www.accellera.org) Eine Rolle spielt auch der Wishbone Bus (z.B. bei OpenCores http://www.opencores.org oder Lattice Mico32 http://www.latticesemi.com) aber fast ausschliesslich in der FPGA Welt. Der Avalon Bus von Altera natürlich ebenso. Hoffe geholfen zu haben, Charles
Hi Charles Danke für deine hilfreiche Antwort. Wusste gar nicht das OCP so alt und ungebräuchlich ist. Habe es damals auch vorallem bei TI gefunden und die verwenden es anscheinend sehr gerne. Bezüglich der Lizenzkosten habe ich bisher leider noch nichts gefunden. Mfg fresh
Hallo Charles Nachdem du ja anscheinend viel mit solchen Systemen arbeitest hätte ich da noch eine kleine Frage an dich. OCP ist ja nur eine spezifikation wie die Schnittstellen aussehen müssen aber wie die Daten physikalisch übertragen werden ist nicht definiert. Daher meine Frage ob auch die anderen Vertreter wie AMBA nur eine Spezifikation sind und das Übertragungsmedium wieder frei Wählbar ist? Mfg fresh
fresh schrieb: > Daher meine Frage ob auch die anderen Vertreter wie AMBA nur eine > Spezifikation sind und das Übertragungsmedium wieder frei Wählbar > ist? AMBA definiert physikalische Signale. -- Marcus
Das heist also AMBA definiert den physikalischen Layer und die Schnittstelle zum Program hin. Also ich kann AMBA direkt verwenden um zwischen IP Cores zu kommunizieren aber ich kann auch OCP verwenden und darunter AMBA oder? Mfg fresh
Harald Schuster schrieb: > Also ich kann AMBA direkt verwenden um zwischen IP Cores zu kommunizieren Ja. > aber ich kann auch OCP verwenden und darunter AMBA oder? So entnehme ich es den Werbebroschüren der OCP-IP. Mehr weiß ich darüber aber nicht. -- Marcus
also wenn ich nun bei ein System on Chip ein Network on Chip brauch kann ich direkt AMBA verwenden oder ist das wieder was anderes? Mfg fresh
Harald Schuster schrieb: > also wenn ich nun bei ein System on Chip ein Network on Chip brauch kann > ich direkt AMBA verwenden oder ist das wieder was anderes? NoC ist lediglich ein griffiger Name für eine komplexe Busmatrix. Üblicherweise werden diese mit einer Software (z.B. AMBA Designer) konfiguriert und stellen so die zentrale Infrastruktur eines SoC dar. -- Marcus
So wie ich das bis jetzt verstanden habe sind AMBA, OCP, usw alles Bussysteme die gewisse beschränkungen haben. Sie sind aber keine Networks on Chip weil diese komplexer sind von der Struktur oder? Mfg fresh
Harald Schuster schrieb: > So wie ich das bis jetzt verstanden habe sind AMBA, OCP, usw alles > Bussysteme die gewisse beschränkungen haben. Jedes Bussystem ist logischerweise beschränkt, da man nicht alle möglichen zukünftigen Entwicklungen voraussehen kann. Selbst wenn man das könnte, wäre es nicht möglich, bzw. sinnvoll, alle diese Fälle mit einem einzigen Protokoll abzudecken. Daher gibt es die Protokollfamilien, wie z.B. AMBA, die verschiedene Protokolle für unterschiedliche Anwendungsfälle definieren. > Sie sind aber keine Networks on Chip weil diese komplexer sind von der > Struktur oder? Was Du möglicherweise meinst sind althergebrachte Busse (mehrere Treiber) gegenüber der Verwendung einer Busmatrix (Switched Interconnect). Ersteres verwendet seit über zehn Jahren keiner mehr, und letzteres nennt man eben immer noch "Bus", obwohl die Bezeichnung nicht so recht passt. Eine Busmatrix, im Wesentlichen aus Adressdekoder und Crossbar bestehend, ist heutzutage Standard und mehr oder weniger dumm. Wenn man, in modernen SoC, an die Eingangs und Ausgangsports der Matrix immer mehr Adapter (Frequenz, Datenbreite, Protokoll, usw.) anflanschen muss, dann wird das schnell unübersichtlich. Dazu kommen transaktionsbasierte Protokolle, wie AXI4, Routingregeln, und QoS. Jetzt empfiehlt es sich, mal ein NoC anzusehen. Das NoC stellt die Infrastruktur dar, an deren Ports die Busprotokolle der Teilnehmer implementiert werden. Dabei müssen nicht alle Teilnehmer das selbe Protokoll sprechen. Das NoC übernimmt das Routing von einem Port zum anderen. Intern wird z.T. ein spezielles, von außen nicht sichtbares, Protokoll verwendet. Manchmal aber auch nicht (siehe CoreLink NIC-301). Im Gegensatz zur Busmatrix ist ein NoC eine komplexe Logikeinheit. Wann genau man noch von einer Busmatrix spricht, und wann man das Ding dann NoC nennt, das wird letztlich von den Marketingabteilungen bestimmt. -- Marcus
Hallo Fresh,
ich bin nicht ganz Deiner Meinung, dass die physikalische
Datenübertragung bei OCP-IP nicht definiert ist. Die Spec hat sehr wohl
Kapitel zu den Themen "Signals and Encoding", "Protocol Semantics",
"Timing Diagrams", "Timing Specification" usw. Darüberhinaus gibt es
Kapitel, die das Format der Synthese Constraints, das Anbinden von nicht
OCP-IP Moduln usw. spezifiziert. Das Verkaufsargument von Sonics Inc.
ist aber das GUI Tool, das sie auch zur Verfügung stellen. So ist mir
jedenfalls vor ein Paar Jahren auf einer Messe vorgeführt worden. Dass
es bei TI, Nokia etc. in die Landschaft passt, kann ich mir auch gut
vorstellen. Durch die eigene Fabs bzw. enge Beziehung zu Ihren
ASIC/Full-Custom Providern wird das Sonics Tool wahrscheinlich in deren
gesamt Tool-Flow voll integriert sein.
Amba, CoreConnect usw. konzentrieren sich auf der Spezifikation der
"Signals and Encoding" und "Protocol Semantics". Das Timing ist
eigentlich impliziert, da die Busse synchron sind. Synthese muss halt
die Ziel-Frequenz erreichen. Zumindest bei Amba, wird das Interconnect
('Fabric') nicht zwingend spezifiziert auch wenn es durchaus
Empfehlungen gibt. Das darf der Anwender nach seinen Bedürfnissen selber
erfinden. AXI ist dem OCP-IP sehr ähnlich und als punkt-zu-punkt
beschrieben.
Nur, als die OCB (der Vorgänger nannte sich so) Spec noch von der VSI
gepflegt worden ist, waren die Erwartungen von vielen Beteilgten etwas
anders. Vor 15 Jahren hat so ziemlich jeder IP Provider seine eigene
Interfaces erfunden. Es war an Greuel sie alle miteinander zu verbinden.
Der Ansatz von VSI war eine Punkt-zu-Punkt Schnittstelle zu definieren,
die entweder als Punkt-zu-Punkt verwendet wird oder über Wrapper mit
Proprietären oder offene Bus Systeme. Bei Siemens damals haben wir
einige Cores mit OCB entwickelt and dann über Wrapper sowohl an Amba als
auch z.B. an den Infineon FPI Bus angeschlossen. Das Herz der IP-Cores
wurden aber eben nur einmal entwickelt und verifiziert. Es haben nur
wenige Firmen aber überhaupt IPs mit OCB angeboten. (Ich glaube Altera,
Virtual Chips und einige wenige andere waren dabei). Das Tempo der OCB
Standardisierung war aber extrem langsam. Mit der Preis/Lizenz/Patent
Politik von Sonics ist es aber m.E. für den breiten Einsatz endgültig
gestorben. Das sind Preise, die keine FPGA Anwender jemals zahlen
werden. Auch Firmen wie z.B. Evatronix, die vieles in den FPGA Markt
beliefern, haben einfach nicht das EDA Budget von Firmen wie Nokia oder
TI.
Als offener/erschwinglicher Standard mit Abstraktionsgedanken sehe ich
im Augenblick wirklich nur die IP-XACT Aktivitäten. Das angesprochene
Problem ist aber nicht genau das was ursprünglich von der VSI adressiert
worden ist. Grob skizziert, IP-XACT geht davon aus, dass man eine
IP-Sammlung hat, die alle dasselbe Interface haben (Amba, CoreConnect,
Proprietär..). Das Ziel ist eher die mühsame Verdrahtung des Top-Levels
zu automatisieren wo ein Leichsinnsfehler über Erfolg/Misserfolg
entscheiden kann. Seitdem die RDL (Register Description Language) Spec
dazugekommen ist, besteht eine Aussicht, dass das Anbinden von
Firmware/Device Treiber etc. an verschiedenen Projekten aus demselben
IP-Fundus vereinfacht werden kann.
Grüße,
Charles
Hi Also so wie ich das mit den OCP verstanden habe ist die Kommunikation zwischen einen OCP Slave und einen OCP Master definiert. Weil ein IP Core ist zum Beispiel ein OCP Slave dann muss er sich zuerst zu einen OCP Master verbinden der die Schnittstelle zum Eigentlichen Bus oder Netzwerk darstellt. Dann gehts zum OCP Slave des Empfängers welcher wiederrum mit den OCP Master des eigentlichen IP Cores kommuniziert. Also kann als echte Verbindung zwischend den OCP Schnittstellen jeder physikalische layer vorhanden sein. So habe ich das verstanden und hoffe das es stimmt. AMBA und Coreconnect definieren die Schnittstelle für die IP Cores und den physical Layer. Also diese Systeme wie AMBA und OCP haben eigentlich nichts mit Network on Chip zu tun weil ein NoC kann mit AMBA oder anderen physikalischen Layer realisiert werden. NoC bezeichnet eigentlich nur ein Bussystem mit logik oder? Sollte ich was falsch verstanden haben bitte ausbessern. DANKE Mfg fresh
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.