Samtidigt som många företag försöker förstå vad ESL (Electronic System Level Design) innebär, vilket värde dettta mångfacetterade angreppssätt kan medföra för utvecklingsprocessen och hur det kan påverka deras sätt att arbeta, finns redan flera inom konsumentprodukter och mobilindustrin som anammat begreppet. ESL håller fortfarande på att ta form, men idag bör ingen undvika begreppet.

 

ESL kan ta ett koncept och överföra det effektivt mot hårdvara och mjukvara samt göra detta med kortare utvecklingstider samtidigt som man uppnår ett mer optimalt system. De företag som idag använder ESL utnyttjar dock i mycket få fall hela dess styrka. Att anamma ESL kräver investeringar i teknik, infrastruktur och modeller.

RTL, Register Transfer Level, är den nuvarande grunden för utveckling av hårdvara. I dess mest basala beskrivning innebär ESL att en modellbeskrivning införs före RTL-nivån. Detta är dock mycket förenklat. Från ett flödesperspektiv siktar ESL på att automatisera vägen från koncept till implementation.

Ur företagets perspektiv reducerar ESL kostnaden för en produkt genom högre produktivitet, minskad NRE, lägre kiselkostnad och inte minst kortare utvecklingstid. Från konstruktionssynpunkt leder ESL till högre abstraktionsnivå.

Det stora flertalet av dagens produkter konstrueras med RTL-metodik. I framtiden räcker dock inte det, då komplexiteten ökar (simuleringshastigheten räcker inte, kodmängden blir oöverblickbar). Dessutom ökar ESL möjligheten att kontrollera och differentiera samt skala elektronikprodukterna vilket tar produkten till marknaden på mycket kortare tid.

En utvecklingsprocess skulle kunna delas in i tre faser: Koncept, följt av konstruktion, följt av implementation.

Vid konceptfasen skapas en beskrivning av systemet utan klar definition eller uppdelning av mjuk- och hårdvara. I konstruktionsfasen delas denna konceptuella beskrivning till hårdvara (RTL) och till mjukvara (C/C++). Vid implementationsfasen tas hårdvara till kisel samt C/C++ till firmware och mjukvara.

Man kan likna dessa tre faser vid en ”vision” som tas vidare till ”strategi” som i sin tur görs om till ”taktik”. Strategin definierar bästa vägen att exekvera visionen, taktiken är de steg som tas för att leverera strategin.

Dagens utvecklingsprocesser startar i de flesta fall först i implementationsfasen. Konceptfasen saknas helt, och likaså oftast konstruktionsfasen, i alla fall en automatiserad sådan. Tänk er att man har en vision men inget sätt att definiera en strategi och därför går direkt till taktik. Hur många gånger behöver man då iterera och ändra taktiken innan man uppnår visionen? En korrekt strategi låter oss sätta klara riktlinjer för taktiken och ger effektiv kontroll över den.

Konceptfasen startar med en specifikation och givna krav som översätts till algoritmer och funktioner som kan valideras. Det finns flera språk som kan användas för detta, som UML och C/C++.

Då konstruktionsfasen ännu inte är helt definierad inom ESL kan konceptfasen inte heller bli helt definierad. Därför lämnar vi i nuläget konceptfasen därhän och koncentrerar oss på konstruktions-och implementationsfaserna.

Konstruktionsfasen definierar hårdvaru- och mjukvarudomänerna som kan bära vårt koncept och parallellt driva hård- och mjukvaruutvecklingen. Den låter oss utforska och optimera hårdvaru- och mjukvaruresurser och säkerställer att de interagerar korrekt. Detta är ett nyckelmål för ESL, en konstruktionsfas som låter dig hitta och skapa den bästa konfigurationen för hård- och mjukvarusystemet som är funktionellt korrekt och som implementerar ditt koncept.

Implementationen automatiserar RTL till kisel. När implementationsfasen drivs från konstruktionsfasen blir det mer effektivt med kortare verifikationscykler eftersom integreringen mellan hårdvaru- och mjukvarublocken redan är validerad. RTL-verifiering kan således helt fokusera på implementationsaspekter snarare än på systemnivåaspekter, såsom hård- och mjukvaruintegration, protokollmissar och dataintegritet, då dessa är mycket svårare att upptäcka på RTL-nivå.

För 20 år sedan gick steget från grindnivå till RTL-nivå relativt enkelt. Båda de nivåerna håller sig inom implementationsfasen. Att gå från implementation till konstruktion med ESL är ett mycket större steg som spänner över gränserna mellan specifika arkitekturer och hårdvara/mjukvara. Detta ger större möjligheter men kräver samtidigt mer sofistikerade och automatiserade processer, exempelvis högnivåsyntes. Det medför även en annan viktig aspekt av ESL, nämligen att alla implementationsspecifika detaljer från systembeskrivningen elimineras. I mjukvaruvärlden skedde detta för länge sedan. Mjukvara utvecklas generiskt, oberoende av målplattform, och kan portas till olika processorer och arkitekturer.

Att ta bort hårdvaruimplementationen påverkar alla lager inom modelleringen. ESL använder sig av TLM (Transaction Level Modelling) som beskriver kommunikation generiskt, såsom läs- och skrivtransaktioner. TLM är första steget för att få hårdvara att matcha samma paradigm som mjukvaran. Fokus ligger på vad som kommuniceras istället för hur det kommuniceras. Sättet man modellerar TLM är oberoende av specifikt protokoll för att överföra data eller vilken buss som används, det kan exempelvis vara AMBA, AXI eller USB. Ett beräkningsblock i ESL fokuserar bara på funktionen i blocket, det vill säga algoritmen, inte på den specifika hårdvara som behövs på kiselnivå. Genom att eliminera implementationsdetaljerna vinner vi följande:

1. Tidsinformation utesluts.
2. Modellen är hårdvaru- och arkitekturoberoende.
3. Modellen exekveras och simuleras mycket snabbare vilket medför att mjukvara kan köras i realtid.
4. Modellen kan överföras till olika implementationer (parallella, sekventiella, en kombination av de båda) med bibehållen funktionalitet.

Låt oss anta att det första steget av konstruktionsfasen, uppdelningen mellan hård- och mjukvara, redan är gjord och att vi har ett antal funktioner som beskriver vad hårdvaran ska göra. Dessa funktioner, som kan representera olika typer av databehandling eller kommunikationsalgoritmer, är beskrivna som TLM-modeller. Sådana modeller kallas PV- modeller (Programmable View). De kan behandla och flytta stora block av data utan någon tidsåtgång. Här är ”hur” data behandlas och flyttas ointressant, endast datat och hur det lagras är av intresse. PV-simulering är extremt snabb då det inte finns någon tidsberäkning som behöver utföras vilken normalt sett tar mycket mer CPU-kraft i anspråk än funktionell beräkning. PV-plattformen kan användas för att validera systemet och som virtuell plattform för mjukvaruutveckling tidigt i utvecklingscykeln.

När PV-plattformen är validerad kan vi börja titta på implementationsstrategier för att nå nödvändig prestanda ifrån systemet. Implementationen av hårdvarublocken kommer att lägga till fördröjningar (latency) som påverkas av den mängd parallellism och pipelining som används. En PV-transaktion som exekveras omedelbart i PV-nivån kommer nu att expandera i tid och kan även brytas upp i flera mindre transaktioner. Vi får här en modell som har tid. Sättet som data delas upp och distribueras över tid beror på interna buffrar, bussarkitektur, protokoll och DMA-konfiguration (Direct Memory Access).

Konstruktionsmodellering. Som nämnts tidigare hoppar man idag ofta över konstruktionsfasen, och man börjar med att skapa en RTL-beskrivning utgående från de erfarenheter som konstruktionsteamet har baserat på tidigare projekt och ad-hoc beslut. Det beror på avsaknaden av teknik och metodik som kan stödja teamet effektivt och låta dem exekvera strategierna deterministiskt.
I motsats till RTL skall en modell vid konstruktionsfasen kunna användas i olika domäner med potentiellt motsatta krav, såsom validering av hårdvara och mjukvara. Modellen ska kunna översättas från en sekventiell beskrivning utan tid till en parallell beskrivning med tidsinformation.

Högnivåsyntes är en nyckelteknologi för att automatisera konstruktionsfasen. Där ska algoritmer syntetiseras (utan tidsbeskrivning) till RTL-beskrivningar givet systemets prestandakrav. Dagens högnivåsyntesverktyg arbetar lokalt (block) med lokala prestandakrav. I framtiden bör sådana verktyg syntetisera hela system, eller åtminstone delar av system givet systemprestanda, vilket dock är komplicerat. De ska samtidigt ta hänsyn till prestanda och effekt på systemnivå och avväga beräkning mot kommunikation. Än så länge existerar inte verktyg som kan göra dessa avvägningar.