Model-based design brengt 3T sneller naar betere FPGA-implementatie

Bij de ontwikkeling van een FPGA voor een robotremsysteem is 3T modelgebaseerd te werk gegaan. Ronald Grootelaar van het Enschedese ontwerpbureau doet de gevolgde aanpak uit de doeken.

Model-based design (MBD) heeft de afgelopen jaren een hoge vlucht genomen. Vanuit de automotivesector en de luchtvaart heeft de ontwerpmethodiek haar weg gevonden naar vele andere industrietakken. De aanpak heeft vooral een enorme toegevoegde waarde in multidisciplinaire projectteams, doordat iedereen in hetzelfde modelgebaseerde simulatiepakket kan werken met eenduidig vastgelegde specificaties en modelverificatie in dezelfde testomgeving.

Bij 3T hebben we MBD ook geadopteerd voor de ontwikkeling van FPGA‘s. De recente systeemchiparchitecturen van Altera en Xilinx, met dubbele Arm Cortex-A9-core en complete FPGA-fabric, sluiten goed aan bij de aanpak. Algoritmes zijn naar wens in hardware of software te implementeren en voor data-uitwisseling bieden de Socs snelle interne Axi-bussen. Voor de externe data-interfaces kunnen we onder meer kiezen uit Gigabit Ethernet, PCI Express, Serial RapidIO en USB.

De gebruikte FPGA-ontwikkelflow is volledig afgestemd op tooling van Mathworks. We passen onder meer de modelgebaseerde simulatieomgeving van Simulink toe en de bijbehorende HDL Coder-toolbox voor automatische (HDL-)codegeneratie. Hiermee profiteren we optimaal van de voordelen die MBD biedt: hogere kwaliteit, snellere time-to-market en een hogere mate van flexibiliteit.

Randvoorwaarden

In samenwerking met een van onze klanten hebben we onlangs een remsysteem ontwikkeld voor een handling-robot. Deze robot transporteert en positioneert halffabricaten in een halfgeleidermachine. Hij wordt aangedreven door twee driefasemotoren en kan zowel strek- als draaibewegingen maken.

De robot gebruikt het remsysteem om een gecontroleerde noodstop te maken in een foutsituatie. Tijdens zo‘n remactie is het zaak de bewegingsbaan binnen een millimeter nauwkeurig te volgen om schade aan de machine te voorkomen. Omdat het remsysteem zijn werk volledig autonoom moet doen, moeten we die baan vóór het remmen afleiden uit de energie in de motor.

Het remprincipe berust op het kortsluiten van de motorfasen. Van de klant hebben we een uitgebreid Simulink-model van de robot gekregen en daaruit blijkt dat een closed loop-regeling nodig is om de bewegingsbaan binnen de vereiste nauwkeurigheid te kunnen volgen tijdens het remmen. Stroombegrenzing voorkomt schade aan de mechanische constructie.

Het remsysteem wordt realtime aangestuurd via een high-speed digitale communicatie-interface. Voor het meten van de motorspanningen tot 250 V en het bedienen van de rem zijn specifieke analoog-digitaalconverters (ADC‘s) en digitaal-analoogconverters (DAC‘s) nodig. Al deze randvoorwaarden vragen om het gebruik van een FPGA. Bij de ontwikkeling hiervan hebben we MBD toegepast.

IP-blok

Voor de remfunctionaliteit hebben we eerst een golden reference-model ontworpen dat werkt op basis van floating point-getallen. De bewegingsbaan reconstrueren we door de verhoudingen tussen de motorspanningen te bepalen en vervolgens de motorfasehoek uit te rekenen met een inverse tangens. Uit de fasehoeken van beide motoren leiden we ten slotte de baan af.

De regelaar gebruikt een infinite impulse response-filter (IIR) van de derde orde gecombineerd met een stroombegrenzingsalgoritme. De IIR-filtercoëfficiënten zijn instelbaar en vanuit software aanpasbaar. Na een aantal designiteraties en afregeling van de parameters werkt de golden reference in Simulink binnen de gestelde specificaties.

Het genereren van HDL-code voor de FPGA is hiermee echter zeker nog geen ’druk op de knop‘. De floating point-gebaseerde golden reference moeten we eerst omzetten naar een tijddiscreet fixed point-model dat uitsluitend door HDL Coder ondersteunde componenten bevat. Daartoe hebben we de impact onderzocht van deze fixed point-conversies en de omzetting van formules naar discrete componenten. Niet alle functionaliteit blijkt eenvoudig in Simulink te integreren. Dit geldt met name voor de benodigde communicatie-interface en ADC/DAC-aansturing.

We hebben er daarom voor gekozen het FPGA-model op te leveren als los IP-blok. Dit blok is een apart subsysteem in het Simulink-model en wordt een op een vertaald naar een VHDL-entity. De overgang van de systeem(regel)frequentie naar de hogere FPGA-klokfrequentie modelleren we in Simulink door middel van Rate Transition-blokken, waarbij de verschillende samplesnelheden overzichtelijk zijn weergegeven in verschillende kleuren.

FPGA-resources

Met HDL Coder hebben we hierna de FPGA-code gegenereerd. De resulterende generieke HDL hebben we vanuit de HDL Coder Workflow Advisor gesynthetiseerd en gemapt op de gekozen FPGA-architectuur, een Xilinx Spartan-6. Zo hebben we een beeld gekregen van de benodigde resources en timing closure.

Om timing closure-problemen het hoofd te bieden, is er in HDL Coder de mogelijkheid extra pipelineregisters te distribueren door het ontwerp. Het gewenste aantal kunnen we per subblok instellen. De toolbox draagt daarbij zorg voor de delay balancing, zodat parallelle datapaden (zonder pipelining) dezelfde vertraging krijgen. HDL Coder plaatst per definitie geen pipelineregisters in feedbackpaden omdat hierdoor de eigenschappen van het model veranderen. We kunnen echter handmatig pipelining toevoegen in de feedbackpaden om de timing closure rond te krijgen, bijvoorbeeld als er een filter op een lagere frequentie wordt doorgerekend dan de FPGA-klokfrequentie.

Om de benodigde hoeveelheid FPGA-resources te reduceren, kunnen we in HDL Coder gebruikmaken van resource sharing. Dit mechanisme werkt nog niet voor alle functieblokken. In ons FPGA-model zitten reciprocal– en squareroot-berekeningen die HDL coder niet kan delen, wat een zware last legt op de beschikbare DSP-cellen in de Spartan-6. Dit resourceprobleem hebben we opgelost door enkele subsystemen in HDL Coder aan te merken als black box. Onze FPGA-designers hebben deze ingevuld met een aantal gegenereerde Xilinx-IP-blokken en daaromheen een handvol multiplexers en demultiplexers om de resource sharing te controleren. Zo hebben we de remfunctie implementeerbaar gekregen binnen de beschikbare FPGA-resources (DSP-cellen, LUT‘s en registers).

Hardware-in-the-loop

HDL Coder heeft ook de mogelijkheid om een cosimulatiemodel te genereren voor RTL-simulatie. De RTL-code die dit oplevert, kunnen we draaien in een RTL-cosimulator zoals Modelsim, die wordt aangestuurd vanuit Simulink. In gevallen zoals de onze is dit altijd aan te raden, omdat het cosimulatiemodel de gegenereerde HDL simuleert, inclusief pipelining, delay balancing én eventuele black boxes.

Bij het genereren van het cosimulatiemodel wordt een Modelsim-script aangemaakt. De implementaties voor de black boxes moeten we handmatig toevoegen, alsmede eventuele leverancierspecifieke simulatiebibliotheken. Vervolgens starten we eerst Modelsim in servermodus en dan de Simulink-simulatie. Verschillen tussen cosimulatie en het originele model worden weergegeven in scope plots. Deze maken zelfs marginale discrepanties tussen de black-boximplementaties en de Simulink-equivalenten inzichtelijk.

Een cosimulatie duurt wel aanzienlijk langer dan een simulatie in Simulink. Daarom ondersteunt Mathworks als alternatief FPGA-hardware-in-the-loop-verificatie. Hierbij wordt de HDL-code eerst gefit en dan gedownload in een standaard FPGA-kaart van Altera of Xilinx. Simulink communiceert met dit bordje via een standaard Ethernet-verbinding.