UT ontwerpt functionele programmeertaal die ontwerpkosten chips terugbrengt

ICT-onderzoekers van de Universiteit Twente hebben een functionele programmeertaal ontwikkeld waarmee chip-ontwerpers kunnen bewijzen dat het gedrag van chips door aanpassingen niet verandert. Dit moet het ontwerpproces goedkoper maken.

Een belangrijk onderdeel van het onderzoek van de Universiteit Twente betreft de ontwikkeling van de CλaSH-compiler. Deze compiler zet de functionele taal Haskell, waarvan de eerste versie in 1990 verscheen, om en gebruikt vergelijkbare syntaxis en semantiek. Een functionele taal is te gebruiken om hardware te beschrijven: combinatorische circuits zijn te modelleren als wiskundige functies. CλaSH zet daarbij de beschrijvingen op hoog niveau om naar de hardwarebeschrijvingstaal vhdl op een lager niveau.

"Tijdens het ontwerpproces van nieuwe chips gebruiken fabrikanten al twintig jaar dezelfde technieken. Daarbij moet na elke stap in het ontwerpproces uitvoerig getest worden", volgens de Universiteit Twente. Aanpassingen aan het ontwerp, om chips sneller te maken bijvoorbeeld, kunnen onbedoelde effecten hebben en tot grote problemen leiden.

“Waar je als softwareontwikkelaar een codefout nog kan herstellen door een patch op te sturen, moet je bij een fout in een chip alle producten waar deze chip in verwerkt is, terugroepen”, verklaart promovendus Christiaan Baaij uit. Zo zag Intel zich in 2011 genoodzaakt de productie van Sandy Bridge-chipsets stil te leggen vanwege een ontwerpfout.

Het gebruik van een moderne functionele taal als CλaSH stelt ontwerpers nu in staat formeel te bewijzen dat hardwaretransformaties geen invloed hebben op het gedrag van chips. Voordeel van de methode zou zijn dat het niet meer nodig is om bij elke stap in het ontwerpproces steeds weer alles te verifiëren. De methode brengt de complexiteit en de kosten van chipproductie dan ook terug, aldus de onderzoekers.

Het onderzoek is verricht binnen de vakgroep Computer Architecture for Embedded Systems van onderzoeksinstituut CTIT van de Universiteit Twente. Volgens de Universiteit Twente is er grote interesse uit het bedrijfsleven, maar zijn concerns huiverig over te stappen op functionele talen.

Lees meer

IT-banen

Reacties (32)

Spockz 22 januari 2015 19:44

Dit is een voorbeeld van waarom declaratieve talen zeer geschikt zijn voor het modelleren van real-life systemen. Door een domein specifieke taal (clash in dit geval) te specificeren kun je transformaties los beschrijven en bewijzen. Daarmee kun je dan weer aantonen dat het opeenvolgend uitvoeren van transformaties ook correct is. Als je vervolgens een vertaling van je dsl naar vhdl of een chip hebt heb je een correct functionerende chip.

Haskell is uitermate geschikt voor het definiëren van dergelijke DSLs vanwege de expressiviteit van de taal en het sterke typesysteem.

Verwijderd 22 januari 2015 17:37

Intel heeft genoeg geld, technici in dienst en vast ook contact met universiteiten om zelf een taal te ontwikkelen. Dus waarom is het er nog niet en zitten ze wel te wachten op deze nieuwe moderne functionele taal?

robvanwijk

Wetenschap

@Verwijderd • 22 januari 2015 22:06

Intel heeft genoeg geld, technici in dienst en vast ook contact met universiteiten om zelf een taal te ontwikkelen. Dus waarom is het er nog niet en zitten ze wel te wachten op deze nieuwe moderne functionele taal?

Omdat het een compleet nieuwe (en eerlijk gezegd, radicaal andere) manier is om tegen het probleem aan te kijken.

Zowel VHDL als Verilog zijn, in de basis, geïnspireerd op de syntax van C. Da's handig, want dat kennen veel mensen al... maar het is ook verschrikkelijk onhandig, want programmeren in C en ontwerpen van hardware zijn twee compleet verschillende processen.
Het belangrijkste verschil is dat C regel voor regel door het programma heenloopt en daarbij elke regel op volgorde uitvoert. Als je hardware ontwerpt dan beschrijf je, regel na regel, de waarde van elke output pin (uitgedrukt in input pinnen), maar die nieuwe waarden worden vervolgens, zodra de klok tikt, tegelijk uitgerekend en toegekend.

Een (enigszins suf) voorbeeld:

variabele1 = variabele2;
variabele2 = variabele1;
In C hebben de beide variabelen nu dezelfde waarde.

flipflop1 <= flipflop2;
flipflop2 <= flipflop1;
In Verilog verwisselen de flipflops hun waardes.

swap (x,y) = (y,x)
In Haskell verwisselen de twee elementen van het tuple hun waardes.

In zo'n simpel geval is dat nog wel te overzien, maar bij ingewikkelde (realistische) voorbeeld, blijkt dat C-achtige syntax eigenlijk ongeschikt is voor hardware ontwerp. De UT heeft een vak, "Embedded computer architectures 2", dat hier veel dieper op ingaat:

Learning goals:
(..)
describe mathematical expressions data dependencies and signal from graph in a functional programming (FP) language
synthesize hardware circuits using the FP descriptions
(..)

[Reactie gewijzigd door robvanwijk op 26 juli 2024 20:21]

koenpp @robvanwijk • 23 januari 2015 12:51

> Zowel VHDL als Verilog zijn, in de basis, geïnspireerd op de syntax van C.
Kleine correctie: VHDL is gebaseerd op de programmeertaal ADA.

Zie bijvoorbeeld:
http://en.wikipedia.org/wiki/VHDL en
http://www.sandstrom.org/systemde.htm

Verwijderd @Verwijderd • 22 januari 2015 17:42

Dit is natuurlijk een uitgesproken visitekaartje om bij z'n bedrijf aan de slag te gaan.

[Reactie gewijzigd door Verwijderd op 26 juli 2024 20:21]

RagingPenguin @Verwijderd • 22 januari 2015 17:47

Het was er nog niet omdat nog niemand het eerder had gemaakt.

terradrone

@RagingPenguin • 22 januari 2015 17:54

Hierbij een pluim voor uw scherpzinnigheid

MrEddy @Verwijderd • 22 januari 2015 17:52

Stel je voor dat alle bedrijven met 'genoeg geld en technici' stoppen met luisteren naar de buitenwereld. Dat ze lekker alles zelf maken naar eigen inzicht en zich niets aantrekken van studenten of ontwikkelaars.

IT draait om innovatie, dat snapt Intel maar al te goed. Innovatie komt vooral van studenten en ontwikkelaars, niet van mensen die al 22 jaar op dezelfde manier chips proberen te verkleinen en optimaliseren. De toekomst ligt bij de studenten met passie voor dit vak. Dit prachtige, innoverende, vooruitstrevende en vooral toekomstgerichte vak.

mashell @Verwijderd • 22 januari 2015 17:58

Misschien heeft Intel al wel zoiets. Maar er zijn natuurlijk 100en kleinere chipbakkers (denk aan NXP) die er misschien wel mee geholpen zijn.

[Yellow] @Verwijderd • 22 januari 2015 21:57

Omdat de meeste R&D afdelingen van bedrijven vrijwel uitsluitend de D doen en heel weinig R.
De reden is simpel, Research levert pas op heel lange termijn geld op terwijl Development meteen producten oplevert die verkocht kunnen worden.

De meeste Research wordt nog altijd op universiteiten of door de overheid gesponsorde projecten uitgevoerd.

BCC @Verwijderd • 23 januari 2015 10:52

Toen ik 10 jaar geleden nog op de UT studeerde had de UT ook best goede banden met Intel.

Verwijderd @Verwijderd • 23 januari 2015 16:40

Intel heeft genoeg geld, technici in dienst en vast ook contact met universiteiten om zelf een taal te ontwikkelen. Dus waarom is het er nog niet en zitten ze wel te wachten op deze nieuwe moderne functionele taal?

Erm... Haskell is niet nieuw, het is al zo'n 25 jaar oud.
Wat is er mis met modern? C# is ook modern...
Fuctionele taal is inherent aan chipontwerp, VHDL en Verilog zijn ook functionele talen, maar dat heeft niet iedereen door door het C-achtige uiterlijk.

unglaublich @Verwijderd • 22 januari 2015 17:43

Wat een redenering zeg. Intel heeft zo veel geld dat de hele technologie sector voor altijd uitontwikkeld is. Nieuwe programmeertalen zijn ook absoluut niet meer nodig want we zitten helemaal top nu. Ontwikkelkosten van chips zijn zeker ook nihil en kunnen niet verder verlaagd worden. Volgens mij heb je geen flauw idee waar je het over hebt.

baje @unglaublich • 22 januari 2015 19:03

Zoals het artikel al aangeeft hebben bedrijven wel interesse, maar zijn ze huiverig. Misschien wil ChicaneBT wel weten waarom ze huiverig zijn, ik ben iig benieuwd. Als ze veel tijd kunnen besparen en dus ook kosten zullen ze er vast onderzoek naar doen, lijkt mij.

De reactie had wat subtieler gekunt, maarja die van jou ook.

Frumbasjt @baje • 23 januari 2015 01:04

Ik heb les gehad van iemand van dezelfde afdeling, en hij had het erover dat het gewoon een probleem is van wat bedrijven gewend zijn. Zo'n beetje heel de programmerende wereld is gewend aan imperatief programmeren, zoals in C. Functioneel programmeren is een compleet andere manier van denken, en de stap maken van een imperatieve taal naar een functionele taal is dus niet niks. Dat is waar bedrijven huiverig voor zijn.

Verwijderd 22 januari 2015 20:15

Mooie ideeën, maar het lijkt me heel moeilijk om VHDL (en ABEL) van de troon te stoten.
Ontwikkelomgevingen zoals ActiveHDL hebben allemaal uitgebreide simulatie mogelijkheden. Je moet gigantisch veel tijd steken in een geschikte werkomgeving te maken waar je accuraat en betrouwbaar kan testen. Ook de soorten testmethodes integreren is een hele kunst omdat die bepalen of je projecten die je hebt gemaakt ook daadwerkelijk blijven functioneren na 5 jaar.

Sissors

Chipproductie

@Verwijderd • 22 januari 2015 20:32

Nog afgezien van alle problemen om hardware designers over te krijgen van VHDL/verilog naar een nieuwe taal, vraag ik me af hoe efficient het geheel is. Vooral ook gezien dat de UT een 'enorme besparing' beweerd te kunnen bewerkstelligen.

Om te beginnen zie ik het niet zo vaak gebeuren dat een nieuwe chip gemaakt moet worden die functioneel identiek is, alleen sneller. Er zullen bijna altijd wel wat nieuwe eisen zijn waardoor er toch wat verandert. Maar daarnaast is efficientie van het geheel ook erg belangrijk: Als je stukje code voor PC software 10% trager is dan de concurrent valt het waarschijnlijk niemand uberhaupt op. Bij je chip als die 10% groter is, groeien de per stuk kosten met richting de 10% (oké minder, want je hebt ook test kosten, packaging kosten, etc).

[Reactie gewijzigd door Sissors op 26 juli 2024 20:21]

M0N0 @Sissors • 22 januari 2015 21:04

Er zullen bijna altijd wel wat nieuwe eisen zijn waardoor er toch wat verandert.

Ook hierbij biedt deze DSL echter voordelen: je kan je nieuwe eisen 'naïef' implementeren (met weinig kans op fouten), en nadien CLASH gebruiken om te verifiëren dat je bij het optimaliseren niets wijzigt aan de semantiek.

In software-metafoor:
1) schrijf je programma neer in Ruby
2) zet CLASH 'aan'
3) herschrijf je programma in C (mogelijk met hulp van CLASH)
4) laat CLASH controleren of je C-programma hetzelfde doet als het Ruby-programma (maar dan mogelijk sneller)
5) fix fouten die CLASH gevonden heeft
6) heb een snel maar veilig programma voor een fractie van de gebruikelijke debugging-effort

GENETX @M0N0 • 22 januari 2015 21:10

Clash is geen verificatietool voor code, Clash is een compiler die Haskell code omzet in VHDL. Dit is even kort door de bocht, maar wel de basis. Het voordeel is dat je met Haskell op een veel hoger niveau code klopt en op dat niveau ook makkelijker kan bewijzen dat de code die je schrijft correct is. Daarna zet je het met Clash om in VHDL en daarna door naar een FPGA of ASIC.

Nu heb je eerst een beschrijving, die zet je om in een berg VHDL die je vervolgens lastig kan testen en allerlei testbenches voor moet opzetten. Als je dan een fout ontdekt moet je ook nog eens omslachtig in je VHDL gaan zoeken waar de fout in je code zit, of wellicht al eerder, in je theorie.

[Reactie gewijzigd door GENETX op 26 juli 2024 20:21]

MacD @GENETX • 22 januari 2015 21:26

Diegene waar je op reageert zegt niet dat het zo gebruikt moet worden, maar hij legt een manier voor om het nut/de efficientie van deze nieuwe techniek te bewijzen. Een testcase.

Daarbuiten gok ik dat in de paper daadwerkelijki mathematisch bewijs wordt gepresenteert dat hun techniek doet wat ze beweren. Anders maken ze die claim ook niet.

Geef het een paar maandne voor peer-review en we weten of dit wel/niet veelbelovend is.

GENETX @MacD • 22 januari 2015 21:50

Weet ik, maar ik vind de overeenkomsten zelf ver te zoeken. Je gebruikt Clash namelijk helemaal niet om nadien te verifiëren of je VHDL (gok ik zo in het geval van M0N0) wel klopt. Clash zet je kloppende beschrijving namelijk om naar VHDL. Wat je daarna zelf gaat doen met je VHDL zal je weer op de oude manier moeten checken. Het basisidee is om juist zo laat mogelijk pas over te schakelen naar VHDL.

En verder weet ik al dat Clash veelbelovend is. Het "boekje" staat in mijn boekenkast

[Reactie gewijzigd door GENETX op 26 juli 2024 20:21]

mad_max234 @GENETX • 23 januari 2015 08:58

Toen ik bij Philips(nu NXP) werkte zat ik dagen achter elkaar door microscoop te kijken en controleren of het proces goed was gegaan. Gaat clash daar ook iets voor kunnen betekenen? Dat zou namelijk veel tijd schelen en de productie een stuk goedkoper maken.

Begrijp niet helemaal wat clash nu doet, voorbeeldje als ik een cpu bouw in een fpga wat kan clash dan voor mijn betekenen in het debuggen? Of zit ik nu verkeerd te denken?

GENETX @mad_max234 • 24 januari 2015 11:45

Als je het hebt over debuggen van geproduceerde chips als in kijken of alle transistoren werken etc hebt, dan zit je in de verkeerde richting te denken. In dat hele proces heb je op het moment niks aan Clash.

Clash kan nuttig zijn bij het ontwerpen van de chip door de functionaliteit in Haskell te beschrijven in plaats van in VHDL. Die Haskell code is namelijk makkelijker te controleren dan VHDL om te achterhalen of je code (en dus chip) doet wat je wil dat deze doet. Clash kan dus met name van dienst zijn in het ontwerp proces voor de chip voor het eerst wordt geproduceerd.