Eric_Leenman

Eric Leenman is senior interim-professional bij Yacht Embedded Systems.

9 May 2012

Onlangs moest ik voor een klant FPGA-code ontwikkelen op een onderdeel waar ik niet zo veel ervaring mee heb. Ik heb toen onderzocht of het inzetten van intellectual property (IP) een oplossing kon bieden. Eerst keek ik of de IP in essentie het probleem oplost en daarna of die toepasbaar is in het product – een core die te veel DSP-blokken van de FPGA gebruikt, heeft geen zin. De taal waarin de IP is geschreven, is ook van belang. Zelf ben ik beter thuis in C dan Java. Verilog is ook geschikt voor FPGA‘s, maar VHDL heeft mijn voorkeur. Als ik wijzigingen wil doorvoeren, is het wel handig als ik de taal begrijp.

Op IP-gebied is er veel te krijgen, zowel open- als closed-source. Een groot voordeel van open source is dat er geen kosten aan zijn verbonden. Verilog- en VHDL-code is gratis beschikbaar op bijvoorbeeld de site van Opencores. Status en kwaliteit van de code worden aangegeven door middel van lemma‘s zoals ’specification done‘, ’FPGA-proven‘ of ’Opencores-certified‘. Support wordt geleverd via de community.

Mooi systeem. Je downloadt de code, leest de documentatie en komt er dan globaal achter wat de core doet. De aanpassing die ik wilde doen, was klein, maar na het bestuderen van de IP-code bleek dat toch iets complexer te zijn. Aangezien het project onder druk stond, was afhankelijk zijn van communitysupport een te groot risico. Wachten op een antwoord op het forum paste niet in de planning.

Daarom onderzocht ik wat de mogelijkheden waren met closed-source IP van de FPGA-leverancier. Op het bijbehorende ontwikkelbord bleek de core goed te werken. Documentatie en voorbeeldprojecten hielpen om snel op gang te komen. Na deze eerste stappen moest er dieper in de code van de IP worden gedoken, en dan merk je dat de pijn en kennis in de details zitten.

Support is dan erg belangrijk. Die van de FPGA-leverancier liep via een IT-ticketsysteem. Je kunt je vraag per e-mail stellen en dan pakt een supportengineer deze op. Telefonisch contact of on-site ondersteuning is niet mogelijk. Maar via e-mail je probleem duidelijk maken, is lastig. Het is een proces waar je geduld voor moet hebben en uitgebreid en gedetailleerd moet antwoorden met behulp van plaatjes, referenties naar handleidingen, code en snapshots. En dan nog moet je elkaars e-mails juist interpreteren.

Vervolgens geprobeerd om de code om te zetten naar het bord in ontwikkeling. Bij het integreren van het stuk IP met bestaande code liep ik ineens tegen problemen aan zoals shared PLL‘s, beschikbare Ram-blokken en andere resources. Als de DDR3-controller een PLL gebruikt die de core ook nodig heeft om zijn 20 bit video over de LVDS-lanes te kunnen sturen, en de FPGA-tooling het dus niet kan routen, heb je alsnog een probleem. Dan lost de IP je probleem functioneel wel op, maar krijg je er een ander voor terug; DDR3-geheugens verleggen op je PCB is ook geen sinecure. De tijdwinst door een core te gebruiken, heb je dan alweer verspeeld. Door kleine codewijzigingen door te voeren en een grotere FPGA in dezelfde familie en hetzelfde package te kiezen, kon de schade beperkt blijven.

Mijn ervaring laat zien dat de keuze voor open- of closed-source IP sterk afhankelijk is van de situatie, het project, de planning en de bedrijfsvisie. In sommige gevallen kan een IP-blok een goede start zijn om een probleem in de basis op te lossen. Maar gedegen product- en vakkennis zijn noodzakelijk om de gekozen core te kunnen gebruiken en te integreren in je eigen product. IP is geen black box die je probleem als puzzelstukje even oplost. Je moet er tijd in steken om te kunnen beoordelen of de code goed te integreren is in het product. Essentieel daarbij is support op die IP. 

Als senior ontwikkelaar heb ik kennis en ervaring opgebouwd waardoor ik makkelijker de overweging kan maken welke oplossing het beste past. Overigens noemt mijn werkgever mij ook IP. Het staat zelfs op mijn visitekaartje: interim-professional. Een IP die IP bouwt.