De worsteling van de moderne ontwikkelaar

De worsteling van de moderne ontwikkelaar

In het technologiegeweld anno 2015 is systeembouw geen sinecure. Van bergen documentatie tot incomplete referentieontwerpen.

In 1971 daagde Intel potentiële ontwikkelaars uit met een eerste ontwerp van een microprocessor, de MCS-4, opgebouwd uit 2900 transistoren en met een datasheet van 82 pagina’s. In 1976 bouwde Steve Wozniak in zijn eentje de hardware en het besturingssysteem van de inmiddels legendarische Apple II-computer, gebaseerd op de uit ongeveer 3500 transitoren opgebouwde 6502-CPU van Mos Technology. Vandaag de dag is er een overvloed aan (systeem)chips, opgebouwd uit miljarden transistoren en met datasheets van wel duizenden pagina’s. Bij Texas Instruments is er keuze uit 825 verschillende microcontrollers, bij Freescale uit meer dan duizend, en dan zijn daar nog Atmel, Microchip, Renesas, Silicon Labs, ST en vele andere, veelal ARM-gebaseerde mcu’s. Vergeet daarbij ook Intel niet met zijn embedded pc-platforms. Daarnaast bestaan er minstens evenveel leveranciers van functiespecifieke producten als encryptie/decryptiecores, netwerkchips, rf-ic’s en raid-controllers. Hoe zien we de bomen door dit bos?

Overdimensioneren

Met een dergelijke technologie- en informatiestroom is het ons eigenlijk niet meer gegeven om een chiparchitectuur in korte tijd volledig, of zelfs maar voldoende, te doorgronden. Om het risico op tegenvallers te reduceren, zoeken we het daarom vaak eerst maar op bekend terrein, daarbij primair geleid door het concrete wensenpakket: levert de chip alle benodigde functies voor het product? Hierbij valt te denken aan aantal en typen USB- en PCI Express-aansluitingen en ondersteuning voor HDMI, LAN en SATA. En als er dan iets ontbreekt: zijn er ondersteunende chips die het gat (eenvoudig) kunnen opvullen? Vervolgens is er de lastigere afweging: kan de onderliggende hardwarearchitectuur überhaupt de gevraagde performance leveren? Wat is daar binnen die architectuur voor beschikbaar? Zijn er caches? Hoe groot zijn ze? Hoe gaan de cores met de caches om? Is er dma-ondersteuning? Wat is de geheugentopologie en bandbreedte? Wat kost het aan vermogen? Dit alles vraagt niet alleen om een degelijke kennis van de technologie, maar ook om een gedegen inschatting en onderbouwing van de consequenties die keuzes met zich meebrengen. Om daar weer een goed beeld van te krijgen, moeten we de bijbehorende documentatie doorspitten, wat weer de nodige tijd kost, zeker met de hedendaagse overvloed daaraan. Voor de TI6674 zijn er meer dan 4800 pagina’s aan datasheets en handleidingen beschikbaar. Ik ben ooit betrokken geweest bij de opdracht om met deze TI6674, een quadcore dsp op 1 GHz, een 64k-punts convolutie te implementeren met een zeer stringente realtime-eis. Tijdens de proof-of-conceptfase kwamen we erachter dat de complete dataset net niet in de L1- en L2-caches van een processorkern paste, waardoor de gebruikte core een deel in het externe geheugen plaatste. Zolang de andere drie cores tijdens de berekening van dat geheugen afbleven, haalden we de eis. In de praktijk is dat natuurlijk redelijkerwijs nooit te garanderen. Iets kan wel werken op papier, de dynamiek van het totale systeem kan roet in het eten gooien; die is applicatiegebonden en laat zich niet of slecht modelleren en kwantificeren, waardoor de impact ervan op voorhand niet te bepalen is. De keuze is dan gauw gemaakt om de architectuur te overdimensioneren: meer instructies per seconde, meer GHz’en, meer gigabytes, meer gigabit per seconde en meer features dan direct noodzakelijk. Allemaal beschikbaar tegen relatief lage kosten, dus waarom niet die ruimte nemen om eventuele vergissingen, misinterpretaties en systeemdynamiek in een later stadium (hopelijk) nog te kunnen ondervangen? Dit kan echter leiden tot verspilling van resources, onwillekeurige introductie van ongewenste artefacten en, wellicht bovenal: het draagt niet bij aan het noodzakelijke probleemoplossend vermogen van de ontwikkelaar.

Adequate support

Voor een totaaloplossing is er natuurlijk software nodig. Ook hier maakt de complexiteit van de architecturen dat we niet meer zonder een volwassen ontwikkel- en debugomgeving kunnen, gebaseerd op een of andere vorm van volwassen support. Door de opkomst van ARM en de voordelen van opensource wordt steeds vaker Linux toegepast. Bij deze keuze loert echter het gevaar dat we een basisoplossing krijgen die we nog uren, of zelfs dagen, moeten configureren, tweaken en/of doorontwikkelen om de performance te bereiken die we wensen. We grijpen daarom vaak terug op referentieborden om het platform, samen met (een deel van) de applicatie, snel te kunnen benchmarken. In relatief korte tijd zou dat een redelijk representatieve indruk moeten kunnen geven van de performance die de gekozen combinatie van hardware en software kan bieden. Voorwaarde is wel dat die combinatie alle ingesloten features (optimaal) kan benutten. Het referentieplatform moet dus compleet en foutvrij zijn, maar daar schort het nogal eens aan, ons daarmee al in een vroeg stadium opzadelend met een lastig ontwikkel- en integratietraject. Neem de Beaglebone Black met Sitara AM3354-cpu van TI. Voor dit, in de embedded-markt populaire, referentiebord is ook een Linux-distributie beschikbaar, die alle i/o ondersteunt, eenvoudig toegang biedt tot het hele platform en het zo mogelijk maakt om er snel mee te starten. Dit wekt de verwachting dat alle features van de TI-chip worden ondersteund. Veel van de meegeleverde drivers bieden echter slechts basale toegang tot de i/o. Wie enige (realtime) performance wenst, zal aan de slag moeten met de Programmable Real-Time Unit of het Intelligent Communication Subsystem om de geadverteerde mogelijkheden van de chip te kunnen benutten. Hierbij ligt er ook een belangrijke taak voor de fabrikant en distributeur om gedegen inhoudelijke ondersteuning te leveren. Onder meer via field application engineers bieden zij vaak redelijk directe toegang tot allerlei informatie, waarmee we al een eind op weg geholpen zijn. De ervaring leert echter ook dat het bij complexere issues lastig is om het probleem goed ‘over de bühne’ te krijgen zodat er vaak een langdurig, en deels frustrerend, traject nodig is om adequate support te ontvangen.

Geen soelaas

De samenbouw van de hardware is evenmin een sinecure; het integratieniveau binnen de componenten mag dan zijn toegenomen, de complexiteit van de resterende onderlinge verbindingen is er niet minder op geworden. We zien ons geconfronteerd met een veelvoud van kritieke voedingen, snelle i/o en uitdagende geheugeninterfaces. Het complexe deel van het ontwerpwerk verplaatst zich meer en meer naar de PCB-routing, terwijl we voor de invulling van het schema teruggrijpen naar de referentiedesigns om te kijken hoe we de issues snel verantwoord kunnen invullen – onder het mom ‘beter goed gejat dan slecht verzonnen’. De ontwerpcomplexiteit verhuist zo naar de printplaat. Daarmee komt er een grotere verantwoordelijkheid te liggen bij de PCB-ontwikkelaars en hun tools. Waar PCB’s in het verleden een eerste vervanging waren voor de handmatige bedrading van een systeem, zijn ze nu zo’n beetje een semi-actieve component geworden binnen het ontwerp. De tooling moet daarom veel features bieden om de complexe routing snel en efficiënt te kunnen uitvoeren. Lag de nadruk vroeger op de features van de geleverde auto-router, tegenwoordig zijn functies als controlled-impedance routing, trace length matching, differential routing, layer stack-up en controle van de signaalintegriteit veel belangrijker om de vereiste PCB-complexiteit te kunnen realiseren. Met het beschikbaar komen van de targethardware begint het proces om de uiteindelijke applicatie op te bouwen en uit te werken, mede op basis van de ervaringen opgedaan met de referentiedesigns. Wat als er dan door een (on)voorziene samenloop van omstandigheden iets niet werkt? Waar en hoe gaan we zoeken? Waar halen we support? Door de hoge integratiegraad krijgen we wel veel voor weinig, maar het helpt niet in de toegankelijkheid tot het platform. Non-intrusive debugging is daardoor lastig tot zelfs ondoenlijk. En met intrusieve foutopsporing lopen we de kans om het systeem dermate te beïnvloeden dat het probleem zich ineens niet meer voordoet. Zo was er de situatie rond een MPC5200B-gebaseerde systeemmodule waarbij de ethernetcommunicatie na enige uren volledig stopte. Een supportverzoek bij Freescale resulteerde in het heen en weer sturen van systeemlogs en veelal zinloze suggesties; zinvolle externe metingen zijn eigenlijk niet mogelijk en de tools voor intrusive debugging bieden geen soelaas voor dit soort dynamische systeemproblemen. Googelend naar ervaringen van andere ontwikkelaars op hetzelfde platform stuitten we op de tip om een specifiek bit te zetten in een register. Dit liet het probleem verdwijnen, bleek na uitvoerige tests, maar waaróm is, door de complexiteit van de MPC5200B-architectuur en onbekendheid met hoe de Linux-kernel en –drivers de hardware configureren, nog steeds niet duidelijk. Ook Freescale kon de reden niet vertellen.

Inhoudelijke rol

De tijd is voorbij dat iemand zich in zijn garage kan ontpoppen tot een Steve Wozniak. Het vereist al snel een teaminspanning van verschillende disciplines en competenties om een productontwikkeling goed vorm en inhoud te geven. Er komen simpelweg te veel technische issues in samen en er zijn te veel tools nodig voor één persoon om het traject binnen een verantwoorde doorlooptijd tot een goed einde te brengen. Ontwikkelaars dienen zich vergaand te specialiseren om zich staande te kunnen houden in het technologiegeweld anno 2015. Daarnaast is er een steeds grotere inhoudelijke rol weggelegd voor fabrikanten. Zij moeten deugdelijk referentiemateriaal, toegankelijke informatie en laagdrempelige support leveren.

Confed – Auteur: Cees van Teylingen (cees.vanteylingen@confed.eu)

Bits&Chips – Redactie: Nieke Roos (nieke@techwatch.nl)

Bits&Chips

Beaglebone

MPC 5200



COMMENTS1

  1. Een duidelijke weergave van de afwegingingen voor de (hardware) designers met een juiste constatering van de rollen van oa de distributeurs / fabrieks reps. Het wordt technisch steeds complexer, anderszijds steeds meer geintegreerde functies per component. Designers moeten de focus op systeemniveau hebben en de technische distributeurs op componentniveau. Maak gebruik van die kennis om risico’s te verkleinen en time-to-market te verkorten. Als dan de EMS- er ook die rollen respecteerd, blijft de balans bewaard en de keten in takt.


LEAVE A COMMENT

Deze website gebruikt Akismet om spam te verminderen. Bekijk hoe je reactie-gegevens worden verwerkt.