Sedan EDA-jätten Synopsys köpte FPGA-verktygsspecialisten Synplicity i våras har det varit ganska tunnsått med nyheter på FPGA-fronten från företaget, och på Synopsys hemsida för Synplicity en synnerligen undanskymd tillvaro. Men under ytan har det hänt desto mer om man får tro Gary Meyers, förr chef för Synplicity, idag ansvarig för Synplicity Business Group inom Synopsys.

- Integrationen går mycket bra. Och vi jobbar hårt på att få in asicteknik i FPGA-produkterna, säger Gary Meyers när Elektroniktidningen får en pratstund med honom i samband med konferensen FPGA World i Lund.

Gary Meyers höll inledningsanförandet där, och temat var just hur gränsen suddas ut mellan FPGA- och asickonstruktörer. Han menar att FPGA-konstruktörer har stora behov av asicmetodik - främst fysisk syntes för att lösa timing- och effektproblemen, och verifiering av stora konstruktioner.

- Dagens FPGA:er kan utveckla uppemot 100 W och ha timingfel i klockträdet på uppemot en halv nanosekund - det är mycket i höghastighetskonstruktioner. De problemen härrör bland annat från processvariationer, och de kan bara lösas med fysisk syntes. Konstruktörerna måste veta var på kretsarna olika delar placeras för att timingen och effektfördelningen ska fungera, och här har vi flera verktyg framme för såväl Xilinx som Altera och Actel, säger han.

Därtill menar han att FPGA-konstruktörerna varit bortskämda med lyxen att kunna verifiera sina konstruktioner på ett ganska osofistikerat vis - helt enkelt genom att ladda in koden och kolla om kretsen fungerar på sin plats på kortet. Och modifiera RTL-koden om det inte fungerar som tänkt.

- Men det håller på att förändras. Inte minst eftersom många före detta asickonstruktörer numera gör FPGA:er, och har tagit med sig formell verifiering och annan verifieringsmetodik från asicvärlden, säger han.

Samtidigt kräver dagens asicar och stora FPGA:er som ofta har en eller flera processorkärnor inbyggda att man kommer igång med programvaruutvecklingen snabbt, vilket bäst sker med hjälp av prototyper.

- Vi tittar mycket på möjligheterna att nå samverkan mellan prototypkorten Haps och de virtuella prototyper som Synopsys jobbat med för asicutveckling, säger han.

Han berättar att asickunderna vill börja utveckla programvara så tidigt som möjligt - helst redan på virtuella prototyper, programvarumodeller som visserligen saknar timing men där den logiska funktionen är någorlunda klar. Sedan ska helst samma programvara kunna överföras till den fysiska konstruktionen i Haps-korten för förfining. Helst ska man också kunna använda IP-block från Synopsys bibliotek Designware genom hela denna kedja. Enligt Meyers arbetar flera kunder på det viset idag, trots att verktygsstödet är långt från perfekt.

- Förr var problem hos kretsleverantören den vanligaste orsaken till att ett asicprojekt försenades. Idag är det oftast programvaran - applikationsprogrammen, drivrutinerna och middleware - som orsakar förseningarna, säger han.

När kommer då Synopsys med en produkt för det ändamålet? Gary Meyers vill inte ge något exakt svar på den frågan.

- Inget står för dörren omedelbart, men mycket arbete pågår, säger han.

Han lovordar dock prototypkorten Haps, som ursprungligen utvecklades av Hardi Electronics i Lund som Synplicity köpte i fjol. Visserligen har Hardigrundaren Lars-Eric Lundgren sagt upp sig därifrån, men styrkan i Lund har utökats med ett par utvecklingsingenjörer och Gary Meyers ser fortsatt expansion även det kommande året.

- Efterfrågan på Hapskort har ökat dramatiskt. Och vi har nyligen lanserat Haps-kort med de senaste FPGA-kretsarna och höghastighetskort för Gigabit Ethernet och Sata-stöd. Framöver kommer också Haps-kort med FPGA-kretsar från andra än Xilinx, säger han utan att avslöja vare sig om det handlar om Altera eller Actel eller när dessa kort ska lanseras.

Någon efterfrågan på IP-block i öppen källkod, från exempelvis Opencores som beskrevs i senaste numret av Elektroniktidningen (länk) har han dock inte sett.

- Den som använder IP-block från externa parter vill vara säker på att blocken uppfyller standarder och är certifierade. Med öppen källkod är problemet att man inte har någon att vända sig till när det uppstår bekymmer. Det finns helt klart ett kvalitetsproblem, menar han.