Generatyvinis DI keičia dalį įterptinių sistemų kūrimo — bet ne lemiamą dalį. Kas pasislinko, kas išryškėjo, ir ką gaunate kaip užsakovas.
Generatyvinis DI šiandien gali kurti standartines tvarkykles, paprastus būsenos automatus ir boilerplate kodą kalbomis SystemVerilog, VHDL, C arba Python. Tai realu, naudinga ir sumažino tam tikrų rutininių užduočių darbo apimtį.
Iš to kyla pagrįstas klausimas: ką dar suteikia patyręs įterptinių sistemų ir FPGA kūrėjas šioje aplinkoje?
Atsakymas yra konkretus.
DI yra greitas vykdytojas. Jis gamina tai, kas jam pavedama — ne tai, kas reikalinga. Paprašyti DI «parašyk man UART tvarkyklę» duoda UART tvarkyklę. Bet ne tą, kuri iš tikrųjų veikia su šiuo laikrodžio domenu, šiuo kontaktų priskyrimu, šiuo laiko elgesiu ir šiuo klaidų apdorojimu tikslinėje aplinkoje.
Tikrasis inžinerinis darbas nėra kodo generavimas. Tai tikslios specifikacijos rašymas: kas tiksliai turi įvykti, kokiomis sąlygomis, kokiomis tolerancijomis, kokiu elgesiu klaidos atveju, kokiame temperatūros diapazone, per kokį tarnavimo laiką.
Geresnis DI šiame nieko nekeičia. Priešingai: kuo galingesni tampa įrankiai, tuo lemiamiau jiems teisingai nurodyti.
DI nepapildo reikalavimų, apie kuriuos užsakovas nepagalvojo. Jis neišgalvoja ypatingų atvejų. Jis pristato tiksliai tai, kas yra specifikacijoje — ir nieko daugiau. Kas nėra specifikuota, trūksta rezultate.
Taip rizika visiškai persikelia į pačią specifikaciją. Nepatyrusi specifikacija teisingai aprašo tai, ko klientas paprašė, ir praleidžia visa, ko sudarytojas niekada nepatyrė: retą sensoriaus gedimą tam tikrais temperatūros gradientais, elgesį vienalaikio brown-out ir I²C magistralės blokavimo metu, watchdog reset flash rašymo sekos metu, elektromagnetinį susiejimą ilguose sensorių kabeliuose, elgesį pakartotinio paleidimo metu po netyčinio reset kritinės rašymo operacijos metu.
Tokie taškai nėra kliento reikalavimai. Tai reikalavimai, kuriuos patyręs kūrėjas pridėjo, žinodamas, kad kitaip jų niekur nebūtų. Todėl specifikacija visada yra ir rizikų katalogas — o jo gylis proporcingas jį sudarančiojo patirčiai.
Atliekant infuzinio aparato saugos tyrimą, į kurį mane pakvietė medicinos prietaisų gamintojas, pasireiškė saugumui svarbus gedimas, kuris atsirado iš dviejų pavienių klaidų vienalaikio atsiradimo: atminties mikroschemos aparatūrinio gedimo ir klaidingos tikrinimo procedūros būtent šiai mikroschemai. Kiekviena klaida atskirai buvo valdoma. Tik kombinacija sukėlė neaptiktą klaidos būseną.
Būtent ši kombinacinė analizė turi būti aktyviai įtraukta į specifikaciją. Iš reikalavimo «patikrink atmintį» įrankis sugeneruoja tikrinimo procedūrą. Iš patirties išplaukia papildomas reikalavimas, kad ir pati tikrinimo procedūra negali sukelti tylios klaidos būsenos. Joks įrankis šio antro reikalavimo savaime nesuformuluoja.
Prie to prisideda aparatūrai artimi spąstai, kurie nėra duomenų lapuose, o tų kūrėjų galvose, kurie jau kartą turėjo juos vytis:
Daugumai užduočių yra keletas sprendimų, kurie iš esmės veikia. Bet tik nedaugelis iš jų atitinka saugumo, patikimumo ir tarnavimo laiko reikalavimus, kurių reikia konkrečiam produktui.
DI sistema renkasi tai, kas jos mokymo duomenyse buvo dažna. Patyręs kūrėjas renkasi tai, kas saugumui svarbioje sistemoje neveda į katastrofą. Šis pasirinkimo sprendimas nėra įgyvendinimo detalė. Tai tikrasis inžinerija.
Žalos atveju įstatymdavys reikalauja įrodymo, kad produktas pateikimo į rinką metu atitiko technikos lygį. Tai pagrindinė sąlyga, kad gamintojas galėtų išsiginti iš atsakomybės už produktą. Su nauja Europos Direktyva dėl atsakomybės už produktą su trūkumais ir iš jos kilusiu nacionaliniu perkėlimo įstatymu šios įrodymo naštos aiškiai sugriežtinama programinei įrangai ir su programine įranga integruotiems produktams.
Technikos lygis nėra statinė būsena. Tai yra tai, kas tarp specialistų laikoma įprastu — ir šiuo metu keičiasi pagreitėjusiu tempu, nes nauji įrankiai ir metodai trumpais ciklais didina rinkos standartą.
Iš to seka: tas, kuris šiandien kuria įterptinę sistemą, turi žinoti ir taikyti šiuo metu galingesnius metodus. Kas to nedaro, savo užsakovui sukuria konkretų atsakomybės pavojų. Tai būtent reikalauja kūrėjo, kuris valdo tiek nusistovėjusius, tiek naujus įrankius ir gali padaryti teisingą pasirinkimą.
Naudoju DI įrankius ten, kur jie matuojamai taupo laiką, nesukurdami rizikų: pirmas boilerplate juodraštis, testbench generavimas, dokumentacija, skaitomumo patikra.
Nenaudoju jų kaip pakaitalo šiems:
Rezultatas: mažiau darbo rutininiam darbui, pastoviai aukšta kokybė užduotyse, kurios iš tikrųjų neša projektą, ir dokumentuotas kūrimo procesas, atitinkantis dabartinį technikos lygį.
Užsakote kūrėją su daugiau kaip 35 metų patirtimi FPGA ir įterptinėse, kuris žino dabartinius įrankius ir gali įvertinti jų ribas. Negaunate nei «DI sugeneruoto projekto», nei «DI nepriklausomo projekto». Gaunate veikiančią sistemą, už kurią konkretus asmuo prisiima atsakomybę — ir kuri žalos atveju gali būti įrodyta kaip sukurta pagal technikos lygį.
Jei turite įterptinį projektą, kuriam reikia būtent tokio gylio, pakalbėkime apie tai tiesiogiai. Pirmas pokalbis ir grubus įvertinimas yra nemokami ir neįpareigojantys.