Neste generasjon av programmerbar logikk-utvikler

En gang i tiden, før tidsalderen til logiske synteser, kunne en konstruktør ha blitt bedt om å konstruere et system som var ren logikk. Dette var da vi hadde radar, men ingen mikrostyringer eller digital signalbehandling. Før digitale signalprosessorer var «hyllevare». Likevel hadde vi radar som var digitalt behandlet.

Da var det forventet at en nyutdannet konstruktør ville vite hvordan han skulle konstruere analog og digital maskinvare, samt hvordan utvikle programvare. Jeg frykter at tiden for den «brede» elektroingeniøren er forbi, samt jeg bekymrer meg for fremtiden til logisk konstruksjon. Det er et ordtak som sier at når en snekker kun har en hammer, ser alle problemer ut som en spiker. Har vi nådd det punktet der alle problemer ser ut som et programvareproblem?

Hvis du søker på internett ved å bruke ordene «FPGA-applikasjoner» (FPGA applications), finner du en liste over applikasjoner i forkant av elektroteknikk. Det finnes applikasjoner som spenner fra kunstig intelligens og talegjenkjenning til kommunikasjon og bildebehandling. Problemet med disse applikasjonene er at de ikke er enkle; de er ikke for nybegynnere. Læringskurven for å mestre implementeringen av disse applikasjonene er bratt og inkluderer flere ikke-trivielle temaer.

Man må lære seg programmerbare logiske enheter selv, deres integrerte utviklingsmiljøer (IDE-er; og hver produsent har sine egne), nye programmeringsmønstre (paradigmer) (dvs. maskinvarebeskrivelsesspråk – HDL – og deres tilpasning til samtidighet og tidsbegrepet), og man må forstå selve applikasjonen. Disse er praktisk talt uoverkommelige for andre enn eksperter. Dette gir ikke noe god måte å inspirere den neste generasjonen konstruktører av logikk, som ønsker å starte opp sine logiske programmeringsferdigheter. Det første trinnet er for høyt. Jeg tror dette hindrer folk i å komme inn i feltet. dermed reduseres menneskene som til slutt ønsker bli morgendagens ivrige logikkprogrammerere. Mange historier er på internett av folk som uttrykker frustrasjon over den nåværende tilstanden til konstruksjon av programmerbar logikk, det er flere open source-samfunn som prøver å løse dette. Mange mennesker føler at frelse vil komme gjennom metaprogrammering – en programmeringsteknikk der et program behandler et annet program som sine data.

Programmerbare logikkselskaper er i en klype. På den ene siden krever investorene deres at de utvikler stadig mer dyktige og dyre brikker (chips), på den andre siden er det relativt færre som kan bruke dem. Løsningen deres er å konvertere programvareutviklere til maskinvarekonstruktører, og de gjør dette med nye verktøy.

HLS-kompilatorer (high level synthesis) på høyt nivå tar generell konstruksjon til et enda høyere nivå, og dette tar oss enda lenger fra røttene til logisk konstruksjon. Det er ganske oppsiktsvekkende at vi kan produsere sofistikert maskinvarekonstruksjon fra rene programvarebeskrivelser, men det gjøres, mangler den fysiske tiltalenheten logisk konstruksjon kan ha på mennesker. Du vil aldri høre meg med å argumentere for at en person kan «optimalisere» en datamaskin, men jeg påstår at det var enklere å konstruere enkle kretsløp før i tiden. Problemet er at enkle kretsløp er vanskeligere å konstruere i dag enn de var tidligere.

Jeg husker min egen, store glede å se min selvlagede logiske konstruksjon fungere i form av en krets. Det var min dyktighet som minimerte antallet nødvendige enheter. Da jeg lærte programmerbar logikk på begynnelsen av 1990-tallet, var jeg enda gladere for at jeg kunne bruke kunnskapen min om kretskonstruksjon for å implementere min egen logikk. Dette var en enkelt enhet med 128 logiske elementer, det var intellektet mitt som valgte hvert eneste av disse logiske elementene. Jeg var ikke avhengig av intellektet til en ukjent algoritmeutvikler.

Mens logisk konstruksjon utviklet seg, gjorde også programvareutviklingen det. Det har i stor grad blitt en objektorientert programmeringsverden (object-oriented programming – OOP) verden og biblioteker med ofte funnet konstruksjonsmønstre er godt dokumentert og lett tilgjengelig i kodebiblioteker. Min konstruksjonsmønsterbok er den en gang populære teksten av Erich Gamma, et. al., Konstruksjonsmønstre, elementer av gjenbrukbar objektorientert programvare (Design Patterns, Elements of Reusable Object-Oriented Software). Jeg synes det er interessant at maskinvarekonstruksjon startet som objektorientert, men utviklingen stoppet med introduksjonen av HDL-er. Selv om HDL-ene er tilpasset gjenbruk av konstruksjon, inneholder designbibliotek mest grunnleggende funksjonalitet. Søk på "Liste over 7400-serien integrerte kretsløp" på internett, og du kan finne noen tidlige mønstre for maskinvarekonstruksjon. Jeg syntes det var interessant at Meilir Page-Jones i boken hans, Grunnleggende om objektorientert (design)-utforming i UML (Fundamentals of Object-Oriented Design in UML), refererer til integrerte kretsløp som eksempler på god objektutforming – høy bindekraft og lav kobling. Men i jakten på stadig mer komplekse programmerbare logiske enheter, har vi mistet røttene våre til enkel og direkte logisk konstruksjon. Dagens konstruksjonsmetoder er avhengige av en datamaskinalgoritme for å implementere logikken vår. Jeg tror denne tilnærmingen gjør en barrière for programmerbare logiske nybegynnere.

Du kan spørre: «Hvor mange kodelinjer var det i det første Pong-spillet som vi koblet til baksiden av TV-apparatene våre?» Svaret er null. Det var ren maskinvare (se figur 1) – ingen programvare inkludert! Jeg tror ikke det er mange nyutdannede ingeniører som kunne konstruert Pong uten å bruke programvare. De sa: «Hvorfor skulle jeg gjøre det?» Mitt svar vil være «for perspektiv, og fordi du burde vite at det kan gjøres. Det er enklere enn du tror.»

Figur 1: Pong-skjema (Bilde: Funnet via Adafruit-blogg, ukjent opprinnelse)

IEEE publiserte en liste over programmeringsspråk som ingeniører elsket og hatet tidlig i 2019. IEEE sa at ingeniører elsker Python. Jeg tror det. Jeg var dommer på en av Texas Instruments designkonkurranser for flere år siden og fikk vite at ni av de ti college-teamene brukte Python til utformingsprosjektene sine. VHSIC Hardware Description Language (VHDL) og Verilog var ikke på listene, hverken på elsket- eller hatet-listene. Kanskje redaktørene på IEEE ikke vurderer disse HDL-programmeringsspråkene, men mer sannsynlig: jeg vedder på at de som ble kartlagt, ikke engang betraktet HDL-er. Hvis det er sant, forteller dette til hvor få konstruktører som har disse språkene, eller logisk konstruksjon i tankene i det hele tatt, – et dårlig tegn på feltet for logisk konstruksjon.

Så, hva gjør vi? Hvordan gjør vi det slik at tankegangen hos nye ingeniører vil se på det som et problem og vurdere løsning med programvare eller maskinvare? Tross alt kan de fleste problemer løses uansett. Jeg har en idé.

jeg tror Arduino-plattformen har gjort mange unge interessert i programvare. De kommer inn på skoler for å bli ingeniører og informatikere. Hvordan gikk dette til? Arduino reduserte læringskurven for å utvikle programvare. Arduino gjorde programvareutvikling mindre skremmende.

Ved å definere et kort, klarte man å eliminere å sette opp linker-kommandofiler, signalnavn ble standard, og IDE-en skjulte kompileringnsdetaljer. Noe av det vakre ved Python, er at det krever streng formatering – innrykk må for eksempel være ensartede. Dette eliminerer lavverdige, vilkårlige valg med effekten av å gjøre hele utviklingsprosessen enklere, noe som igjen gjør utviklere mer produktive. Vi trenger tilsvarende for programmerbar logikk, det vil være nødvendig for at den programmerbare logikkindustrien skal samarbeide om en standard.

Her er noen av egenskapene som jeg forfekter for den standarden. På samme måte som Arduino ikke har en iboende og robust evne til å endre den underliggende arkitekturen, for eksempel ved å imøtekomme nestede avbrytelser, la oss anta at logikkproblemene som skal løses på denne plattformen er enkle nok til at dagens programmerbare logiske enheter kan møte alle tidsbestemmelser. Arduino-ekvivalenten, programmerbar logisk enhetskort (programmable logic device board – PLDB), bør ha en tilstrekkelig langsom klokke til at hvilken som helst 1000-elements logiske konstruksjon skal fungere. Dette betyr at bare funksjonell verifisering er påkrevd av plattformen.

Siden alle elsker Python, foreslår jeg at PLDB støttes med Python og bygger på et rammeverk som nMigen eller MyHDL (se figur 2), eller til og med Yosys med sin RTLIL. Dette vil gi nybegynnere mulighet til å simulere sin logiske konstruksjon med et tolket språk, produsere sannhetstabeller og få tilgang til ethvert annet Python-bibliotek som er tilgjengelig for dem. Når vi snakker om Pythons bibliotek og bruker Python, kan også samfunnet bruke Python-pakkeindeksen (PyPI) til å distribuere gjenbrukbare maskinvareblokker som hjelper til med å løse mangelen på robuste, delte utformingsmønstre. nMigen, som Python, støtter metaprogrammering, selv om dette rammeverket vil støtte enkle utforminger, er plattformen skalerbar for å støtte komplekse utforminger.

Figur 2: Python-basert rammeverk (Bildekilder: MyHDL.org og m-labs.hk)

Grensesnittet fra en verts-PC til en PLDB skal være USB sammen med en PLDB-innebygd mikrostyring med en API for verts-PC-en til bruk for å lære om PLDB-konfigurasjonen, slik at den kan konfigurere Python-miljøet automatisk for programmerbar logikkutvikling. Resultatet av dette oppsettet skal være å skjule syntesens detaljer, sted, rute og programmering, samtidig som det er tilrettelagt for funksjonell simulering på PC, samt eksekvering på faktisk maskinvare.

Om noen lesere tror det ikke lenger er enkle logiske problemer å løse, viser jeg statistikk over DigiKey sitt salg av mikrostyringer. Figur 3 viser fordelingen av klasser av mikrokontrollere som kundene kjøper, og figur 4 viser hvor mange enheter i hver klasse som selges. I alt viser DigiKey over 80 000 mikrostyringer delenummer og har over 19 000 mikrokontrollere på lager, klar for umiddelbar forsendelse til hvor som helst i verden. Tallene viser at enkle 8-bits prosessorer brukes av flere konstruktører og at DigiKey sender flere 8-bit mikrokontrollere enn noen annen type prosessor. Dette forteller meg at det er mer enkle problemer enn komplekse.

Figur 3: Antall DigiKey-kunder som kjøper hver type mikrostyringer (Bildekilde: DigiKey)

Figur 4: Antall solgte enheter for hver type mikrostyringer fra DigiKey (Bildekilde: DigiKey)

Vårt mål bør være å gjøre hvem som helst, også de uten formell utdanning innen logisk konstruksjon, til programmerbare og logiske entusiaster; men vi må endre utviklingsstandardene (paradigmene) for å gjøre det.