STMicroelectronics introduceert 'Spidergon' netwerk-on-chip

De EE Times bericht dat STMicroelectronics een nieuwe technologie heeft ontwikkeld om onderdelen binnen een chip met elkaar te laten communiceren. De technologie gaat door het leven onder de naam ‘Spidergon’ en is gericht voor het gebruik binnen ‘System-on-Chip’-ontworpen. Bij een SoC worden vele bouwblokken zoals processorcore’s, audio/video codecs, geheugen en IO-logica gecombineerd op één chip. Wanneer een chip uit slechts een beperkt aantal blokken wordt opgebouwd is de communicatie tussen de onderdelen geen groot probleem, maar bij tientallen of zelfs honderden bouwblokken is het communicatieprobleem minder makkelijk op te lossen.

Met STMicroelectronics’ Network-on-Chip wordt het probleem opgelost door alle blokken via een ringstructuur aan elkaar te koppelen. Tevens worden alle blokken direct verbonden met de overbuurman aan de andere kant van de ring. Hierdoor kan het routingalgoritme datapakketjes veelal via een kortere route naar de bestemming sturen. De gekozen topologie van het ‘Spidergon’ Network-on-Chip biedt hiermee een uitstekende combinatie tussen snelheid en complexiteit, aldus STMicroelectronics. Daarnaast maakt het netwerk het gemakkelijk een nieuwe chip te ontwerpen doordat de bouwblokken simpel met elkaar gecombineerd kunnen worden.

Reacties (25)

[RickN]

Mja, ringstructuur, ik denk dat we vanuit gewone ethernet netwerken wel weten dat dat niet de meest efficiente netwerken oplevert. Als je echt een design hebt met honderden componenten, krijg je dus tientallen hops voor je kiezen voor je bij je destination bent.

Philips heeft in de research groep waar ik werk ook network-on-chip technologie ontwikkeld. Deze technologie is meer analoog aan netwerken zoals we ze tegenwoordig zien, met routers. Het is al enige tijd productie rijp, maar het probleem waar men tegenaan loopt is dat huidige designs een beetje achterblijven bij de visie van SoCs met zeg 50+ componenten. In de praktijk kan men het nog af met een (multilayer) bus en dus gaan designteams liever voor die optie, want daar zijn ze bekent mee en dat brengt dus minder risico's met zich mee. Ik verwacht eigenlijk ook niet dat het aantal componenten in een SoC binnenkort explosief gaat stijgen.

Echter, netwerken als deze hebben ander voordelen die je bij een bus niet hebt. Zo is een netwerk veel voorspelbaarder. Je kunt een pad in het netwerk reserveren en zo een bepaalde throughput tussen componenten garanderen. Dit wordt in de toekomst belangrijk omdat veel applicaties realtime eisen hebben die op een multiprocessor systeem moeilijk te garanderen zijn als je afhankelijk bent van de primitieve arbiters in een bus.

[SED]

Was begrijpend lezen bij Philips ook een eigenschap die onderzocht werd?

Tevens worden alle blokken direct verboden met de overbuurman aan de andere kant van de ring. Hierdoor kan het routingalgoritme datapakketjes veelal via een kortere route naar de bestemming sturen

Let op het woord tevens

[Luxx]

de overbuurman zorgt voor een korte route, maar RickN heeft een goed punt door op te merken dat de route erg hard groter wordt als het aantal blokken hard groeit. Dan zal je meerdere/slimmere shortcuts moeten bedenken, of idd een ander ontwerp moeten nemen. Voor 'relatief weinig' componenten is dit echter wel een lekker eenvoudig en snelle oplossing.

[Punkie]

Maakt idd uit voor de performantie van deze specifieke chip maar lost het performantieprobleem niet op voor ring netwerken in het algemeen. Laat dat nu net zijn waar RickN het over heeft.

Die overbuurlink maakt trouwens dat de routing in het netwerk weer ingewikkelder met alle routing en performantie problemen vandien. Voor betere performantie zal een ander ontwerp , vb hyperkubussen, uitkomst moeten bieden.

[Ralph Smeets]

Mja, ringstructuur, ik denk dat we vanuit gewone ethernet netwerken wel weten dat dat niet de meest efficiente netwerken oplevert. Als je echt een design hebt met honderden componenten, krijg je dus tientallen hops voor je kiezen voor je bij je destination bent.

Als dit zo zou zijn, dan zouden backbones van grote netwerken niet als een ring uitgevoerd worden Dit is echter wel altijd het geval. Daarnaast klopt het niet wat je zegt. Ethernet is namelijk alleen maar efficienter als het netwerk niet zwaar belast wordt. Zo gauw de belasting zwaar wordt, is tokenring sneller. Dit is bij ethernet opgelost door het gebruik van routers en switches, die als je heel goed kijkt, een soort van ring-netwerk van het geheel maken. Tokenring heeft vooral gefaald omdat het meer eisen aan de hardware stelde en daardoor stukken duurder was.

Daarnaast betekent het niet dat als een techniek ergens in het verleden als achterhaald werd beschouwt, je dit in de toekomst ook maar moet doen. Kijk bijvoorbeeld naar hele discussie omtrend seriele en paralelle geheugenbussen in computers. Rambus was bijvoorbeeld een mooi ontwerp dat hel wat bandbreedte kon bieden. Het probleem voor Rambus was echter dat DDR dit ook kan, terwijl het minder kost. Echter, de rek begint er een beetje uit te komen. Dit komt onder andere omdat het paralelle structuur is, waarbij de timing van de afzonderlijke signalen ontzettend kritisch begint te worden. Iets waar je bij seriele communicatie minder last van hebt. Dus wordt er gekeken naar een combinatie FB-DIMM, die het goedkope DDR1/2/3-geheugen combineerd met een serieel communicatie kanaal.

Als je trouwens goed kijkt naar deze structuur, kun je zien dat er twee verschillende technieken worden gecombineerd. Een ringstructuur, die onder andere het voordeel heeft dat je heel makkelijk de latentie kunt uitrekenen, erg belangrijk voor een SoC!, en point-to-point verbindingen, die eigenlijk de snelste verbinding voorstellen. Volgens mij kun je hier heel mooie dingen mee bereiken, zeer zeker als je de plaatsing van de afzonderlijke blokken ene beetje slim aanpakt.

[zytec]

Als dit zo zou zijn, dan zouden backbones van grote netwerken niet als een ring uitgevoerd worden Dit is echter wel altijd het geval.

Dat is voor redundancy redenen. Als er b.v. een graafmachine of een klopboor door een kabel gaat. Wel zo prettig als je hele netwerk dan niet plat ligt.

Dit is bij ethernet opgelost door het gebruik van routers en switches, die als je heel goed kijkt, een soort van ring-netwerk van het geheel maken.

Mhh. ligt aan de topology, maar als dit het geval is, dan heb je wel veel minder hops t.o.v. een echte ringstructuur.

Een ringstructuur, die onder andere het voordeel heeft dat je heel makkelijk de latentie kunt uitrekenen, erg belangrijk voor een SoC!, en point-to-point verbindingen, die eigenlijk de snelste verbinding voorstellen. Volgens mij kun je hier heel mooie dingen mee bereiken, zeer zeker als je de plaatsing van de afzonderlijke blokken ene beetje slim aanpakt.

Latency & throughput, twee eisen die elkaar vaak bijten.

off topic: Hey Ralph, does E1C ring a bell !?
idem RickN: have a look at A.320 p from your window!

[DropjesLover]

kan het niet makkelijker door een sterstructuur te gebruiken en dan één apart blok in het centrum het verkeer te regelen? of is dat te simpel/te moeilijk...

maar als het sneller is als huidige technieken -> altijd beter

[Luxx]

Op zich is een sterstructuur soms wel sneller, maar het 'regelblok' moet wel een flinke capaciteit hebben als je er vele verkeersstromen op chipniveau wilt 'routen'... Dit gedecentraliseerde systeem heeft daar geen last van, en blijft daardoor veel simpeler, wat ook een snelheidswinst met zich meeneemt... Afhankelijk van de functie en eisen aan een chip, zal een ster, ring, of 'verbeterde ring' de beste oplossing zijn.

[michel_habets]

geweldige uitvinding,

het klinkt zo logisch dat ik me afvraag waarom de mensheid er niet eerder op gekomen is

[cyspoz]

Ik denk dat er al lang en breed mensen op zijn gekomen om het in een ring te plaatsen. Echter zal dit bedrijf een compleet protocol hebben opgestelt wat inzet baar is voor alle mogelijkheden zonder complex, zwaar of onveilig te worden. Die combinatie is nou net de kunst en daar lijken hun nu in geslaagd te zijn.

[M.M]

Volgens mij maakte de transputer al van een dergelijke communicatiestructuur gebruik.

Even graven... 20 jaar geleden?

[Verwijderd]

Ehhh, weet je, INMOS, de makers van de transputer zijn na hun faillisement overgenomen door: ( tèteretèèèt ) ST Microelectronics!!!

[Termi]

Ik denk niet dat STM zich richt op de consumenten markt . Dit zal eerder voor embedded hardware zijn.

[Ralph Smeets]

ST richt zich niet direct op de consumentenmarkt. Echter er is grote kans dat in veel producten die je in huis hebt gebruik maken van een chip die door ST wordt gemaakt, zoals je GSM-telefoon, je televisie, je monitor, in je computer, je printer, je digitale televisie ontvanger, enzovoort, enzovoort.

Deze techniek, waarvan ik zelf niet wist dat deze al zo ver doorontwikkeld was, komt dus in een aantal van die chips terecht om ervoor te zorgen dat alle onderdelen op de chip beter met elkaar kunnen communiceren

[daft_dutch]

ring stuctuur is vrij simpel. je hebt 1 master nodig en voor de rest kan je er zo veel aan kopelen als je wilt.
geen collisons, goede broadcast en een piortijds structuur.
daar door good geschikt voor realtime oplossingen wat je kan garanderen dat de informatie na een bepaalde tijd aan komt.
max tijd (aantal rondjes nodig + 1)

ster en mash structuur?
volgens mij hebben de mensen die dit als idee gaven niet echt opgelet in wat voor omgeving dit gaat.

in de chip industrie gaat het om minimaliseren van de aantal pootjes. wat ook weer inhoudt dat je minder koperbanen nodig hebt. ze kunnen honderden blokjes aan elkaar koppelen neem voor het gemak 300 (ik ga uit van een common ground)

mash: heb je per chip 2* 300 pootjes nodig
ster: een verdeel ic met 300 pootjes
ring : 2 pootjes

[RickN]

1. ringstructuur is decentralized, er is geen master.
2. collisions heb je nooit in een NoC, er draait geen complete protocol stack op die retransmissies doet ofzo. Goede arbitrage sluit collisions uit.
3. broadcast, boeie. Bovendien kun je in elk netwerk wel een broadcast doen.
4. prioriteitsstructuur is één arbitrage schema, en juist NIET geschikt voor voorspelbaarheid.
5. pootjes hebben met dit hele verhaal geen flikker te maken want het gaat om netwerken ON chip.
6. 300 componenten common ground? Mag ik lachen?
7. wat koperbanen is geen issue meer met 8 metaallagen.
8. area is überhaupt geen issue, want een NoC geeft toch maar een overhead van een paar procent.

Poeh, er valt hier nog een hoop te zeggen en ik zal er waarschijnlijk wel te laat mee zijn, maar goed:

Was begrijpend lezen bij Philips ook een eigenschap die onderzocht werd?

Laten we het erop houden dat ik hier meer van begrijp dan jij, mkay.
Ik was die extra links niet vergeten, maar die doen weinig meer dan van 1 ring 2 maken en de het maximale aantal hops in een pure ringstructuur halveren.

Als dit zo zou zijn, dan zouden backbones van grote netwerken niet als een ring uitgevoerd worden. [..] Dit is bij ethernet opgelost door het gebruik van routers en switches, die als je heel goed kijkt, een soort van ring-netwerk van het geheel maken.

Een ringstructuur en een mesh lijken bij weinig nodes dan ook erg op elkaar. Zo is een mesh met 4 nodes eigenlijk een een ring. Het verbaast me dus niet dat je dit bij backbones ziet, maar het gaat hier niet over weinig nodes. Netwerken met routers en switches vormen vaak een boomstructuur, ik kan hierin geen ring herkennen.

Als je trouwens goed kijkt naar deze structuur, kun je zien dat er twee verschillende technieken worden gecombineerd. Een ringstructuur, die onder andere het voordeel heeft dat je heel makkelijk de latentie kunt uitrekenen, erg belangrijk voor een SoC!, en point-to-point verbindingen, die eigenlijk de snelste verbinding voorstellen.

Die point-to-point verbindingen zijn zéér beperkt, de maximale afstand tussen twee nodes wordt gehalveert, maar dat is dus nogsteeds 50 bij 200 nodes.

En dan het grootste misverstand, dat latency en voorspelbaarheid hoofdzakelijk afhangen van je netwerkstructuur. Nee, het gekozen arbitrage schema is veruit het belangrijkste. De ST oplossing hanteert prioriteiten. Dat is heel leuk voor de taak met de hoogste prioriteit, omdat je daarvoor precies kunt zeggen hoelang de communicatie tussen twee nodes gaat duren. Echter, alle andere taken kunnen alleen nog best effort draaien. Je kunt niks meer garanderen. En dat je in een ring veel hops moet maken is dan een probleem, want elke hop gaat over een gesharede resource, en bij elke hop heb je dus de kans dat je moet wachten op een taak met een hogere prioriteit.

De Philips oplossing gebruikt TDMA scheduling. Dit is een periodiek schedule, waarin een taak een bepaald pad op een bepaald moment per periode kan reserveren. En op de momenten dat de ene taak een resource niet heeft gereserveerd kan een andere taak dat doen. Zo kun je voor veel verschillende taken throughput garanderen. Dit is dus volledig voorspelbaar, omdat je precies weet op welk moment een bepaalde taak een resource tot z'n beschikking heeft. Ongereserveerde capaciteit blijft beschikbaar voor best effort taken. Het nadeel van deze aanpak is, dat een "guaranteed thoughput" taak soms moet wachten op zijn reservering, terwijl de resource onbezet is, wat onnodige latency introduceert. Gegarandeerde lage latency bereik je dan door iedere periode veel resources te reserven, maar daarmee leg je wellicht onnodig beslag op een groot deel van de beschikbare capaciteit van het netwerk.

[Schapie]

Ofwel wat er ook mogelijk zou kunnen zijn met deze chip is dat de chip zich on the fly aanpast aan de vraag van de software wat voor berekeningen deze gaat doen.
(Ik kan niet opmaken of het ook on the fly werkt of dat het in een firmware oid vast wordt gelegd.)

Op dat betreft lijkt het wel op de chip van ik geloof de TU twente die een tijdje geleden voor bij kwam.

Ja dat was deze dus. Alleen heeft het bij deze chip als functie om energie te besparen en hebben de blokken (tegels daar genoemd) een vaste functie.

[DwarV]

Doet me een beetje denken aan de opbouw van de nieuwe chips van ATI

[Speedswitch]

Bij ATI was alleen de memory architectuur op deze manier opgebouwd, dat was niet de GPI

[YStec]

Tevens worden alle blokken direct verboden met de overbuurman aan de andere kant van de ring. Hierdoor kan het routingalgoritme datapakketjes veelal via een kortere route naar de bestemming sturen.

verboden moet verbonden zijn?

[T!mothy]

't is idd een goeie vooruitgang. Nu kunnen processors neem ik aan nog efficienter aan de gang...?

[Speedswitch]

Ik vraag me maar 1 ding af:

In ringnetwerken had je altijd het probleem dat sommige dingen bleven loopen.

Je pingt een pc die niet bestaat: PC1 pakt het pakketje...is niet van mij > gooit het door naar PC2...is niet van mij > gooit het door naar PC3 enz...
Dit kan voor flinke overbelasting van het netwerk zorgen.

Heeft dit systeem daar ook geen last van? Bijvoorbeeld de CPU stuurt een pakketje naar de videocodec, maar geeft door een software fout een verkeerd adres mee. Loopt dit systeem dan ook vast, of hebben ze daar rekening mee gehouden?

[Finwe]

Lijkt me dat ze daar wel rekening mee gehouden hebben, ofwel je geeft het packet een maximum time to live (TTL) mee, dan stopt hij er na x hops mee.

Ik ben ook niet overtuigd van deze structuur, zoals RickN al zegt kan de latency groot worden bij een groot aantal IP's, de snelste route naar een ander IP is minimaal 1/4 van de hops in de worst case denk ik. (Als je je een klok voorstelt, de snelste weg om van 12 naar 3 te komen is gewoon 3 stappen maken). Dit betekent dus dat als je straks 64 IP cores op een SoC hebt je al 16 hops nodig hebt om bij je bestemming te komen. Met een mesh-structuur kan dat aantal veel minder zijn...

[Ralph Smeets]

Denk eens paralel. Dus niet een blok die gegeven wil versturen naar een ander blok, maar:
blok 1 verstuurt gegevens richting blok 2
blok 3 verstuurt gegevens richting blok 2
blok 4 vraagt gegevens op van blok 3
blok 5 verstuurt gegevens richting blok 4
blok 5 verstuurt gegevens richting blok 2

Bij een mesh-structuur krijg je hier flink wat problemen met het vinden van het juiste arbitrage algorithme. Iets dat redelijk wat tijd kan duren en wat achteraf moeilijk te veranderen is. Het voordeel van een ringstructuur is juist dat je de maximale latentie kan bereken, iets dat niet altijd mogelijk is bij een mesh-structuur.