Avaleht

Inseneritöö ja TI sardistutud arendamises

Generatiivne TI muudab osa sardistutud arendamisest — kuid mitte otsustavat osa. Mis on nihkunud, mis on teravnenud, ja mida saate tellijana.

Lähtekoht

Generatiivne TI suudab täna toota standardseid draivereid, lihtsaid olekuautomaate ja boilerplate koodi keeltes SystemVerilog, VHDL, C või Python. See on tõeline, kasulik ja vähendanud teatud rutiinsete ülesannete vaeva.

Sellest tõuseb õigustatud küsimus: mida toob kogenud sardistutud ja FPGA arendaja selles keskkonnas veel?

Vastus on konkreetne.

Spetsifikatsioon on tegelik ülesanne

TI on kiire täideviija. Ta toodab seda, mis talle määratakse — mitte seda, mis on vajalik. TI-lt küsida «kirjuta mulle UART draiver» annab UART draiveri. Aga mitte selle, mis tegelikult töötab selle kellaala, selle pinöörimise, selle ajastuskäitumise ja selle veakäsitsemisega sihtkeskkonnas.

Tegelik insenerikunst ei ole koodi genereerimine. See on täpse spetsifikatsiooni kirjutamine: mis täpselt peab toimuma, milliste tingimuste juures, milliste tolerantsidega, millise käitumisega vea korral, millises temperatuurivahemikus, millise eluea jooksul.

Parem TI ei muuda seda. Vastupidi: mida võimsamaks muutuvad tööriistad, seda otsustavamaks muutub neid õigesti juhendada.

Kogemusest sündinud spetsifikatsioon välistab lõksud

TI ei lisa nõudeid, millele tellija ei mõelnud. Ta ei leiuta erijuhtumeid. Ta tarnib täpselt selle, mis on spetsifikatsioonis — ja mitte midagi enamat. Mis pole spetsifitseeritud, puudub tulemuses.

Sellega kandub risk täielikult spetsifikatsioonile endale. Kogenematu spetsifikatsioon kirjeldab korrektselt seda, mida klient palus, ja jätab tähelepanuta kõik, mida koostaja pole kunagi kogenud: harva esinev anduritõrge teatud temperatuurigradientide juures, käitumine üheaegse brown-out'i ja I²C-siini lukustuse korral, watchdog reset flash-kirjutuse järjestuse ajal, elektromagnetiline ühendamine pikkadel anduri kaablitel, käitumine taaskäivitusel pärast soovimatut resetti kriitilise kirjutusoperatsiooni ajal.

Sellised punktid pole kliendi nõuded. Need on nõuded, mille kogenud arendaja lisab, teades, et muidu need pole kuskil. Spetsifikatsioon on seetõttu alati ka riskikataloog — ja selle sügavus on võrdeline koostaja kogemusega.

Praktikast

Infusioonseadme

Infusioonseadme ohutusuuringus, mille juurde meditsiinitehnika tootja mind kutsus, ilmnes ohutuse seisukohast oluline rike, mis tekkis kahe üksikvea üheaegsest esinemisest: mälukivi riistvaratõrge ja just selle kivi vigane kontrollirutiin. Iga viga eraldi oli hallatav. Alles kombinatsioon tekitas tuvastamata veaseisundi.

Just see kombinatsioonianalüüs tuleb spetsifikatsioonis aktiivselt lisada. Nõudest «kontrolli mälu» genereerib tööriist kontrollirutiini. Kogemusest järeldub täiendav nõue, et ka kontrollirutiini enda tõrge ei tohi viia vaikse veaseisundini. Ükski tööriist ei sõnasta seda teist nõuet iseseisvalt.

Sellele lisanduvad riistvarale lähedased lõksud, mida pole andmelehtedes, vaid arendajate peades, kes on neid juba kord taga ajanud:

  • Et teatav carry-chain primitiiv triivib temperatuuri ja toitepingega ja ilma kalibreerimiseta ei taga stabiilset eraldusvõimet.
  • Et QSPI siin muutub 50 MHz juures ebastabiilseks, kui maandus pole tähekujuline.
  • Et FreeRTOS muteks ja semafor lahendavad mõlemad ressursiprobleemi, kuid ainult üks neist väldib prioriteedi inversiooni.
Ohutuskriitiliste funktsioonide puhul pole see kvalitatiivne lihvimine. See on vahe «töötab» ja «töötab ka siis, kui see, mis ei tohi juhtuda, ikkagi juhtub» vahel.

Ohutu tee valimine paljude seast

Enamiku ülesannete jaoks on mitu lahendust, mis põhimõtteliselt töötavad. Kuid ainult vähesed neist täidavad ohutus-, töökindlus- ja eluiganõudeid, mida konkreetne toode vajab.

TI süsteem valib selle, mis tema treeningandmetes oli sage. Kogenud arendaja valib selle, mis ohutuse seisukohast olulises süsteemis ei vii katastroofini. See valikuotsus pole rakendusdetail. See on tegelik insenerikunst.

Tehnika tase õigusliku mõõdupuuna

Kahjujuhtumi korral nõuab seadusandja tõendit, et toode turule laskmise ajal vastas tehnika tasemele. See on keskne tingimus, et tootja saaks ennast tootevastutusest välja vaielda. Uue Euroopa tootevastutuse direktiiviga ja sellest tuleneva siseriikliku ülevõtmisseadusega seda tõendamiskoormust selgesõnaliselt teravdatakse tarkvara ja tarkvaraga integreeritud toodete osas.

Tehnika tase pole staatiline seisund. See on see, mida ekspertide seas peetakse tavaliseks — ja muutub praegu kiirenenud, kuna uued tööriistad ja meetodid lühikeste tsüklite jooksul tõstavad turustandardit.

Sellest järeldub: kes täna arendab sardistutud süsteemi, peab tundma ja kasutama praegu võimsamaid meetodeid. Kes seda ei tee, loob oma tellijale konkreetse vastutuseriski. See eeldab täpselt arendajat, kes valdab nii väljakujunenud kui ka uusi tööriistu ja oskab teha õige valiku.

Kuidas töötan

Kasutan TI tööriistu seal, kus need säästavad mõõdetavalt aega riske loomata: boilerplate'i esimene visand, testbench'ide genereerimine, dokumentatsioon, loetavuse kontroll.

Ei kasuta neid asendusena järgmisele:

  • Arhitektuurilised otsused
  • Spetsifikatsioon rakenduskogemusest
  • Valik lahendusteede vahel ohutuse ja töökindluse vaatenurkadest
  • Ajastusanalüüs päris riistvaral
  • Valminud süsteemi verifitseerimine spetsifikatsiooni vastu

Tulemus: vähem vaeva rutiinitööle, püsivalt kõrge kvaliteet ülesannetes, mis projekti tegelikult kannavad, ja dokumenteeritud arendusprotsess, mis vastab praegusele tehnika tasemele.

Mida saate tellijana

Tellite arendaja, kellel on üle 35-aastane kogemus FPGA-s ja sardistutus, kes tunneb praeguseid tööriistu ja oskab nende piire hinnata. Te ei saa ei «TI-genereeritud projekti» ega «TI-vaba projekti». Saate töötava süsteemi, mille eest konkreetne isik võtab vastutuse — ja mille kahjujuhtumi korral saab tõendada, et see on arendatud tehnika taseme kohaselt.

Kui teil on sardistutud projekt, mis nõuab just sellist sügavust, räägime sellest otse. Esimene vestlus ja jämedahinnang on tasuta ja kohustuseta.

Värviskeem

Keel