Ik heb even gewacht om dit nieuwsbericht te schrijven, want zonder twijfel waren er dingen in terecht gekomen die ik nu liever voor me zelf hou, gewoon omdat het ons toch niks bijbrengt.
Ik denk dat het niet zo moeilijk is om te begrijpen dat we na bijna 6 jaar extreem hard werken onmenselijk halsreikend uitkeken naar de eerste rally met onze auto, die toch stilaan wel een buitenbeentje begint te worden onder de steeds talrijker wordende E30 M3’s.
Ondanks de enorme teleurstelling, kunnen we er niet blijven bij stilstaan en zoals een bekende voetballer ooit zei “elk nadeel heb zen voordeel” …
Dus ondertussen zijn we al terug vol goede moed in actie geschoten en hebben we deze donkere wolken definitief verbannen naar een onbewoond eiland, heel ver hiervandaan.
Het zal ons zeker een paar maand extra kosten maar gelukkig hebben we ook veel dingen geleerd die we sowieso beter gaan doen en wat onze auto nog unieker gaat maken !
Wat is er mis gegaan …
Toen we destijds begonnen zijn met de ontwikkelingen van de TFT controller hebben we ervoor gekozen een eigen interface bord te maken met daarop alle connectiviteit nodig naar de auto toe en om kosten en tijd te sparen dachten we dat het zinvol was een standaard processor module op dit bord te pluggen.
Er zijn tal van deze SOM’s (System on Module) op de markt en iedere zichzelf respecterende silicon fabrikant heeft zo wel iets voorhanden.
Zo ook voor de technologie die wij wilden gebruiken, een module van Emcraft met als kloppend hart een Microsemi Smartfusion 2.
Dit was destijds splinternieuw en we zijn dan ook van start gegaan met de allereerste versie.
Nu weten we uit ervaring ook wel dat het soms uitdagend kan zijn iets te gebruiken met versie nummer 1.0 maar gezien mijn connecties en ervaringen met Microsemi was ik er 1000% van
overtuigd dat het wel goed ging komen.
Versie 1.0 van de Emcraft SOM had een Smartfusion 050 aan boord in een FG896 behuizing. Dit was zelfs Engineering Silicon, zelfs geen productie versie.
Op zich geen probleem, want we zijn er redelijk goed in geslaagd de SOM op ons bord te implementeren en hadden super goede support van zowel het lokale Microsemi team als van de mensen van Emcraft.
Niet geheel onverwacht kwamen er met de regelmaat van de klok dan ook bugs bovendrijven die ons soms behoorlijk wat tijd hebben gekost maar op geen enkel moment zijn we echt onoverkomelijke dingen tegen gekomen. Natuurlijk wisten we ook dat er een versie 2 op komst was met de nodige fixes, dus we zijn nooit beginnen wanhopen.
We waren dan ook al een heel eind op weg met de software alvorens de nieuwe SOM’s beschikbaar kwamen en vanzelfsprekend waren onze 8 prototypes van onze interface kaart al geruime tijd geproduceerd en in test.
Toen we de eerste documentatie kregen van de nieuwe SOM’s merkten we dat men had gekozen om dezelfde chip in een andere behuizing te gebruiken. Nl, de M2S050 van een FG896 naar een FG484. Voor de minder technische mensen onder ons, de oude versie is de middelste op de foto en de nieuwe is de rechtse.
Gezien de SOM maar een beperkt aantal IO’s (ong. 160) naar buiten brengt op 2 HD connectoren (zichtbaar op de foto links zijnde de achterkant van de SOM) zou de verschillende keuze van behuizing geen invloed hebben op de compatibiliteit.
Dus de nieuwe “zouden” 100% pin compatibel zijn !! Voor zover geen vuiltje aan de lucht.
In onze design tool had de wijziging gelukkig ook maar beperkte consequenties. Omdat we geen tijd en zin hadden om alle pinnen terug te herdefiniëren hadden we besloten de pdc file (waar alle physical constraints staan beschreven) manueel aan te passen naar de nieuwe package en gewoon de designflow terug te runnen.
Dat ging zelfs erg vlot en zowel synthesis, compile en P&R zorgden voor weinig of geen problemen.
We hebben dan ook vanaf dat moment alle oude SOM’s verwisseld met de nieuwe versie en zo konden we probleemloos verder ontwikkelen.
Eigenlijk waren we al een tijdje zo goed als klaar, al moest ik nog wel enkele kleine dingetjes oplossen waaronder een vreemd SPI akkefietje.
Omdat dit nooit een blocking issue is geweest hebben we dat niet de volle aandacht gegeven. Omdat ik vorige week de code aan het opkuisen was leek het me de ideale moment om dit op te lossen.
Omdat het aanvankelijk toch iets lastiger was dan gedacht lastig had ik besloten vlug nog een paar testsignalen naar buiten te brengen zodat ik de protocol analyser erop kon loslaten.
Tot mijn extreem grote verbazing heb ik toen gemerkt dat ik de debug signalen niet kon toevoegen op de pinnen die daarvoor voorzien waren.
Libero (de design tool) heeft namelijk een soort automatische design rule check feature wanneer je als gebruiker bv een IO wil koppelen met een niet compatibele voltage standaard dan verhindert de tool dat.
Zo kwam ik er natuurlijk al snel achter dat die uilskuikens geen rekening hebben gehouden met de IO bank verdeling tijdens de re-design van de nieuwe SOM.
In veel van de nieuwere generaties MCU’s/FPGA’s heb je banken IO’s die nog 3V3 compatibel zijn maar ook banken (meestal de snellere IO’s) die max 2V5 of minder aankunnen. Onze olijke vrienden hebben het blijkbaar niet nodig gevonden dit na te kijken met natuurlijk desastreuze gevolgen.
Aanvankelijk dacht ik dat het maar om enkele IO’s ging maar ik ben ze allemaal stuk voor stuk gaan nakijken en het zijn er 10-tallen die van bank zijn verwisseld. Om het even simplistisch in de taal van 1-nen en 0-len uit te drukken betekent dit dat meerdere signalen van ons interface bord wanneer ze tegen de processor willen spreken : ziehier een 1 ( zijnde 3V3 niveau) dat er aan de ingang van deze processor iemand dit 3V3 signaal wel degelijk leest als een 1 (wat volledig correct is) maar dat deze armzalige IO eigenlijk maar gemaakt is om max 2V5 te kunnen verdragen en zodanig gestresseerd geraakt dat de levensverwachting van deze IO aanzienlijk verkort wordt.
Herinnert iemand zich nog 1 van onze meest belangrijkste design specs? Juist betrouwbaarheid !!!
Tot overmaat van ramp zijn de oude versies niet meer te krijgen, enkel de nieuwe SOM’s worden nog geproduceerd.
Conclusie :
- We kunnen alle 8 onze borden richting vuilbak sturen, wat neerkomt op +10K euro in de riool zonder rekening te houden met de ontelbare uren die we er hebben ingestoken.
- We gaan een re-design moeten doen, dus opnieuw schema tekenen, layout maken, PCB’s laten maken inclusief stencil- en filmkosten, nieuwe componenten aankopen, bestukken, testen, … dus wederom zelfde orde groote van extra kost.
- We kijken wederom tegen een 4-6 maand delay
Zo zal je zeker geen SOM module meer terug gaan vinden, we gaan alles zelf op 1 bord zetten zodat we niet meer afhangen van module fabrikanten. Ondertussen zijn er ook weer nieuwe technologieën beschikbaar gekomen en gaan we vooral op communicatie zeer vooruitstrevende dingen toevoegen.
Het was een zeer pijnlijke en kostelijke les, maar de motivatie is enkel toegenomen en we hebben nu terug de mogelijkheid om features waar we initieel niet aan gedacht hebben toe te voegen.
Het zal dus wederom spectaculairder worden en met een beetje geluk zich zelfs niet meer beperken tot enkel de R-Box BMW.
Wordt vervolgt …