Co-simulatie voor op Zynq gebaseerde ontwerpen

Heterogene System-on-Chip (SoC)-apparaten zoals de Xilinx Zynq 7000 en Zynq UltraScale+ MPSoC combineren hoogwaardige verwerkingssystemen met geavanceerde programmeerbare logica. Door deze combinatie kan het systeem zo worden ontworpen dat het een optimale oplossing biedt. Gebruikersinterfaces, communicatie, besturing en systeemconfiguratie kunnen worden aangepakt door het processorsysteem (PS). Ondertussen kan de Programmable Logic (PL) worden gebruikt om lage latentie, deterministische functies en verwerkingspijplijnen te implementeren die de parallelle aard ervan benutten, zoals die worden gebruikt door beeldverwerking en industriële toepassingen.

De communicatie tussen de PS en de PL wordt verzorgd door verschillende memory-mapped interfaces. Deze interfaces gebruiken de Advanced eXtensible Interface (AXI) om zowel master- als slave-communicatie in elke richting te bieden.

Afbeelding 1. Zynq-architectuur met AXI-interconnectie tussen de PS en PL (Bron:Xilinx)

In gevallen waar configuratie- en besturingsfuncties worden uitgevoerd door de PS, wordt de universele AXI Master-interface gebruikt van de PS naar de PL. Hierdoor kan de software (SW) registers configureren en daarmee het gewenste gedrag van IP-cores in de PL. Bij complexere operaties kan er een wens zijn om grote hoeveelheden gegevens van de PL naar de PS-geheugenruimte over te dragen voor verdere verwerking of communicatie. Deze overdrachten maken gebruik van de krachtige interfaces, waarvoor aanzienlijk complexere software nodig is om te configureren en te gebruiken.

Het verifiëren van interacties tussen de PS en PL stelt het ontwerpteam voor uitdagingen. De 2015 Embedded Markets Survey identificeerde debugging als een van de grootste ontwerpuitdagingen waarmee engineeringteams worden geconfronteerd en identificeerde ook de behoefte aan verbeterde debugging-tools. Hoewel functionele busmodellen in eerste instantie kunnen worden gebruikt, zijn deze modellen vaak vereenvoudigd en kunnen de ontwikkelde SW-stuurprogramma's en de applicatie niet tegelijkertijd worden geverifieerd. Er zijn volledig functionele modellen beschikbaar, maar deze kunnen onbetaalbaar zijn. Bij het implementeren van een heterogeen SoC-ontwerp moet er een verificatiestrategie zijn waarmee zowel PL- als PS-elementen zo vroeg mogelijk samen kunnen worden geverifieerd.

Traditioneel wordt de verificatie in eerste instantie uitgevoerd voor elk element (functieblok) in het ontwerp afzonderlijk; het verifiëren van alle blokken samen gebeurt wanneer de eerste hardware arriveert. Het software-engineeringteam dat de toepassingen ontwikkelt om op de PS te draaien, moet ervoor zorgen dat de Linux-kernel alle benodigde modules bevat om het gebruik ervan te ondersteunen en de juiste apparaatboom-blob heeft; dit wordt normaal gesproken geverifieerd met behulp van QEMU (afkorting van Quick Emulator), een gratis en open source gehoste hypervisor die hardwarevirtualisatie uitvoert.

Om het PL-ontwerp correct te verifiëren, moet het logische verificatieteam ondertussen commando's genereren en op volgorde zetten zoals die door de applicatiesoftware worden uitgegeven om te verifiëren dat de logica werkt zoals vereist. Beide benaderingen leggen echter niet de ware interactie van de software met de hardware vast, waardoor fouten die met deze interactie samenhangen zeer moeilijk te detecteren zijn. Dit vertraagt ​​het ontwikkelingsschema en verhoogt de ontwikkelingskosten, aangezien problemen die later in het ontwikkelingsproces aan de orde worden gesteld, altijd duurder zijn om aan te pakken en te corrigeren.

Het is mogelijk om een ​​ontwikkelbord te gebruiken als tussenstap om de HW- en SW-interactie te verifiëren voordat de definitieve hardware arriveert. Debuggen op echte hardware kan echter ingewikkeld zijn, waardoor extra instrumentatielogica in de hardware moet worden ingevoegd. Dit invoegen kost extra tijd omdat het bitbestand opnieuw moet worden gegenereerd om de instrumentatielogica op te nemen. Natuurlijk kan deze wijziging in de implementatie ook van invloed zijn op het onderliggende gedrag van het ontwerp, waardoor problemen worden gemaskeerd of nieuwe problemen worden geïntroduceerd die alleen zichtbaar worden in de debugging-builds.

Het kunnen verifiëren van zowel het SW- als het HW-ontwerp met behulp van co-simulatie biedt daarom verschillende belangrijke voordelen. Het kan eerder in de ontwikkelingscyclus worden uitgevoerd en er hoeft niet te worden gewacht tot de ontwikkelingshardware arriveert, waardoor de kosten en gevolgen van foutopsporing worden verminderd. Bovendien zorgt een dergelijke aanpak ook voor meer zichtbaarheid met betrekking tot registers en interacties tussen de PS en PL, wat allemaal helpt bij het ontdekken en verwijderen van bugs eerder in het proces.

HW &SW co-simulatie

Co-simulatie tussen SW en HW vereist de logische simulatietool die wordt gebruikt om het HW-ontwerp te verifiëren om te kunnen communiceren met een SW-simulatie-emulatieomgeving.

De release van Aldec's Riviera-PRO (2017.10) maakt alleen deze HW- en SW-co-simulatie mogelijk door een brug te vormen tussen Riviera-PRO en QEMU, waardoor de uitvoering van de ontwikkelde software voor op Linux gebaseerde Zynq-ontwikkelingen mogelijk wordt.

Figuur 2. Een brug slaan tussen de HW- en SW-verificatieomgevingen (Bron:Aldec)

Deze brug is gemaakt met behulp van SystemC Transaction Level Modeling (TLM) om de communicatiekanalen tussen QEMU en Riviera-PRO te definiëren. De gelijktijdige verificatie van de SW en HW wordt vergemakkelijkt door het vermogen van de brug om informatie in beide richtingen over te dragen.

Binnen deze geïntegreerde simulatieomgeving kan het engineeringteam standaard en geavanceerde debugmethodologieën gebruiken om eventuele problemen aan te pakken die zich kunnen voordoen naarmate de verificatie vordert. In het geval van Riviera-PRO omvat dit mogelijkheden als het instellen van breekpunten binnen de HDL, het onderzoeken van de gegevensstroom en zelfs het analyseren van de codedekking en paden die worden uitgeoefend door de SW-toepassing die in QEMU wordt uitgevoerd. In het geval van QEMU kan het SW-team Gnu DeBugger (GDB) gebruiken om zowel de kernel als de driver te instrumenteren om door de code te stappen met behulp van breekpunten.

Deze co-simulatiebenadering heeft niet alleen het voordeel dat het meer zichtbaarheid en debugging-mogelijkheden biedt binnen de hardwaresimulatieomgeving, maar het maakt het ook mogelijk dezelfde Linux-kernel te gebruiken die is ontwikkeld voor de doelhardware binnen QEMU. Nogmaals, dit zorgt voor eerdere verificatie dat de kernel correct alle vereiste pakketten en elementen bevat om de applicatie in ontwikkeling te ondersteunen.

PWM-voorbeeld

Om deze co-simulatieomgeving te demonstreren, is een eenvoudig voorbeeld gemaakt. Dit voorbeeld plaatst een IP-kern in de PL en verbindt deze met de Zynq PS via een algemene AXI-interface. Indien ingeschakeld door een AXI-toegang tot zijn registerruimte, genereert de IP-kern een pulsbreedtegemoduleerde (PWM) signaaluitvoer. De duur van het PWM-signaal is selecteerbaar binnen een bereik van 0 tot 100% en wordt opnieuw bepaald door een register binnen de registerruimte van de IP-kern. Een typische use-case voor deze kern vereist daarom software die in de Zynq PS draait om de IP-kern in te schakelen en te configureren. Het alleen maar simuleren van de IP-core in isolatie zal er niet toe leiden dat de gewenste werking van de core voldoende wordt aangetoond. Om de IP-kern correct te verifiëren, moeten we de outputpulsbreedte van de PS kunnen inschakelen en oefenen wanneer een Linux-besturingssysteem wordt uitgevoerd.