Beslissingen, beslissingen:hardwareversneller of DSP?

In mijn eerste twee blogs over dit onderwerp heb ik het gehad over waarom DSP's plotseling overal opduiken en waarom ze in het bijzonder een aantal aangepaste hardwareversnellers (HWA) beginnen te vervangen als een flexibelere en toekomstbestendige optie. In deze blog wil ik het hebben over een meer gedetailleerde analyse die u kunt volgen om te beslissen of u aan een DSP moet denken in plaats van aan een HWA-implementatie.

(Bron:CEVA)

Ik noemde in de vorige blog enkele van de ideale toepassingen voor DSP's. Signaalverwerking voor modem- of audiosignalen zijn duidelijke voorbeelden. Een ander veel voorkomend voorbeeld is de signaalverwerking in radars voor autonome auto's, die vrij gelijkaardig is aan de signaalverwerking in een modem. Veel hiervan zijn gebouwd rond een hardwareversneller in combinatie met een kleine controller. We zien nu een significante trend onder die oplossingsproviders om over te schakelen naar architecturen waarin meer van de functionaliteit is gebaseerd op software die op een DSP draait, waarbij de signaalverwerking die momenteel wordt afgehandeld door de HWA en zelfs enige controle wordt gecombineerd. De redenering is simpel:software biedt meer flexibiliteit in functionaliteit en veel goedkopere en snellere mogelijkheden om zich aan te passen aan veranderende communicatiestandaarden.

Globale positionering is een andere toepassing, waarbij in dit geval sterk gebruik wordt gemaakt van de wiskundige mogelijkheden die inherent zijn aan DSP's voor de triangulatieberekeningen. In eerste instantie zou je denken dat GPS-ondersteuning alles is wat je nodig hebt en misschien kun je een heel snelle implementatie bouwen in een hardwareversneller. In de wereldwijde GNSS-standaard moet u echter ook rekening houden met ondersteuning voor GLONASS (Rusland), Galileo (Europa) en BeiDou (China). Een vast bedrade implementatie voor GPS kan uw markten onnodig beperken, aangezien het ondersteunen van alle varianten in software kan worden bereikt als u op een DSP werkt.

Tot nu toe in principe goed, maar hoe presteert een DSP-implementatie versus een aangepaste hardware-implementatie? Ik zal het vandaag illustreren met een populair voorbeeld:stel dat u een IoT-toepassing bouwt en van plan bent NB-IoT te gebruiken voor communicatie. De lengte van het subframe is 1 ms, wat een begrenzingslimiet definieert voor bepaalde verwerkingen die binnen die tijd moeten worden voltooid. In dit voorbeeld zou dat de algoritmen van de fysieke laag, de L1-besturingscode en de protocolstack omvatten. Voor een typisch DSP/NB-IoT-platform met laag vermogen dat draait op 100 MHz, geeft 1 ms u 100k cycli om die berekeningen te voltooien.

Om in te schatten wat voor soort prestaties u kunt verwachten in een gelijkwaardige DSP-implementatie, moet u werken met een embedded DSP-leverancier. Zo'n bedrijf zou al softwareoplossingen op hun platformen moeten aanbieden voor meerdere toepassingen, die ze zullen hebben gekenmerkt door prestaties en kracht. Voor prestaties zouden ze u een schatting van het aantal cycli voor uw functie moeten kunnen geven, in dit geval een NB-IoT-modem, en u een grafiek kunnen geven, vergelijkbaar met die hieronder. Elk punt in de grafiek vertegenwoordigt het aantal cycli dat nodig is om uit te voeren en de grafiek wordt in kaart gebracht over een in de tijd variërend bereik van belastingen. De grafiek moet ook de maximaal toelaatbare cycli weergeven bij een geselecteerde werkfrequentie.

(Bron:CEVA)

Nu heb je een methode om in te schatten of je applicatiebelasting op die frequentie zal werken, of dat je de frequentie misschien moet verhogen om je meer hoofdruimte te geven. Natuurlijk is deze schatting gebaseerd op de software-implementatie van de leverancier, hoewel het redelijk is om te verwachten dat deze redelijk goed zal worden afgestemd. U hoeft zich niet te binden aan het gebruik van hun software, maar de schatting moet goed genoeg zijn om uw besluitvorming te begeleiden.

Als u voldoende hoofdruimte heeft op uw gewenste werkfrequentie, kunt u misschien meer HWA-functies naar de DSP verplaatsen of misschien meer onderscheidende functies toevoegen, zoals GNSS-locatieondersteuning. Als u aan de andere kant de frequentie moet verhogen om aan de latentievereisten te voldoen, is dat ook mogelijk, maar u moet er rekening mee houden dat het verhogen van de frequentie het gebied en het stroomverbruik zal vergroten.

Een snelle manier om een ​​schatting van het vermogen te krijgen, is door te kijken hoeveel van de software in echte DSP-code gaat, met behulp van parallellisme, MAC-eenheden enz., en hoeveel er in de besturingscode gaat - de gebruikelijke algemene - doelcode aanroepende functies, het nemen van beslissingen en andere standaardhandelingen. U kunt deze splitsing meestal in het oog houden, zeg 40% controlecode en 60% DSP-code. Een DSP-leverancier zal vaak typische stroomnummers voor deze twee gevallen verstrekken, bijvoorbeeld 2mW voor besturingscode en 4mW voor DSP-code (in elk geval bij 100MHz). In uw berekening moet u rekening houden met de gemiddelde activiteit van de DSP, bijvoorbeeld 50% van de frequentie. Dus in dit voorbeeld zou je een schatting maken van (0,4 * 2 + 0,6 * 4) * 0,5 =1,6 mW gemiddeld vermogen (uitgaande van een gemiddelde activiteit van 50%).

Samenvattend zou u een redelijk redelijke schatting moeten kunnen maken van welke prestaties en kracht u kunt verwachten voor een DSP-implementatie van uw acceleratorfunctie (tenzij u iets heel ongewoons ontwikkelt - in dit geval zou u uw toepassing in de DSP's moeten modelleren SW-tools om een ​​vrij nauwkeurige schatting te krijgen voor het aantal cycli). Als je kijkt naar de extra flexibiliteit die je krijgt van een software-implementatie en de mogelijkheid om kosten te besparen door meerdere versnellers op één processor te combineren, ziet een DSP-oplossing er behoorlijk aantrekkelijk uit.