mikrocontroller.net

Forum: FPGA, VHDL & Co. kommunikation zwischen IP Cores


Autor: fresh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Charles Gardiner (Firma: Ingenieurbuero Gardiner) (cfgardiner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/16.... 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

Autor: fresh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: fresh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hans Anonym (fresh)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hans Anonym (fresh)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hans Anonym (fresh)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Charles Gardiner (Firma: Ingenieurbuero Gardiner) (cfgardiner)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hans Anonym (fresh)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.