Päätöskehikko toimintojen jakamiseen FPGA-logiikan ja sulautetun ohjelmiston välillä niin, että rajapinnat, verifiointi ja toimitusriskit pysyvät näkyvissä.
Käsittele laitteistoa ja ohjelmistoa yhtenä järjestelmänä
FPGA-pohjaisessa tuotteessa ratkaisevin arkkitehtuuripäätös ei usein ole prosessori tai työkaluketju vaan se, missä kukin toiminto suoritetaan. Ohjelmoitavaan logiikkaan sijoitettu toiminto voi saada deterministisen rinnakkaisuuden ja pienen viiveen, mutta sen muuttaminen ja verifiointi on kalliimpaa. Ohjelmistossa sama toiminto voi olla helpompi päivittää ja havainnoida, mutta ajoitus-, läpäisy- tai tehoraja voi ylittyä.
Laitteiston ja ohjelmiston yhteissuunnittelu tekee rajasta tietoisen päätöksen myöhäisen luovutuksen sijaan. Tiimit arvioivat koko järjestelmän käyttäytymistä, jakavat toiminnot yhteisillä kriteereillä ja verifioivat rajapinnan osana tuotetta. Tämä korostuu, kun sulautettu C tai C++, Python-työkalut ja VHDL tai muu laitteiston kuvauskieli kehittyvät rinnakkain.
Asiakkaan saama tulos on kokonaisuus, joka täyttää rajoitteet ilman että kaikki vaativat toiminnot viedään automaattisesti laitteistoon tai kaikki muutettava ohjelmistoon. Jaon pitää perustua mittauksiin, kirjattuihin oletuksiin ja mahdollisuuteen muuttaa ratkaisua epävarmuuden aikana.
Nimeä järjestelmätason omistaja, joka ratkaisee osa-alueiden väliset ristiriidat. Erilliset työjonot ja toimittajat ovat tavallisia, mutta suorituskyky ja luotettavuus kuuluvat yhteiselle tuotteelle. Jaettu omistajuus estää paikallista optimointia siirtämästä kustannusta tai riskiä huomaamatta rajan toiselle puolelle.
Pidä raja liikuteltavana varhaisen oppimisen aikana. Käytä vaihdettavia rajapintoja, testikaksoisia ja mittauspisteitä, jotta toiminto voidaan siirtää uuden näytön muuttaessa vaihtoehtoja. Jaon lukitseminen ennen edustavia kuormia, laiterajoja ja päivitystarpeita muuttaa varhaisen arvion kalliiksi uudelleentyöksi. Arkkitehtuurikatselmuksen pitää hyväksyä sekä nykyinen ratkaisu että avoimien oletusten varmennussuunnitelma, vastuuhenkilöt ja määräpäivät. Varaa aikatauluun myös päätöksen muuttaminen: oppiminen ei vähennä riskiä, jos suunnitelma ei salli reagoida tulokseen. Kirjaa, mikä näyttö oikeuttaa rajamuutoksen ja kuka hyväksyy sen vaikutukset.
Mittaa rajoitteet ennen toimintojen jakamista
Sanat nopea, reaaliaikainen ja tehokas eivät ole arkkitehtuurivaatimuksia. Muuta ne budjeteiksi: suurin päästä päähän -viive, jatkuva ja hetkellinen läpäisy, sallittu ajoitusvaihtelu, logiikka- ja muistiresurssit, prosessorikuorma, tehoraja, käynnistysaika sekä hyväksyttävä virhetaajuus. Lisää tarvittaessa ympäristö- ja turvallisuusrajat.
Mittaa koko polku, älä vain yksittäistä algoritmia. Siirrot prosessorin ja FPGA:n välillä kuluttavat aikaa, kaistaa ja puskureita. Keskeytyskäsittely, välimuisti, DMA:n käynnistys ja datamuotojen muunnos voivat poistaa näennäisen kiihdytyshyödyn. Edustava kuorma ja yhteinen mittaustapa tekevät vertailusta rehellisen.
Kirjaa epävarmuus budjetteihin. Tyypillinen, pahin ja heikentynyt tila ovat eri suunnittelusyötteitä. Jos mittauslaitteistoa tai lopullista piiriä ei vielä ole, merkitse arviot ja anna niille varmennuspäivä. Merkitsemätön arvio muuttuu helposti pysyväksi vaatimukseksi tai kuvitteelliseksi marginaaliksi.
Erota ehdottomat rajat mieltymyksistä. Säätösilmukan määräaika voi olla tinkimätön, kun taas tietty valmistajakirjasto voi olla vain tuttu. Erottelu antaa tiimille tilaa tutkia vaihtoehtoja heikentämättä tuotevaatimusta.
- Viive ja ajoitusvaihtelu järjestelmän rajalla, ei vain komponentin sisällä.
- Läpäisy edustavissa kuormapiikeissä ja vastapaineessa.
- Logiikan, muistin, prosessorin, lämmön ja tehon budjetit.
- Päivitystiheys, tuotteen odotettu elinkaari ja kenttähuollon polku.
- Turvallisuuden, tietoturvan, diagnostiikan ja palautumisen vaatimukset.
Arvioi jokainen toiminto samoilla kysymyksillä
Toimintoja pitää verrata muullakin kuin raakanopeudella. FPGA-logiikka sopii vakaaseen, rinnakkaiseen, bittitason tai syvästi liukuhihnoitettuun työhön, jolla on tiukka ajoitus. Ohjelmisto sopii monimutkaiseen ohjaukseen, usein muuttuvaan toimintaan, laajoihin kirjastoihin sekä ominaisuuksiin, jotka hyötyvät suoraviivaisesta lokituksesta ja kenttäpäivityksistä. Moni ratkaisu on hybridi: laitteisto hoitaa ennakoitavan datapolun ja ohjelmisto politiikan sekä orkestroinnin.
Lisää pisteytykseen elinkaarikustannus. Kysy, miten toimintoa diagnosoidaan oikeassa laitteessa, miten virhe korjataan, mitä osaamista tarvitaan viiden vuoden kuluttua ja miten työkalujen tai komponenttien vanheneminen vaikuttaa ylläpitoon. Pieni suorituskykyhyöty ei aina oikeuta erikoistunutta verifiointi- ja julkaisupolkua. Toisaalta jatkuva prosessorin kasvattaminen voi olla rajattua kiihdytintä kalliimpaa.
Kirjaa hylätty vaihtoehto ja päätöksen näyttö. Näin sama keskustelu ei käynnisty alusta, ja ratkaisua voidaan muuttaa järkevästi kuormien tai laitevalintojen muuttuessa.
Suunnittele laitteisto-ohjelmistoraja tuoterajapintana
Rekisterit, muistialueet, viestimuodot, keskeytykset ja ajoitussäännöt muodostavat sopimuksen. Anna sille versio, omistaja ja suoritettavat tarkistukset. Määritä tavujärjestys, kohdistus, arvovälit, nollausarvot, virhetilat, aikakatkaisut sekä kummankin puolen uudelleenkäynnistyminen. Epäselvyys rajalla tuottaa vaikeasti toistettavia vikoja, koska kumpikin tiimi näkee vain osan tilasta.
Tuota mahdollisuuksien mukaan ohjelmiston otsikkotiedostot, dokumentaatio ja testimallit yhdestä määrittelystä. Tarjoa simulointi- tai emulointipolku, jotta ohjelmistotyö voi edetä ennen lopullista laitteistoa. Suunnittele havainnointi mukaan: laskurit, jäljityspisteet, terveystiedot ja ymmärrettävät virhekoodit vähentävät laboratorio- ja kenttätyötä.
Määritä yhteensopivuus tietoisesti. Päätä, voiko ohjelmisto toimia usean bitstream-version kanssa, miten kyvykkyydet tunnistetaan ja mitkä yhdistelmät ovat tuettuja. Vaarallinen yhdistelmä hylätään näkyvästi käynnistyksessä sen sijaan, että hienovarainen ristiriita pääsee tuotantoajoon.
Tietoturva kuuluu samaan sopimukseen. Määritä epäluotettavat syötteet, päivitysten todentaminen, debug-pääsyn hallinta ja virheellisen datan rajaaminen. Teknisesti toimivasta datapolusta voi silti tulla tuoteriski, jos palautumis- ja käyttöoikeussäännöt lisätään vasta integraatiossa.
Verifioi osat erikseen ja käyttäytyminen yhdessä
Ohjelmiston yksikkötestit ja logiikan simulaatiot ovat välttämättömiä mutta eivät riitä. Suurimmat riskit löytyvät usein osien välisestä järjestyksestä, ajoituksesta ja palautumisesta. Rakenna verifiointiportaat: puhtaat mallit, RTL-simulaatio, ohjelmisto virtuaalirajaa vasten, yhteissimulaatio, hardware-in-the-loop ja edustava kohdelaite. Jokainen taso vastaa eri kysymykseen.
Jäljitä jokainen kriittinen vaatimus testiin ja säilytä testisyötteet versioituina aineistoina. Mukaan kuuluvat ylikuorma, kello- tai tiedonsiirtohäiriö, osittainen päivitys, virheellinen data ja uudelleenkäynnistys. Nimeä vastuuhenkilö rajan ylittävien vikojen selvitykseen, jotta ne eivät siirry tiimiltä toiselle. Järjestelmän havaitusta käyttäytymisestä lähtevä vikakieli on hyödyllisempi kuin varhainen syyllisen etsiminen.
Toimitus on valmis, kun käännös on toistettava, bitstream- ja ohjelmistoversiot liittyvät toisiinsa, julkaisun näyttö voidaan tuottaa uudelleen ja kenttälaite kertoo käyttämänsä versiot. Pitkässä elinkaaressa nämä hallintakeinot ovat yhtä tärkeitä kuin ensimmäinen toimiva ominaisuus.
Harjoittele päivityksen epäonnistuminen ja palautuminen ennen julkaisua. Varmista toiminta sähkökatkossa, osittaisessa ohjelmoinnissa ja yhteensopimattoman paketin tilanteessa. Vain laboratorion ohjeessa oleva palautuminen ei vielä ole luotettava kenttäkyvykkyys. Vastuu, tarvittavat välineet ja palautumisen aikaraja kuuluvat hyväksyntään.
Jakopäätöksen tarkistuslista arkkitehtuurikatselmukseen
Käy lista läpi jokaiselle merkittävälle rajalle, ei vain kerran koko laitteelle. Jos näyttö puuttuu, rahoita kohdennettu mittaus tai prototyyppi ennen arkkitehtuurin lukitsemista. Tarkoitus on poistaa kallein epävarmuus silloin, kun muutos on vielä edullinen.
- Onko järjestelmärajat mitattu edustavilla kuormilla?
- Sisältääkö vertailu siirron ja puskuroinnin kustannukset?
- Onko toiminto riittävän vakaa laitteistototeutukseen?
- Onko rajapinnan merkitys, ajoitus, nollaus ja virhetoiminta versioitu?
- Voiko ohjelmistotyö edetä ennen lopullista laitteistoa?
- Kattavatko yhteistestit ylikuorman, virheellisen syötteen ja palautumisen?
- Ovatko käännökset toistettavia ja ohjelmisto- sekä bitstream-versiot yhdistetty?
- Onko ylläpitopolku realistinen tuotteen elinkaarelle ja saatavilla olevalle osaamiselle?