När jag var i EDA-branschen som teknolog fanns det tre huvuddelar i min roll. Den första var att berätta för kunderna om ny teknik som utvecklas och verktygstillägg som skulle dyka upp i nästa utgåva. Det här var funktioner som de kan ha nytta av både i de projekt de genomförde idag, och i ännu högre grad, skulle gälla för framtida projekt. För det andra skulle jag försöka ta reda på vilka nya problem de hittade, eller var verktygen inte levererade de funktioner de krävde. Detta skulle ingå i planeringen av verktygsutveckling. Och slutligen skulle jag ta de funktioner som valts ut av marknadsföringsteamet för implementering och försöka komma fram till hur man bäst implementerar dem om det inte var uppenbart för utvecklingsteamen.

Den överlägset svåraste uppgiften av de tre var att få nya krav från kunderna. De flesta ingenjörer har huvudet nere och koncentrerar sig på att få ut sitt senaste chip. När du frågar dem om nya funktioner är det enda de erbjuder deras nuvarande smärtpunkter. Dessa involverar vanligtvis inkrementella funktioner eller buggar, där lösningen ogillas, eller otillräcklig prestanda.

För trettio år sedan, när jag först började göra den rollen, fanns det dedikerade metodgrupper inom de större företagen vars uppgift det var att utveckla flöden och metoder för framtida projekt. Detta verkar vara de perfekta personerna att fråga, men i många fall var de så bortkopplade från utvecklingsteamet att det de bad om aldrig faktiskt skulle användas av utvecklingsteamet. Dessa grupper var idealister som ville ingjuta revolutionära förändringar, medan utvecklingsteamen ville ha evolutionära verktyg. Det längst bort som många av dessa utvecklingar gick var pilotprojekt som aldrig blev mainstream.

Det verkar som om branschen behöver en bättre väg för att få in krav i EDA-företagen. Detta brukade definieras av ITRS, som skulle se framåt och projicera de nya kapaciteter som skulle krävas och tidsramarna för dem. Det finns inte längre. Idag drivs standarder av halvledarföretag. Detta är en förändring från det förflutna, där vi brukade se EDA-företagen driva utvecklingen inom grupper som Accellera. När jag tittar på deras senaste åtaganden är de flesta av dem drivna av slutanvändare.

Att få igång en standardgrupp idag sker ganska sent i processen. Det innebär ett omedelbart behov, men ger inte riktigt tid för lösningar att utvecklas i förväg. Det framgår att det krävs en tankesmedja där branschen kan diskutera frågor och problem för vilka ny verktygsutveckling krävs. Det kan sedan byggas in i EDA:s färdplaner så att tekniken blir tillgänglig när den behövs.

Ett sådant område är effektanalys. Jag har skrivit berättelser om hur viktig kraft och energi blir och kan verkligen snart bli begränsningen för många av de mest komplexa designerna. Några av de frågor jag alltid ställer är:

• Vilka verktyg utvecklas för att göra effektanalys av mjukvara?
• Hur kan man beräkna energiförbrukningen för en given funktion?
• Hur kan användare optimera en design för kraft eller energi?

Jag får sällan raka svar på någon av dessa frågor. Istället får jag ofta vaga idéer om hur en användare skulle kunna göra detta på ett manuellt sätt givet de verktyg som finns tillgängliga för närvarande.

Jag började tro att jag skällde upp i fel träd och det kanske inte var legitima bekymmer. Mitt förstånd återställdes av en kommentar till en av mina senaste maktrelaterade berättelser. Allan Cantle, OCP HPC Sub-Project Leader på Open Compute Project Foundation, skrev: "Även om det är fantastiskt att se artiklar som denna belyser behovet av att vi alla fokuserar på energicentrerad datoranvändning, är den tråkiga nyheten att våra verktyg inte rapporterar energi på något uppenbart sätt för att visa de dumma arkitektoniska misstag vi ofta gör ur ett energiförbrukningsperspektiv. Vi löser alla problem ur ett underifrånperspektiv genom att föra saker närmare varandra. Även om det ger enorma energieffektivitetsfördelar, skapar det också en kraftigt ökande energitäthet. Det finns så mycket lågt hängande frukt från en systemarkitektur uppifrån och ned som branschen saknas eftersom vi måste tänka utanför ramarna och över våra silos.”

Cantle fortsatte med att säga: "En trivial förbättring av verktyg som rapporterar energiförbrukning som ett förstklassigt mått kommer att göra det mycket lättare för oss att förstå och rätta till de misstag vi gör när vi bygger nya energicentrerade, domänspecifika datorer för varje applikation. Alternativt skulle de kiselgudar som styr vår bransch göra klokt i att ta ett steg bakåt och tänka på problemet ur ett systemnivåperspektiv.”

Jag kunde inte hålla med mer, och jag tycker att det är frustrerande att inget EDA-företag verkar lyssna. Jag är säker på att en del av problemet är att de stora kunderna arbetar med sina egna interna lösningar, och de känner att det kommer att ge dem en konkurrensfördel. Tills det står klart att alla deras konkurrenter har liknande lösningar och att de inte längre får någon fördel av det, då kommer de att försöka överföra dessa lösningar till EDA-företagen så att de inte behöver underhålla dem. EDA-företagen kommer då att börja kämpa för att göra den lösning de har skaffat till standard. Det hela tar lång tid.

Som ett partiellt försvar av EDA-företagen står de inför så många nya problem nuförtiden att de är väldigt tunna utspridda och hanterar nya noder, 2.5D, 3D, vänsterskift, multifysik, AI-algoritmer – för att bara nämna några. De spenderar redan mer på FoU än de flesta teknikföretag som andel av intäkterna.

Kanske Accellera skulle kunna börja inkludera diskussionsforum i evenemang som DVCon. Detta skulle möjliggöra en öppen diskussion om de problem de måste ha löst. Kanske kunde de börja producera EDA-motsvarigheten till den gamla ITRS-färdplanen. Det skulle säkert spara mycket tid och energi (ordlek).