Nästa generations utvecklare av programmerbar logik,

En gång i tiden, före logiksyntesåldern, kanske en ingenjör ombads att konstruera ett system som var ren logik. Detta var när vi hade radar men inga microcontrollers, och digital signalprocessning men inga standardiserade digitalsignalprocessorer. Dock hade vi digitalt processad radar.

På den tiden förväntades en nyutexaminerad ingenjör veta hur man designar analog och digital hårdvara och hur man utvecklar mjukvara. Jag fruktar att tiden för den breda, eklektiska ingenjören är förbi och jag oroar mig för framtidens logikkonstruktion. Det finns ett ordspråk som säger att när en snickare bara har en hammare, ser varje problem ut som en spik. Har vi nått en punkt där varje problem ser ut som ett mjukvaruproblem?

Om man söker på internet på orden “FPGA applications” hittar man en lista över applikationer i framkanten av elektroteknikens område. Det finns applikationer från artificiell intelligens och taligenkänning till kommunikation och bildbehandling. Svårigheten med dessa applikationer är att de inte är enkla; de är inte för nybörjare. Inlärningskurvan för att bemästra implementeringen av dessa applikationer är brant och omfattar flera ämnen som är allt annat än triviala.

Man måste lära sig de programmerbara logikenheterna i sig själva, deras integrerade utvecklingsmiljöer (IDE:er, och varje tillverkare har sin egen), nya programmeringsparadigm (dvs. hårdvarubeskrivningsspråk - HDL - och deras hantering av parallellitet och begreppet tid), och man måste förstå själva applikationen. Detta är praktiskt taget oöverstigligt förutom för experter. Det bådar inte gott för att inspirera nästa generations logikkonstruktörer som vill bootstrappa sina förmågor inom programmerbar logik. Det första steget är för högt. Jag tror att detta avskräcker folk från att ta sig an fältet, och minskar därmed antalet människor som med tiden ska bli morgondagens idealister inom programmerbar logik. Många historier på internet härrör från personer som uttrycker frustration med sakernas tillstånd för programmerbar logikkonstruktion, och det finns flera open source-grupper som försöker lösa detta. Många känner att räddningen kommer bli metaprogrammering – en programmeringsteknik i vilken ett program behandlar ett annat program som sin data.

Företag inom programmerbar logik sitter i ett skruvstäd. Å ena sidan, kräver deras investerare att de utvecklar ständigt bättre och dyrare chip, å andra sidan finns det relativt få människor som kan använda dem. Deras lösning är att ombilda mjukvaruutvecklare till hårdvaruutvecklare och de gör detta med nya verktyg.

Kompilerare för högnivåsyntes (HLS) tar konstruktionsabstraktionen till en ännu högre nivå och detta för oss ännu längre bort från rötterna inom logikkonstruktion. Det är ganska fantastiskt att vi kan producera sofistikerade hårdvarukonstruktioner från enbart mjukvarubeskrivningar, men när vi gör detta tappar vi den djupt intuitiva attraktionskraft som logikkonstruktion kan ha på människor. Tro nu inte att jag påstår att en människa kan klå en dator i optimering; jag hävdar bara att det var enklare att konstruera enkla kretsar förr i tiden. Problemet är att enkla kretsar är svårare att konstruera idag än de var förr i tiden.

Jag kommer ihåg min rena förtjusning över att se min handgjorda logiska konstruktion fungera i form av en krets. Det var mina egna färdigheter som minimerade antalet nödvändiga komponenter. När jag lärde mig programmerbar logik på tidigt 1990-tal blev jag ännu mer förtjust över att jag kunde applicera min kunskap om kretskonstruktion till att implementera min logik på en enda enhet med 128 logikelement, och det var mitt intellekt som valde alla dessa logikelement. Jag var inte beroende mentalt av någon okänd algoritmutvecklare.

Konstruktion av logik har utvecklats, och det har även mjukvaruutvecklingen. Det har till stor del blivit en objektorienterad programmeringsvärld (OOP) och bibliotek med vanliga konstruktionsmönster är väldokumenterade och lättillgängliga i kodbibliotek. Min konstruktionsmönsterbok är den en gång populära texten av Erich Gamma et. al., Design Patterns, Elements of Reusable Object-Oriented Software. Jag finner det intressant att hårdvarukonstruktion började som objektorienterad, men att dess utveckling sedan stannade av med introduktionen av HDL. Även om HDL klarar att återanvända konstruktioner, innehåller konstruktionsbiblioteken mest fundamental funktionalitet. Sök på “List of 7400-series integrated circuits” på internet så hittar du några tidiga hårdvarukonstruktionsmönster. Jag finner det intressant att Meilir Page-Jones, i sin bok Fundamentals of Object-Oriented Design in UML, talar om integrerade kretsar som exempel på bra objektkonstruktion – hög sammanhållning och låg interdependens. Men i strävan efter allt mer komplexa programmerbara logikenheter har vi tappat bort våra rötter i den enkla och direkta logikkonstruktionen. Dagens konstruktionsmetodik är beroende av att en datoralgoritm kan implementera vår logik. Jag tänker att detta förhållningssätt utgör ett hinder för nybörjare inom programmerbar logik.

Du kanske ställer frågan “Hur många rader kod var det i det första Pong-spelet vi pluggade in på baksidan av våra tv-apparater?” Svaret är noll. Det var enbart hårdvara (se figur 1) – ingen mjukvara ingick! Jag tror inte det finns många nyutexaminerade ingenjörer som kan konstruera Pong utan att använda mjukvara.  De skulle säga “Varför skulle jag det?” Mitt svar skulle vara “för att få perspektiv och eftersom ni ska veta att det kan göras. Det är enklare än ni tror.”

Figur 1: Pong-schema (Bild: Hittat via Adafruit-bloggen, okänt ursprung)

IEEE publicerade en lista över programmeringsspråk som älskades och hatades av ingenjörer tidigt 2019. De nämnda ingenjörerna älskade Python. Det tror jag på. Jag var domare på en Texas Instruments-konstruktionstävling för flera år sedan och märkte att nio av 10 collegelag använde Python för sina projekt. Varken VHSIC Hardware Description Language (VHDL) och Verilog fanns på älska/hata-listorna. Kanske redaktörerna på IEEE inte betraktar dessa HDL som programmeringsspråk, men jag slår vad om att, vilket är mer troligt, ingen som tillfrågades ens tänkte på HDL. Om det är sant, visar det hur få ingenjörer som tänker på dessa språk, eller logikkonstruktion överhuvudtaget – ett dåligt omen för fältet logikkonstruktion.

Så vad ska vi göra? Hur skapar vi en inställning hos unga ingenjörer att se på ett problem och betrakta dess lösning i termer av mjukvara eller hårdvara? När allt kommer kring, kan de flesta problem lösas på båda sätten. Jag har en idé.

Jag tror att Arduino-plattformen skapade mängder av unga människor som var intresserade av mjukvara. De börjar på skolor för att bli ingenjörer och datavetare. Hur gjorde Arduino detta? Arduino kapade inlärningskurvan för att utveckla mjukvara. Det gjorde mjukvaruutveckling mindre skrämmande.

Genom att definiera ett kort, kunde man undvika att konfigurera linker-kommandofiler, signalnamn blev standard och dess IDE döljer kompileringsdetaljerna. En vacker sak med Python är att det kräver en strikt formatering – indragen måste exempelvis vara enhetliga. Detta eliminerar godtyckliga val av lågt värde med följden att det gör hela utvecklingsprocessen enklare, vilket i sin tur gör utvecklare mer produktiva. Vi behöver en motsvarighet för programmerbar logik och det skulle gagna programmerbar logik-industrin att samarbeta för en standard.

Här är några av attributen som jag förespråkar för den standarden. Precis som Arduino inte har en inherent och robust förmåga att modifiera sin underliggande arkitektur, såsom att acceptera nästlade interrupt, låt oss anta att logikproblem som ska lösas på denna plattform är så pass enkla att dagens programmerbara logikenheter kan uppfylla alla timingrestriktioner. Det Arduino-likvärdiga, programmerbara logikenhetskortet (PLDB), ska ha en tillräckligt långsam klocka för att en godtycklig design med 1 000 logikelement ska fungera. Detta betyder att endast funktionell verifiering krävs av plattformen.

Eftersom alla älskar Python, föreslår jag att PLDB:et kompletteras med Python och bygger på ett ramverk som nMigen eller MyHDL (se figur 2), eller t.o.m. Yosys med sitt RTLIL. Detta skulle göra det möjligt för nybörjare att simulera sina logikkonstruktioner med ett tolkat språk, producera sanningsvärdetabeller och komma åt alla andra Python-bibliotek som finns tillgängliga. På tal om Pythons bibliotek: med hjälp av Python är det även möjligt för communityn att använda Python package index (PyPI) för att distribuera återanvändbara hårdvarublock som hjälper till att hantera bristen på robusta, delade konstruktionsmönster. nMigen stödjer, precis som Python, metaprogrammering, så även om detta ramverk stödjer enkla konstruktioner, är plattformen skalbar för att stödja komplexa konstruktioner.

Figur 2: Python-baserat ramverk (Bildkällor: MyHDL.org och m-labs.hk)

Gränssnittet från en värd-PC till ett PLDB ska vara USB tillsammans med en PLDB-inbäddad microcontroller med ett API som värd-PC:n använder för att känna av PLDB-konfigurationen så att den kan autokonfigurera Python-miljön för programmerbar logik-utveckling. Resultatet av denna konfiguration ska vara att dölja detaljer om syntes, plats och rutt samt programmering, samtidigt som det underlättar funktionell simulering på PC och körning på faktisk hårdvara.

För att inte vissa läsare ska tro att det inte längre finns enkla logikproblem att lösa, visar jag en del statistik över Digi-Keys försäljning av microcontrollers. Figur 3 visar fördelningen av klasser av microcontrollers som kunder köper och figur 4 visar hur många enheter av varje klass som säljs. Sammanlagt har DigiKey över 80 000 microcontroller-artikelnummer och lagerför över 19 000 microcontrollers redo för omedelbar leverans till hela världen. Siffrorna visar att enkla 8-bitars processorer används av fler ingenjörer och att DigiKey levererar fler 8-bitars microcontrollers än någon annan processorklass. Detta visar att det finns fler enkla problem än komplexa.

Figur 3: Andel DigiKey-kunder som köper varje typ av microcontroller (bildkällor: DigiKey)

Figur 4: Antal sålda enheter av varje typ av microcontroller från DigiKey (Bildkällor: DigiKey)

Vårt mål borde vara att få alla, även de utan formell utbildning i logikkonstruktion, att bli entusiaster för programmerbar logik; men vi måste byta utvecklingsparadigm för att göra detta.