mikrocontroller.net

Forum: FPGA, VHDL & Co. Bus vs NoC Unterschied


Autor: Hans Anonym (fresh)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Also ich wollte euch nur kurz fragen ob ich bei meiner Recherche zum 
Thema Bussysteme alles richtig verstanden habe.

Es gibt im Prinzip zwei möglichkeiten mehrere IP Core in einen SoC zu 
verbinden und zwar Buse und Network on Chip.

Buse sind zum Beispiel AMBA, Wishbone, CoreConnect, usw wobei die 
meisten davon nur das Interface spezifizieren und nicht die 
physikalische Übertragung oder? Eine weitere spezifikation is OCP welche 
ebenfalls ein definiertes Interface zur Verfügung stellt und der 
darunterliegende Bus ist erneut nicht definiert.

Bei NoC handelt es sich um kleine Netzwerke am Chip die mit 
verschiedenen Topologien (folded torus, CLICHE, SPIN, BFT, Octagon, usw) 
aufgebaut werden können. Dabei werden die Daten parallel übertragen weil 
genung Leitungen vorhanden sind. Diese sind gegenüber busen flexibler 
wenn änderungen vorgenommen werden. Ich habe aber bisher keine 
spezifikation zu NoCs gefunden und daher baut jeder HErsteller seine 
eigene Lösung oder?

Danke im Vorhinien für das Hinweisen auf Fehler und 
Verbesserungsvorschläge.

Mfg Harald

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Harald Schuster schrieb:
> Also ich wollte euch nur kurz fragen ob ich bei meiner Recherche zum
> Thema Bussysteme alles richtig verstanden habe.

Wird das ganze eine Studien-/Diplomarbeit?

> Es gibt im Prinzip zwei möglichkeiten mehrere IP Core in einen SoC zu
> verbinden und zwar Buse und Network on Chip.

Nicht falsch. Wobei die Übergänge fließend sind, und das was eine Uni
als Messlatte für die Bezeichnung "NoC" hält, nicht unbedingt mit dem
Gebrauch dieses Begriffs in der Praxis übereinstimmt.

Bus #1: req, gnt, stb, arbiter, handover, tri-state
Bus #2: req, gnt, stb, arbiter, multiplexer
Bus #3 (triviales NoC?): crossbar, point-to-point
Bus #4: registered paths, port-to-port routing, transactions, 
out-of-order
Bus #5: routing mesh

> Buse sind zum Beispiel AMBA, Wishbone, CoreConnect,

AMBA ist ein Standard der mehrere Protokolle definiert. Das gleiche
gilt meines Wissens auch für CoreConnect.

> usw wobei die meisten davon nur das Interface spezifizieren und
> nicht die physikalische Übertragung oder?

Ich würde das nicht so trennen. Natürlich wird das Interface auf
elektrische Signale abgebildet. Ob diese Signale dann direkt zum
Empfänger durchgeschaltet werden, oder zwischendurch gewandelt, ist
eine andere Sache.

> Eine weitere spezifikation is OCP welche ebenfalls ein definiertes
> Interface zur Verfügung stellt und der darunterliegende Bus ist
> erneut nicht definiert.

Ich habe mir OCP bisher nur oberflächlich angesehen, aber ich denke
die kochen auch nur mit Wasser. Das Interface ist eine p-t-p
Verbindung zu einem Protokollwandler. Das stellt sich mir erstmal
nicht anders dar als z.B. ein AMBA AHB Interface, das an einen Wandler
geht.

> Bei NoC handelt es sich um kleine Netzwerke am Chip die mit
> verschiedenen Topologien (folded torus, CLICHE, SPIN, BFT, Octagon, usw)
> aufgebaut werden können.

So lange es die jeweilige Prozesstechnologie hergibt, wird man
versuchen, auf die komplexen Topologien zu verzichten und direktes
routing zwischen Quelle und Ziel herzustellen. Alles andere kostet zu
viel Zeit (Latenz, nicht Bandbreite).

> Dabei werden die Daten parallel übertragen weil genung Leitungen
> vorhanden sind.

"vorhanden"? Ach so, auf einem FPGA. Man will ja auch nicht an jedem
Interface einen SerDes installieren.

> Ich habe aber bisher keine spezifikation zu NoCs gefunden und daher
> baut jeder HErsteller seine eigene Lösung oder?

Davon ist auszugehen.

--
Marcus

Autor: Hans Anonym (fresh)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Danke für die Antwort. Die Recherche ist für eine Seminararbeit. Also 
das dieser Übergang zwischen Busen und NoC nicht klar definiert ist ist 
mir auch schon aufgefallen. Ich habe dazu mal gelesen das shared bus, 
single crossbar Switch und Point-to-Point architecture kein NoC sind 
aber komplexerer topologien schon. Daher wäre doch ein wishbone bus mir 
crossbar switch topology noch kein NoC sondern ein Bus. Ich habe auch 
gelesen das man bei SoCs oft einen kompletten Layer für Verbindungen hat 
und daher zwischen den einzelnen Switches in einen NoC zb 64 Bit 
Datenleitungen parallel hat oder ist das komplet falsch?!

Das AMBA und CoreConnect drei unterschiedliche Buse definieren ist mir 
klar aber ich dachte eigentlich das sie eben das Interface definieren 
aber nicht wie die elektrischen Signale dann wirklich übertragen werden.

Bzüglich OCP habe ich das so verstanden das du am IP Core ein OCP 
interface hast zum Beispiel einen Master und der kommuniziert mit einen 
OCP Slave welche als Bus wrapper dient. Darunter kann aber ein 
beliebiger Bus also auch AMBA sitzen.

Nachdem nun eigentlich jeder Hersteller dann die Idee eines NoC 
unterschiedlich umsetzt ist das ja nicht wirklich förderlich für Core 
reuse von fremden Cores.

Wiedermal danke im vorhinein für alle Antworten.

Mfg Harald

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Harald Schuster schrieb:
> Ich habe auch gelesen das man bei SoCs oft einen kompletten Layer
> für Verbindungen hat und daher zwischen den einzelnen Switches in
> einen NoC zb 64 Bit Datenleitungen parallel hat oder ist das komplet
> falsch?!

Das mit dem kompletten Layer kann ich nicht beurteilen, kommt
sicherlich auf die ASIC Technologie an. Die 64 Datenleitungen sind
heutzutage eigentlich Standard, sowie (typisch) 32 Adressleitungen,
Kontrollsignale, Handshaking und Sidebandsignale. Wird schon etwas
kuschelig, wenn ich damit einen Crossbar aufbauen wollte.

Daher sind einige Hersteller (z.B. Arteris) dazu übergegangen ein
internes, pakteorientiertes Routingprotokoll zu verwenden. Die vom
Interface kommende Information wird z.B. in einen Bytestrom gewandelt
und über eine Anzahl von Byte Lanes zum Exit-Port geschickt. Dort wird
es wieder in ein Interfaceprotokoll gewandelt. Vorteil: man hat
schlankere Verbindungen, und erreicht dank einfacherem Timing
möglicherweise sogar höhere Taktfrequenzen. Dafür steigt die Latenz
und die Bandbreite ist bei gleicher Frequenz geringer.

> aber ich dachte eigentlich das sie eben das Interface definieren
> aber nicht wie die elektrischen Signale dann wirklich übertragen
> werden.

Wie gesagt, ich weiß nicht wie man das konzeptionell trennen soll. Wie
sollen denn Interface-Signale übertragen werden, wenn nicht
elektrisch? Natürlich werden diese Signale bis zu einem gewissen Punkt
genauso übertragen wie es das Protokoll definiert. Dahinter
möglicherweise nicht mehr.

> Bzüglich OCP habe ich das so verstanden das du am IP Core ein OCP
> interface hast zum Beispiel einen Master und der kommuniziert mit einen
> OCP Slave welche als Bus wrapper dient. Darunter kann aber ein
> beliebiger Bus also auch AMBA sitzen.

Was ich an OCP nicht verstehe ist der (angebliche) Unterschied in
dieser Hinsicht zu anderen Protokollen. Es gibt genau so die
Konstellation AXI/AHB/APB->AXI->AXI/AHB/APB. Hab' im Moment leider
keine Zeit mich näher mit OCP zu beschäftigen.

> Nachdem nun eigentlich jeder Hersteller dann die Idee eines NoC
> unterschiedlich umsetzt ist das ja nicht wirklich förderlich für Core
> reuse von fremden Cores.

Wieso? Genau dafür hat man doch die Interfaces. Wie das intern
geroutet wird ist doch zunächst vollkommen egal.

Als Dank bekomme ich eine Kopie der Arbeit, oder :-)

Gruß
Marcus

Autor: dito (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Harald Schuster:

Vielleicht hilft dir ja dieser Artikel weiter:

http://www.design-reuse.com/articles/10496/a-compa...

Den habe ich gefunden als ich nach etwas anderem gesucht habe und da 
viel mir deine Frage wieder ein.

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.