Microsemi In-Circuit FPGA -virheenkorjaus
Tuotetiedot
Tekniset tiedot
- Laitetyyppi: Microsemi SmartFusion2 SoC FPGA
- Julkaisupäivä: toukokuu 2014
- Virheenkorjausominaisuudet: In-Circuit FPGA -virheenkorjaus, sulautettu logiikka-analysaattori
- Suurin tiedonsiirtotaajuus: Jopa 100 MHz
Abstrakti
FPGA:t ovat tehokkaita suunnitteluelementtejä sulautetuissa järjestelmissä, joissa on monia suunnittelun etujatagmutta näillä laitteilla voi olla monimutkaisia rakenteita ja monimutkaisia suunnitteluongelmia, jotka on korjattava. Suunnitteluongelmien, kuten määrittelyvirheiden, järjestelmän vuorovaikutusongelmien ja järjestelmän ajoitusvirheiden, jäljittäminen voi olla haaste. Piirin sisäisten virheenkorjaustoimintojen sisällyttäminen FPGA:han voi parantaa huomattavasti laitteiston virheenkorjausta ja välttää tuntikausien turhautumisen. Tässä artikkelissa kuvataan useita erilaisia lähestymistapoja FPGA:iden piirin sisäiseen virheenkorjaukseen, tunnistetaan tärkeimmät kompromissit ja esim.ampLe design, joka on suunnattu Microsemi SmartFusion®2 SoC FPGA -laitteelle, näyttää kuinka uusia ominaisuuksia voidaan käyttää nopeuttamaan virheenkorjausta ja testausta.
Johdanto
FPGA:t ovat kaikkialle leviäviä ja tehokkaita suunnitteluelementtejä, ja niitä löytyy nykyään lähes kaikista sulautetuista järjestelmistä. Kapasiteetin kasvaessa, monimutkaisten sirujen toiminnallisten lohkojen ja kehittyneiden sarjaliitäntöjen mukaan näissä laitteissa voi olla myös monimutkaisia suunnitteluongelmia, jotka on korjattava. Ongelmien, kuten funktionaalisten määrittelyvirheiden (FPGA- tai järjestelmätasolla), toiminnallisten järjestelmän vuorovaikutusongelmien, järjestelmän ajoitusongelmien ja IC:ien välisten signaalin tarkkuusongelmien (kuten kohina, ylikuuluminen tai heijastukset) jäljittämisestä tulee paljon monimutkaisempaa, kun käytetään edistyneitä FPGA:ita. Simulaatiosta on varmasti suuri apu monien suunnitteluongelmien tunnistamisessa, mutta monet todellisen maailman vuorovaikutukset eivät näy ennen kuin suunnittelu on toteutettu laitteistossa. Prosessin yksinkertaistamiseksi on kehitetty useita erilaisia tekniikoita monimutkaisten suunnitteluongelmien virheenkorjaukseen. Jokaisen näistä keskeisistä tekniikoista, mukaan lukien erilaiset advan, huolellinen ymmärtäminentagja haittojatages on hyödyllinen pohdittaessa, mikä tekniikka tai tekniikoiden yhdistelmä sopii tiettyyn malliin.
ExampMicrosemi SmartFusion2 SoC FPGA -laitteelle suunnattua FPGA-suunnittelua voidaan käyttää esittelemään joitakin etuja.tagja haittojatagnäiden vakiotekniikoiden sekä uusimpien piirin sisäisten viankorjausominaisuuksien avulla. Tämä havainnollinen esimample näyttää, kuinka näitä erilaisia tekniikoita voidaan käyttää nopeuttamaan laitteisto-ongelmien tunnistamista ja poistamista laitteiston virheenkorjauksen aikana.
Miksi FPGA-virheenkorjaus on kriittinen osa järjestelmän suunnittelua ja kehitystä?
FPGA:lla on kaksi pääkäyttömallia, jotka erottavat ne muista suunnitteluelementeistä. FPGA:ita voidaan käyttää tuotantotuotteessa tai niitä voidaan käyttää kehitysvälineenä tuotannon suunnittelukonseptin todistamiseen tai prototyyppiin. Tuotantovälineenä käytettynä FPGA:t voivat olla paljon joustavampi kohde kuin ASIC- tai CPU-pohjaiset tuotantoajoneuvot. Tämä on erityisen tärkeää uudelle suunnittelulle, jota ei ole vielä toteutettu laitteistossa. Suunnitelmia erilaisilla arkkitehtonisilla vaihtoehdoilla voidaan helposti luoda ja testata, jotta optimaalinen suunnittelu löydetään. FPGA:t, joissa on on-chip-prosessorit (SoC FPGA:t), mahdollistavat myös prosessoripohjaisen käsittelyn vaihtamisen laitteistoavusteisten FPGA-pohjaisten kiihdytystoimintojen kanssa. Nämä Advantagse voi dramaattisesti lyhentää uusien tuotekehitysten suunnitteluun, validointiin, testaukseen ja vikaanalyyseihin kuluvaa aikaa.
FPGA-joustavuus on keskeinen etu, kun sitä käytetään prototyyppien suunnitteluun, ehkä tuotanto-ASIC:iin. Varsinainen laitteistoalusta, jopa sellainen, joka ei toimi täydellä nopeudella, tekee yksityiskohtaisten järjestelmän suorituskykymittareiden, suorituskyvyn analyysitietojen ja arkkitehtuurin konseptitulosten hankkimisesta paljon helpompaa. FPGA-tuki alan standardiväylän (kuten PCIe®, Gigabit Ethernet, XAUI, USB, CAN ja muut) kovetetuille toteutuksille yksinkertaistaa näihin liitäntöihin liittyvää testausta. Uusimmat FPGA-perheet, joissa on on-chip ARM-prosessorit (SoC FPGA:t), tekevät sulautetuilla prosessoreilla varustettujen toteutusten prototyyppien tekemisestä helppoa. Aiemmin kehitetty prosessorikoodi voidaan siirtää prototyyppiin ja luoda uusi koodi rinnakkain laitteiston suunnittelun kanssa.
Tämä vakioprosessorin yhdistelmä vakioliitäntäväylillä mahdollistaa käytettävissä olevien koodikirjastojen, ohjainten, toiminnallisten API:iden, reaaliaikaisten käyttöjärjestelmien ja jopa täydellisten käyttöjärjestelmien laajan ekosysteemin hyödyntämisen toimivan prototyypin luomiseksi paljon nopeammin. Lisäksi, kun malli on vakiintunut, FPGA-prototyyppiä voidaan käyttää kaapata laajoja simulaatiotestisarjoja (sekä ärsykkeelle että vasteelle), jotka kuvastavat todellisia järjestelmätietoja. Nämä tietojoukot voivat olla korvaamattomia luotaessa lopullisia simulaatioita ASIC- tai muulle tuotantototeutukselle. AdvantagFPGA:n käyttäminen suunnittelun prototyyppinä voi lyhentää merkittävästi suunnitteluun, validointiin, testaukseen ja virheanalyysiin kuluvaa aikaa lopullisen tuotteen toteutuksessa.
Molemmissa näissä yleisissä FPGA-käyttömalleissa FPGA:n joustavuus suunnittelukohteena on tärkeä etu.tage. Tämä tarkoittaa, että monet suunnittelumuutokset ja iteraatiot olisivat normaaleja, ja näin ollen kyky korjata suunnitteluvirheet nopeasti olisi ratkaisevan tärkeää mahdollisimman monen suunnitteluvaihtoehdon mahdollistamiseksi. Ilman tehokasta virheenkorjausominaisuutta suuri osa AdvanistatagFPGA-suunnittelun joustavuus vähenee vaaditun lisävirheenkorjausajan vuoksi. Onneksi FPGA:t voivat tarjota myös lisälaitteita, jotka yksinkertaistavat dramaattisesti reaaliaikaista virheenkorjausta. Ennen kuin tarkastelemme näitä ominaisuuksia, katsotaanpa ensin yleisimmät ongelmatyypit, joita FPGA-suunnittelu saattaa kohdata, jotta meillä on oikea tausta arvioida erilaisten virheenkorjaustyökalujen tehokkuutta ja niihin liittyviä kompromisseja.
Yleisiä ongelmia FPGA-mallien virheenkorjauksessa
Nykyaikaisten FPGA-laitteiden tuomien laajennettujen ominaisuuksien lisäksi siihen liittyvä lisääntynyt monimutkaisuus vaikeuttaa virheettömän suunnittelun luomista. Itse asiassa on arvioitu, että virheenkorjaus voi viedä yli 50 % sulautetun järjestelmän suunnittelusyklistä. Kun markkinoilletulopaineet jatkavat kehityssyklin puristamista, alkuperäisen järjestelmän laitteiston virheenkorjaus jää jälkikäteen – aivan liian usein olettaen, että todentaminen (itse suuri prosenttiosuustage kehitysaikataulusta), havaitsee kaikki virheet ennen järjestelmän ensimmäistä käyttöönottoa. Katsotaanpa vain muutamia yleisiä järjestelmäongelmia ymmärtääksemme paremmin haasteita, joita tyypillinen suunnittelu kohtaa järjestelmän käyttöönoton aikana.
Toiminnallisia määrittelyvirheitä voi olla kaksinkertaisesti vaikea löytää, koska suunnittelija on ymmärtänyt tietyn vaatimuksen väärin, joten virhe voidaan jättää huomiotta, vaikka tarkastelee tarkasti suunnittelun yksityiskohtia. ExampYleisen funktionaalisen määrittelyvirheen le on se, että tilakoneen siirtymä ei päädy oikeaan tilaan. Virheet voivat myös näkyä järjestelmän käyttöliittymissä vuorovaikutusongelmana. Käyttöliittymän latenssi, esimample, saattaa olla määritetty väärin, mikä johtaa odottamattomaan puskurin yli- tai alivuototilaan.
Järjestelmätason ajoitusongelmat ovat toinen hyvin yleinen suunnitteluvirheiden lähde. Etenkin asynkroniset tapahtumat ovat yleinen virheiden lähde, kun synkronoinnin tai ajoitusalueen vaikutuksia ei harkita huolellisesti. Nopeudella toimittaessa tämäntyyppiset virheet voivat olla erittäin ongelmallisia ja voivat ilmaantua hyvin harvoin, ehkä vain silloin, kun tietyt datamallit ilmenevät. Monet yleiset ajoitusrikkomukset kuuluvat tähän luokkaan, ja niitä on yleensä erittäin vaikea, ellei mahdoton simuloida.
Ajoitusrikkomukset voivat myös johtua alhaisesta signaalin tarkkuudesta integroitujen piirien välillä, erityisesti järjestelmissä, joissa jokaiselle piirille on useita tehokiskoja. Alhainen signaalin tarkkuus voi aiheuttaa signaalikohinaa, ylikuulumista, heijastuksia, liiallista kuormitusta ja sähkömagneettisia häiriöitä (EMI), jotka usein näkyvät ajoitusvirheinä. Virtalähdeongelmat, kuten transientit (erityisesti järjestelmän käynnistyksen tai sammutuksen aikana), kuormituksen vaihtelut ja suuret tehohäviöjännitteet voivat myös johtaa mystisiin virheisiin, joita ei useinkaan ole helppo jäljittää virtalähteeseen. Vaikka suunnittelu on täysin oikea, levyn valmistusongelmat voivat johtaa virheisiin. Vialliset juotosliitokset ja väärin kiinnitetyt liittimet, esimample, voi olla virheiden lähde ja se voi jopa riippua lämpötilasta tai kortin sijainnista. Kehittyneiden FPGA-pakkaustekniikoiden käyttö voi vaikeuttaa painetun piirilevyn signaalien tutkimista, joten pelkkä pääsy haluttuun signaaliin voi usein olla ongelmallista. Usein monet suunnitteluongelmat eivät aiheuta välitöntä virhettä, ja niiden on heijastuttava suunnittelun läpi, kunnes virhe todella ilmenee. Aloitusvirheen jäljittäminen perimmäiseen syyyn voi usein olla turhauttavaa, vaikeaa ja aikaa vievää tehtävää.
esimample, yksittäinen bitti väärin käännöstaulukossa saattaa aiheuttaa virheen vasta monta jaksoa myöhemmin. Jotkin työkalut, joista keskustelemme myöhemmin tässä artikkelissa ja jotka käyttävät piirin sisäistä virheenkorjauslaitteistoa, on erityisesti tarkoitettu nopeuttamaan ja helpottamaan näitä "vianetsintä". Ennen kuin perehdymme näiden työkalujen yksityiskohtiin, katsotaanpa ensin suosittu ohjelmistopohjainen virheenkorjaustekniikkasimulaatio, jotta ymmärrämme paremmintagja haittojatagsimuloinnin käyttäminen virheenkorjaukseen.
Simuloinnin käyttö virheenkorjaukseen
Tyypillisesti suunnittelusimulaatiossa kaikki tosielämän komponentit suunnittelun sisällä ja ulkopuolella mallinnetaan matemaattisesti ohjelmistoprosesseiksi, jotka suoritetaan peräkkäin tavallisella CPU:lla. Erilaisten ärsykkeiden käyttäminen suunnitteluun ja odotetun tuoton vertaaminen simuloidun suunnittelun tuottoon on helppo tapa havaita ilmeisimpiä suunnitteluvirheitä. Ikkuna, joka esittää tyypillistä simulointiajoa, on esitetty alla olevassa kuvassa 1. Selkeä etutagYksi simulaatiosäkeistä laitteistopohjaisesta virheenkorjauksesta on se, että simulointi voidaan tehdä ohjelmistossa – varsinaista laitteistopohjaista suunnittelua ja testipenkkiä ei tarvita. Simulointi voi nopeasti havaita monia suunnitteluvirheitä, erityisesti virheitä, jotka liittyvät vääriin määrityksiin, liitäntävaatimusten väärinymmärrykseen, toimintovirheisiin ja moniin muihin "karkeisiin" virhetyyppeihin, jotka havaitaan helposti yksinkertaisten ärsykevektorien avulla.
Simulointi on erityisen tehokasta, kun suunnittelijan käytettävissä on laajat ärsykeyhdistelmät ja tuloksena saadut tulokset ovat hyvin tiedossa. Näissä tapauksissa simulointi voi tehdä suunnittelun lähes täydellisen testin. Valitettavasti useimmilla malleilla ei ole helppoa pääsyä laajoihin testisarjoihin, ja niiden luominen voi olla hyvin aikaa vievää. Suunnittelusta 100 % kattavan testipaketin luominen on käytännössä mahdotonta suurille FPGA-pohjaisille malleille, ja suunnittelun avainelementtien kattamiseen on käytettävä oikoteitä. Toinen simulaation vaikeus on, että se ei ole "todellisen maailman" toteutus, eikä se pysty havaitsemaan asynkronisia tapahtumia, nopeita järjestelmän vuorovaikutuksia tai ajoitusrikkomuksia. Lopuksi simulointiprosessi voi olla hyvin hidas ja jos tarvitaan useita iteraatioita, simuloinnista tulee nopeasti kehitysprosessin aikaa vievin ja usein kallein osa.
Vaihtoehtona (tai ehkä paremmin sanottuna, lisäyksenä simulaatioon) FPGA-suunnittelijat havaitsivat, että he voisivat lisätä FPGA-suunnitteluun virheenkorjauslaitteistoa laitteen sisällä olevien avainsignaalien tarkkailemiseksi ja ohjaamiseksi. Nämä tekniikat kehitettiin alun perin ad-hoc-lähestymistapoina, mutta niistä on vähitellen kehittynyt standardi laitteiston virheenkorjausstrategia. Tämä piirin sisäisten virheenkorjausominaisuuksien käyttö tarjoaa merkittävää edistystätages FPGA-pohjaisille malleille ja seuraavassa osiossa tarkastellaan kolmea yleisintä strategiaa ja niiden erilaisia etujatagja haittojatages.
Yleiset In-Circuit -virheenkorjausmenetelmät FPGA:ille
Yleisimmät tekniikat piirin sisäisten virheenkorjaustoimintojen toteuttamiseksi FPGA:ssa käyttävät joko sulautettua logiikkaanalysaattoria, ulkoista testilaitteistoa tai FPGA-kangasrakenteeseen upotettua erillistä signaalianturilaitteistoa. Sulautettu logiikka-analysaattori toteutetaan tyypillisesti FPGA-kankaalla ja se liitetään suunnitteluun. JTAG porttia käytetään analysaattoriin pääsyyn ja kaapatut tiedot voidaan näyttää PC:llä. Kun käytetään ulkoista testauslaitteistoa, testattavaa FPGA-rakennetta muutetaan siten, että valitut sisäiset FPGA-signaalit reititetään lähtönastoihin. Nämä nastat voidaan sitten tarkkailla ulkoisten testilaitteiden kautta. Kun käytetään erillistä signaalianturilaitteistoa, laaja valikoima sisäisiä signaaleja voidaan lukea reaaliajassa. Joitakin koetintoteutuksia voidaan käyttää jopa kirjoittamiseen rekisteriin tai muistipaikkoihin, mikä parantaa entisestään virheenkorjausominaisuuksia. Katsotaanpa tarkemmin Advaniatagja haittojatagjokaisen näistä tekniikoista ja katso sitten exampsuunnittelemaan, kuinka nämä erilaiset lähestymistavat voivat vaikuttaa virheenkorjausaikaan.
In-Circuit FPGA Debug-embedded Logic Analyzer
Sulautetun logiikka-analysaattorin konsepti oli suora seuraus ad-hoc-piirin sisäisestä virheenkorjausominaisuuksista, joita suunnittelijat ottivat käyttöön, kun FPGA:ita käytettiin ensimmäisen kerran. Sulautetut logiikka-analysaattorit lisäsivät uusia ominaisuuksia ja poistivat suunnittelijan tarpeen kehittää oma analysaattori. Useimmat FPGA:t tarjoavat nämä ominaisuudet, ja kolmannet osapuolet tarjoavat standardianalysaattoreita (Identify®, Synopsys, on yksi suosittu esim.ample), jotka voivat helposti liittää korkeamman tason työkaluihin tuottavuuden parantamiseksi entisestään.
Logiikka-analysaattorin toiminnallisuus on sisällytetty suunnitteluun käyttämällä FPGA-kudosta ja sulautettuja muistilohkoja jäljityspuskureina, kuten kuvassa 2 on esitetty. Liipaisuresursseja luodaan myös siten, että monimutkaiset signaalivuorovaikutukset voidaan valita ja siepata helposti. Analysaattoriin pääsy ohjausta ja tiedonsiirtoa varten tapahtuu tyypillisesti standardin J kauttaTAG portti rajapintavaatimusten yksinkertaistamiseksi. Kaapatut tiedot voidaan näyttää PC:llä käyttämällä yhteistä viewohjelmiston ja tyypillisesti peilaa logiikkasimulaattorin aaltomuotolähtöä viewtyyliin.
AdvantagTässä lähestymistavassa ei käytetä ylimääräisiä FPGA I/O -nastoja, vain vakio JTAG signaaleja. Sulautetut logiikka-analysaattorin IP-ytimet ovat yleensä suhteellisen edullisia, ja joissain tapauksissa ne voivat olla vaihtoehto olemassa oleville FPGA-synteesi- tai simulointityökaluille. Joissakin tapauksissa sulautettu logiikka-analysaattori voi myös tarjota lisälähtöjä käyttämättömille I/O:ille, jos se on kätevämpää. Yksi huonoistatagTämä lähestymistapa on se, että tarvitaan suuri määrä FPGA-resursseja. Erityisesti, jos käytetään jäljityspuskureita, tämä vähentää käytettävissä olevien lohkomuistien määrää. Jos tarvitaan laaja puskuri, tämä on myös kompromissi muistin syvyyttä vastaan (koska laajemman muistin käyttö johtaa pienempään muistin syvyyteen) - suuri haittatage käytettäessä pienempiä laitteita. Ehkä tämän tekniikan suurin haittapuoli on se, että joka kerta, kun anturin sijoitusta muutetaan, suunnittelu on käännettävä uudelleen ja ohjelmoitava uudelleen. Suuria laitteita käytettäessä tämä prosessi voi viedä huomattavasti aikaa. Johtuen tavasta, jolla signaalianturit on sijoitettu suunnitteluun, voi olla vaikeaa korreloida signaalin ajoitussuhteita. Lisäksi signaalikoettimien väliset viiveet eivät ole johdonmukaisia ja siten ajoitussuhteita on vaikea verrata. Tämä on erityinen vaikeus verrattaessa asynkronisia signaaleja tai signaaleja eri aikaalueilta.
In-Circuit FPGA -virheenkorjaus – ulkoinen testauslaitteisto
Piirin sisäisen virheenkorjauskoodin käyttö ulkoisten testilaitteiden kanssa oli luonnollista kehitystä, kun ulkoinen logiikka-analysaattori oli jo saatavilla järjestelmän testaukseen. Luomalla yksinkertaista virheenkorjauskoodia sisäisten testisignaalien tunnistamiseksi ja valitsemiseksi ja niiden soveltamiseksi FPGA I/O:ihin, kuten kuvassa 3 on esitetty, oli mahdollista hyödyntää analysaattoreiden edistyneitä ominaisuuksia (kuten suuria jäljityspuskureita, monimutkaisia laukaisusarjoja ja useita viewvaihtoehtoja) luodaksesi yksinkertaisia mutta tehokkaita virheenkorjausympäristöjä. Monimutkaisemmat piirin sisäiset ominaisuudet edistyneille laukaisuvaihtoehdoille voivat minimoida tarvittavien lähtöjen määrän. esimampTiettyjen osoitteiden valitseminen leveällä väylällä saattaa olla kohtuutonta, jos ulkoisia nastaja tarvitaan.
Sisäisen FPGA-logiikan käyttö vähentää merkittävästi I/O-vaatimuksia ja voi jopa etsiä tiettyjä osoitekuvioita (ehkä kutsu- ja paluusekvenssiä) monimutkaisempien ongelmien vianmääritykseen. Jos käytettävissä on yhteinen käyttöliittymä, tämä voi yksinkertaistaa oppimiskäyrää ja parantaa tuottavuutta.
AdvantagTämän lähestymistavan päätekijänä on se, että se hyödyntää ulkoisen testauslaitteiston kustannuksia, joten työkalukustannuksia ei lisätä. Joitakin virheenkorjauspiirin IP-ytimiä on saatavana laitevalmistajilta tai FPGA-valmistajilta, ja ne voivat olla erittäin edullisia tai jopa ilmaisia. Signaalinvalintalogiikan toteuttamiseen tarvittavien FPGA-resurssien määrä on hyvin pieni, ja koska jäljitystoiminto tehdään ulkoisen logiikka-analysaattorin avulla, lohkomuisteja ei tarvita. Koska valintalogiikka on edullinen, voidaan tukea myös suurta määrää kanavia laajalla laukaisulla. Logiikka-analysaattori voi toimia sekä ajoitus- että tilatilassa, mikä auttaa eristämään joitain ajoitusongelmia.
HaittapuolitagTähän lähestymistapaan voi sisältyä tarve ostaa logiikka-analysaattori, jos sitä ei ole jo varattu projektiin. Tämä epäkohtatage saattaa riittää estämään tämän lähestymistavan monissa tapauksissa. Huomaa kuitenkin, että joitain edullisia logiikka-analysaattorivaihtoehtoja on tulossa saataville, jotka käyttävät PC:tä tai tablettia näyttöön, mikä tekee tästä vaihtoehdosta paljon kustannustehokkaamman yksinkertaisissa virheenkorjausvaatimuksissa.
Käytettyjen FPGA-nastojen määrä voi olla toinen haittapuolitage ja jos leveitä väyliä on tarkkailtava, tarvitaan merkittävää suunnittelua korttien asettelulle ja debug-liittimien lisäämiselle. Tätä vaatimusta on useimmiten vaikea ennustaa suunnitteluvaiheessa ja toinen ei-toivottu monimutkaisuus. Samoin kuin sulautettu logiikka-analysaattori, ulkoinen testausstrategia vaatii suunnittelun uudelleenkääntämistä ja ohjelmointia, kun jokaista uutta koetta tarvitaan.
Yleinen epäkohtatagNäistä kahdesta tekniikasta – sirun sisäisten resurssien käyttö (joka voi myös vaikuttaa suunnittelun ajoitussuorituskykyyn ja luoda lisävirheenkorjausvaatimuksia), tarve kääntää ja ohjelmoida suunnittelu uudelleen (joka voi lisätä tunteja tai jopa päiviä virheenkorjausaikatauluun), ennakkosuunnittelu, jota tarvitaan todennäköisten testiskenaarioiden tunnistamiseen, ja lisäpiirien I/O-resurssien käyttö aiheuttivat tarpeen ilman lähestymistapaa. Yksi vastaus oli omistetun virheenkorjauslogiikan lisääminen FPGA-kankaaseen joissakin laitteissa. Tuloksena oli piirin sisäinen virheenkorjaus laitteistoluettimilla.
In-Circuit FPGA-virheenkorjaus – Hardware Probes
Laitteiston käyttö yksinkertaistaa dramaattisesti FPGA:iden piirin sisäisiä virheenkorjaustekniikoita. Tämä tekniikka, joka on toteutettu Live Probe -ominaisuudena SmartFusion2®SoC FPGA- ja IGLOO®2 FPGA -laitteissa, lisää FPGA-kankaaseen omat mittauslinjat minkä tahansa logiikkaelementin rekisteribitin ulostulon tarkkailemiseksi. Kuten kuvan 4 lohkokaaviosta näkyy, laitteistoanturit ovat saatavilla kahdessa anturikanavassa A ja B.
Valitut rekisterilähdöt (mittauspisteet), kuten kuvan alareunassa oleva, reititetään kahden mittauskanavan yläpuolelle, ja jos ne on valittu, ne voidaan syöttää joko A- tai B-kanavalle. Nämä reaaliaikaiset kanavasignaalit voidaan sitten lähettää laitteen erillisiin mittausanturin A- ja B-nastoihin. Mittaanturin A- ja B-signaalit voidaan myös reitittää sisäisesti sulautettuun logiikka-analysaattoriin.
Huomaa, että anturin nastojen ajoitusominaisuudet ovat säännöllisiä ja niillä on mitätön poikkeama mittapään pisteestä toiseen, mikä tekee reaaliaikaisten signaalien ajoitusominaisuuksien vertailusta paljon helpompaa. Tietoja voidaan kaapata jopa 100 MHz:n taajuudella, joten se sopii useimpiin kohdemalleihin.
Ehkä tärkeintä on mittauspisteiden paikat, koska niitä ei valita osaksi toteutettua suunnittelua (ne valitaan erillisen laitteiston kautta, kun suunnittelu on käynnissä FPGA:lla), voidaan nopeasti muuttaa lähettämällä valintatiedot laitteeseen. Suunnittelun uudelleenkääntämistä ja uudelleenohjelmointia ei tarvita.
Live Probe -ominaisuuden käytön yksinkertaistamiseksi entisestään, siihen liittyvällä virheenkorjausohjelmistotyökalulla on pääsy kaikkiin anturin signaalin sijainteihin automaattisesti luodun virheenkorjauksen kautta. file. Kuten kuvassa 5 näkyy, signaalin nimi voidaan valita signaaliluettelosta ja käyttää halutulle kanavalle. Tämä voidaan tehdä myös suunnittelun ollessa käynnissä, joten suunnittelun koetustoiminta on saumatonta ja erittäin tehokasta.
Monissa tapauksissa laitteisto-anturia, kuten Live Probea, voidaan käyttää yhdessä aiemmin kuvatun sulautetun logiikka-analysaattorin ja ulkoisten testitekniikoiden kanssa.
Kuten kuvasta 6 näkyy, Live Probe -kyky valita signaaleja "lennossa" mahdollistaa tarkkailtavien signaalien nopean ja helpon muuttamisen ilman, että suunnittelua tarvitsee kääntää uudelleen. Ulkoinen logiikka-analysaattori tai skooppi voi helposti tarkkailla mittaussignaaleja, kuten kuvan oikeassa yläkulmassa on osoitettu anturin lähtönastoilla. Vaihtoehtoisesti (tai jopa sen lisäksi) voidaan käyttää sisäistä logiikka-analysaattoria (ILA Identify -lohko, joka näkyy kuvassa) mittapään nastojen tarkkailuun. ILA voi siepata anturin signaalit ja tarkkailla niitä aaltomuotoikkunassa. Anturin paikkoja voidaan muuttaa ilman, että kohdesuunnittelua tarvitsee kääntää uudelleen.
Huomaa, että lisäominaisuuksia liipaisuun ja jäljitykseen voidaan käyttää parantamaan anturin toimivuutta, jolloin monimutkaistenkin suunnitteluongelmien havaitseminen on helppoa.
Muita laitteiston virheenkorjausominaisuuksia on saatavilla myös SmartFusion2 SoC FPGA- ja IGLOO2 FPGA -laitteissa. Yksi näistä ominaisuuksista, nimeltään Active Probe, voi dynaamisesti ja asynkronisesti lukea tai kirjoittaa mihin tahansa logiikkaelementin rekisteribittiin. Kirjoitettu arvo säilyy yhden kellojakson ajan, joten normaali toiminta voi jatkua, mikä tekee siitä erittäin arvokkaan virheenkorjaustyökalun. Active Probe on erityisen kiinnostava, jos halutaan nopeaa sisäisen signaalin havainnointia (ehkä vain tarkistaakseen, että se on aktiivinen tai halutussa tilassa, kuten nollaussignaali), tai jos logiikkatoimintoa on testattava nopeasti kirjoittamalla mittauspisteeseen.
(ehkä käynnistää tilakoneen siirtymä asettamalla nopeasti syöttöarvon ohjausvirta-ongelman eristämiseksi).
Toinen Microsemin tarjoama virheenkorjausominaisuus on Memory Debug. Tämän ominaisuuden avulla suunnittelija voi dynaamisesti ja asynkronisesti lukea tai kirjoittaa valittuun FPGA-kudoksen SRAM-lohkoon. Kuten virheenkorjaustyökalun kuvakaappauksessa (Kuva 7) näkyy, kun Muistilohkot-välilehti on valittuna, käyttäjä voi valita haluamasi muistin luettavaksi, suorittaa muistin tilannekuvakaappauksen, muokata muistiarvoja ja kirjoittaa arvot sitten takaisin laitteeseen. Tämä voi olla erityisen hyödyllistä tarkistettaessa tai asetettaessa tietopuskureita, joita käytetään tietoliikenneporteissa laskentasuuntautuneelle alustalle tai jopa sulautetun CPU:n suorittamaan koodiin. Monimutkaisten tiedoista riippuvien virheiden virheenkorjaus on huomattavasti nopeampaa ja helpompaa, kun muistoja voidaan tarkkailla ja hallita niin nopeasti.
Kun mallin virheenkorjaus on tehty, saattaa olla toivottavaa kytkeä laitteiston virheenkorjausominaisuudet pois päältä arkaluonteisten tietojen suojaamiseksi. Hyökkääjä voi käyttää näitä samoja tiloja lukeakseen tärkeitä tietoja tai muuttaakseen järjestelmäasetuksia, jotka mahdollistavat helpon pääsyn järjestelmän arkaluonteisiin osiin. Microsemi on lisännyt ominaisuuksia, joiden avulla suunnittelija voi suojata laitteen virheenkorjauksen jälkeen. esimampPääsy Live Probeen ja Active Probeen voidaan lukita toiminnon poistamiseksi kokonaan käytöstä mahdollisena hyökkäyskeinona (se jopa eliminoi sen mahdollisuuden, että anturin toiminta luo syöttövirtaan kuvioita, joita voitaisiin käyttää koetintietojen epäsuoraan tarkkailuun). Vaihtoehtoisesti pääsy suunnittelun valittuihin osiin voidaan lukita, jotta estetään pääsy vain näihin osiin. Tämä voi olla kätevää, jos vain osa suunnittelusta on suojattava, jolloin loput suunnittelusta ovat edelleen käytettävissä kenttätestausta tai virheanalyysiä varten.
In-Circuit Debug -vertailukaavio
Nyt yksityiskohtainen review kolmesta tärkeimmästä piirin sisäisestä laitteiston virheenkorjaustekniikasta on kuvattu yhteenvetokaavio, kuten kuvassa 8 on esitetty, on luotu, joka yksityiskohtaisestitagja haittojatagkustakin menetelmästä. Muista, että joitain tekniikoita voidaan käyttää yhdessä (Live Probe ja Internal Logic Analyzer (ILA), kuten Synopsys Identify, esim.ample), voimme nähdä kunkin tekniikan tärkeimmät vahvuudet ja heikkoudet. Kokoelma piirin sisäisiä laitteiston virheenkorjausominaisuuksia (Live Probe, Active Probe ja Memory Debug – yhteisnimitys SmartDebug) ovat heikoimpia muihin tekniikoihin verrattuna käytettävissä olevien koettimien kokonaismäärässä (punainen ympyrä) ja ovat parhaita heikompia (keltainen ympyrä), kun otetaan huomioon sieppausnopeus (ulkoinen testilaitteisto voi olla nopeampi).
ILA-pohjaiset tekniikat, kuten Synopsys Identify, ovat heikoimpia verrattuna muihin tekniikoihin ja kun otetaan huomioon FPGA-resurssivaatimukset. Ulkoiset testauslaitteistoon perustuvat tekniikat ovat useista näkökohdista heikoimpia, ja kustannukset, suunnittelun ajoituksen vaikutus ja anturin liikkeen ylimääräiset kustannukset (johtuen suunnittelun uudelleen kääntämisestä) ovat kaikkein raskaimpia. Ehkä optimaalinen ratkaisu on SmartDebugin ja jonkin muun tekniikan yhdistelmä, jotta SmartDebugin kanavien lukumäärän heikkoutta voidaan vähentää ja mittauspisteen liikehaittaa.tagMyös muiden tekniikoiden estoja on vähennetty.
Signaaliluokitukset
Hyödyllinen ero voidaan tehdä joidenkin yleisimpien signaalityyppien välillä, ja tämä voi auttaa suunnittelemaan virheenkorjaustapaa. esimample, signaalit, jotka eivät muutu muutoin kuin järjestelmän käynnistyksen aikana, kuten järjestelmän nollaus, lohkon palautus tai alustusrekisterit, voidaan luokitella staattisiksi signaaleiksi. Tämäntyyppiset signaalit saadaan tehokkaimmin käsiksi laitteiston kautta, joka voi helposti tarkkailla ja ohjata signaalia ilman pitkää uudelleenkäännössykliä. Active Probe on erinomainen väline staattisten signaalien virheenkorjaukseen. Vastaavasti signaalit, jotka muuttuvat useammin, mutta ovat edelleen staattisia suurimman osan ajasta, voidaan luokitella pseudostaattisiksi, ja ne voidaan myös tehokkaimmin korjata Active Probella. Signaalit, jotka muuttuvat usein, kuten kellosignaalit, voidaan luokitella dynaamisiksi, eivätkä ne ole yhtä helposti saatavilla Active Proben kautta. Live Probe on parempi valinta näiden signaalien tarkkailuun.
Yksinkertainen virheenkorjauskäyttötapaus
Nyt kun ymmärrämme paremmin eri piirin sisäiset virheenkorjausvaihtoehdot, katsotaanpa yksinkertaista suunnittelua esim.ampnähdä kuinka nämä tekniikat toimivat. Kuva 9 esittää yksinkertaisen FPGA-mallin SmartFusion2 SoC FPGA -laitteessa. Microcontroller Subsystem (MSS) nollataan CoreSF2Reset Soft IP -lohkolla. Tämän lohkon tulot ovat Power On Reset, User Fabric Reset ja External Reset. Lähdöt ovat nollaus User Fabriciin, MSS-nollaus ja M3-nollaus. Virheoireita ovat, että I/O:issa ei ole toimintaa, vaikka laite poistuu POR-tilasta onnistuneesti. Kuvassa on myös kuvattu kolme eri vaihtoehtoa tämän virheen virheenkorjaukseen: Sininen laatikko (merkitty ETE) on tarkoitettu External Test Equipment -menetelmälle; vihreä laatikko (merkitty ILA) on Internal Logic Analyzer -menetelmää varten; ja oranssi laatikko (merkitty AP) on Active Probe -menetelmää varten. Oletetaan, että virheen mahdolliset perimmäiset syyt ovat CoreSF2Reset Soft IP -lohkon virheellisesti vahvistetut palautustulot.
Tarkastellaan nyt kolmen aiemmin kuvatun piirin sisäisen menetelmän virheenkorjausprosessia.
Ulkoiset testauslaitteet
Tätä menetelmää käytettäessä oletetaan, että testilaitteet ovat saatavilla, eikä niitä käytetä korkeamman prioriteetin projektissa. Lisäksi on tärkeää suunnitella etukäteen, jotta joitain FPGA I/O:ita on saatavilla ja ne voidaan helposti liittää testauslaitteistoon. Ottaa otsikko PCB esimample, olisi erittäin hyödyllinen ja minimoi ajan, joka kuluu "todennäköisen epäillyn" tunnistamiseen ja yhteyden muodostamiseen tai mahdolliseen nastoihin liittyvään oikosulkuun luotauksen aikana. Suunnittelu on käännettävä uudelleen, jotta voidaan valita signaalit, joita haluamme tutkia. Toivottavasti emme "kuori sipulia takaisin" ja joudumme valitsemaan lisäsignaaleja lisätutkimuksia varten, koska usein alkuperäinen tutkimuksemme johtaa vain lisää kysymyksiin. Joka tapauksessa uudelleenkäännös- ja ohjelmointiprosessi voi viedä huomattavan paljon aikaa, ja jos se johtaa ajoitusvirheisiin, uusi suunnittelu on tarpeen (me kaikki tiedämme, kuinka turhauttavaa voi olla ajoituksen sulkemisongelmien ratkaiseminen, etenkin kun teet suunnittelumuutoksia löytääksesi suunnitteluvirheen – koko prosessi voi kestää minuuteista tunteihin)! On myös tärkeää muistaa, että jos suunnittelussa ei ole vapaita I/O:ita, tätä menetelmää ei voida toteuttaa. Lisäksi tämä menetelmä häiritsee rakenteellisesti suunnittelua – ja ajoitukseen liittyvät virheet voivat kadota tai ilmaantua uudelleen iteraatioiden välillä.
Sisäinen logiikka-analysaattori
Tätä menetelmää käyttämällä ILA on lisättävä suunnitteluun kangasresursseja käyttäen, ja se on sitten käännettävä uudelleen. Huomaa, että jos ILA on jo instantoitu, signaaleja, joita haluamme tutkia, ei ehkä ole instrumentoitu, mikä vaatisi myös uudelleenkääntämisen. Tämä prosessi saattaa muuttaa alkuperäistä suunnittelua ja rikkoa ajoitusrajoituksia. Jos ajoitus täyttyy, suunnittelu on ohjelmoitava uudelleen ja alustettava uudelleen. Tämä koko prosessi voi kestää useita minuutteja tai jopa tunteja, jos uudelleenkäännösajat ovat pitkiä ja tarvitaan useita läpikulkuja. Tämä lähestymistapa on rakenteellisesti häiritsevä ja voi aiheuttaa samanlaisia ongelmia kuin yllä olevaa menetelmää käytettäessä.
Aktiivinen koetin
Tällä menetelmällä Active Probe voidaan osoittaa erilaisten nollaussignaalien lähteeseen, jotka kaikki tulevat rekisterilähdöistä (kuten on yleistä missä tahansa hyvässä digitaalisessa suunnittelukäytännössä). Signaalit valitaan yksi kerrallaan alla olevassa kuvassa 10 esitetystä Active Probe -valikosta. Valitut signaaliarvot voidaan lukea ja ne näkyvät Active Probe -tietoikkunassa. Kaikki väärät väitteet on helppo tunnistaa. Tämä testi voidaan tehdä välittömästi ilman tarvetta kääntää ja ohjelmoida laitetta uudelleen, eikä se ole rakenteellisesti tai menettelyllisesti häiritsevää. Koko prosessi kestää vain muutaman sekunnin. Tämä menetelmä voi myös luoda ohjattavuuden (muuttaa arvoja asynkronisesti), mitä kaksi muuta menetelmää eivät salli. Tässä nimenomaisessa exampRekisterin lähteenä oleva nollaussignaali voidaan helposti tutkia ja havaita olevan aktiivisessa tilassa.
Nollaussignaalin hetkellinen vaihto voidaan saada aikaan käsittelemällä asynkronisesti loput signaalit muodostavaa rekisteriä.
Monimutkaisempi virheenkorjauskäyttötapaus
Yllä oleva suunnittelu oli hyvin yksinkertainen ja hyödyllinen johdannossa kuvattujen suunnittelutekniikoiden käyttöön, mutta monimutkaisempi esimerkkiample voisi olla vielä havainnollistavampi. Monta kertaa kiinnostuksen kohteena oleva signaali ei ole staattinen signaali, kuten se oli yksinkertaisessa esimerkissämmeample vaan on dynaaminen. Yleinen dynaaminen signaali on välikello, jota ehkä käytetään sarjaliitännän kättelyn ajoitukseen. Kuvassa 11 on esitetty tällainen rakenne käyttäjän Soft IP -ytimellä, tässä tapauksessa mukautetulla sarjaliitännällä, joka on kytketty järjestelmän APB-väylään. Virheoireet ovat, että käyttäjien mukautetussa sarjaliitännässä ei ole toimintaa ja että kun APB-väyläisäntä antaa tapahtuman päästäkseen sarjaliitäntään, se menee poikkeustilaan, joka osoittaa virheellisen kättelyn. Nämä olosuhteet näyttävät sulkevan pois staattisen syyn, kuten virheellisen palautussignaalin, koska tapahtumatilakone ei näytä toimivan odotetulla nopeudella ja aiheuttaa siten poikkeuksen. Perimmäisenä syynä uskotaan olevan kellotaajuusgeneraattori käyttäjän IP-ytimessä.
Jos se ei toimi oikealla taajuudella, seurauksena on kuvattu virhe.
Tässä tilanteessa on luultavasti parempi strategia korvata Active Probe -lähestymistapa Live Probella. Tätä havainnollistaa yllä olevassa kuvassa oranssinvärinen LP-laatikko JTAG signaali anturin lähteen valintaa varten.
Ulkoiset testauslaitteet
Tässä tapauksessa menetelmä on hyvin samanlainen kuin aiemmin kuvattu yksinkertainen esimample. Käyttäjän kellosignaali tuodaan ulos testipisteeseen (toivottavasti otsikkoon) ja aikaa vievä uudelleenkäännös tarvitaan. Voi myös olla hyödyllistä tuoda esiin vertailusignaali, ehkä järjestelmän kello, jota käytetään kellottamaan käyttäjän IP-osoite vertailusignaalina. Meidän tulee jälleen kääntää ja ohjelmoida uudelleen, joten koko prosessi voi viedä huomattavan paljon aikaa.
Sisäinen logiikka-analysaattori
Tämä tapaus on hyvin samanlainen kuin yksinkertainen example. ILA on lisättävä tai haluttu signaali määriteltävä ja uudelleenkäännös- ja uudelleenohjelmointijakso suoritettava. Kaikki aiemmin kuvatut ongelmat johtavat edelleen huomattavaan virheenkorjausjaksoon. Siinä on kuitenkin ylimääräinen monimutkaisuus. ILA:ta ohjaavan kellon on oltava synkroninen ja mieluiten paljon nopeampi käyttäjän Soft IP -ytimestä havaittavaan kelloon nähden. Jos nämä kellot ovat asynkronisia tai niillä ei ole oikeita ajoitussuhteita, tiedonkeruu on arvaamatonta ja se voi aiheuttaa sekaannusta virheenkorjausprosessissa.
Huomaa, että jos käyttäjän Soft IP -kelloa ei luoda sirulla (ehkä se on palautettu sarjaliitännästä), suunnittelijan on ehkä lisättävä kellomoduuli nopeamman ILA-kellon luomiseksi käyttämällä lisäresursseja ja mahdollisesti aiheuttaen ajoitusvirheen.
Live Probe
Tällä menetelmällä Live Probe voidaan nopeasti osoittaa käyttäjän kellon lähteeseen ja mihin tahansa muuhun kellolähteeseen rekisteristä virheen perimmäisen syyn selvittämiseksi. Live Probe näyttää valitut signaalilähdöt reaaliajassa ja signaalien välinen ajoitussuhde on siten paljon helpompi määrittää. Koko prosessi kestää vain muutaman sekunnin.
Muut sarjaliitäntöjen virheenkorjausominaisuudet
On myös tärkeää huomauttaa, että SmartFusion2 SoC FPGA- ja IGLOO2 FPGA -laitteissa on monia muita virheenkorjausominaisuuksia, joita voidaan käyttää sarjaliitännöissä, kuten edellisessä ex.ampsuunnittelua, jossa virheet ovat vieläkin monimutkaisempia. SERDES Debug, esimample tarjoaa erityisiä virheenkorjausominaisuuksia omistetuille nopeille sarjaliitännöille. Joihinkin SERDES Debug -ominaisuuksiin kuuluu PMA-testituki (kuten PRBS-mallin luominen ja takaisinkytkentätestaus) tuki useille SERDES-testikokoonpanoille rekisteritason uudelleenkonfiguroinnilla, jotta koko suunnittelukulkua ei käytetä konfiguraatiomuutosten tekemiseen, sekä tekstiraportit, jotka näyttävät määritetyt protokollat, SERDES-määritysrekisterit ja kaistanmääritysrekisterit. Nämä ominaisuudet tekevät SERDES-virheenkorjauksesta paljon helpompaa, ja niitä voidaan käyttää yhdessä Live Probe:n ja Active Proben kanssa nopeuttamaan monimutkaisten piirien virheenkorjausta.
Aiemmin kuvattua Memory Debug -työkalua voidaan käyttää myös SERDES Debugin kanssa testauksen nopeuttamiseksi. Koska muistipuskurit voidaan tarkastaa ja muuttaa nopeasti ja helposti Memory Debugilla, on mahdollista luoda nopeasti "testipaketteja" ja tarkkailla takaisinkytkentätuloksia tai järjestelmien välistä viestintää. Suunnittelija voi hyödyntää näitä ominaisuuksia ja siten minimoida erikoistuneiden "testivaljaiden" tarpeen, jotka kuluttavat lisää FPGA-kangasta ja voivat vaikuttaa sirun ajoitukseen.
Johtopäätös
Tässä artikkelissa on kuvattu yksityiskohtaisesti useita erilaisia lähestymistapoja piirin sisäisen virheenkorjauksen toteuttamiseen FPGA:ille ja SoC FPGA:ille – integroidun logiikka-analysaattorin käyttö, ulkoisten testilaitteiden käyttö ja FPGA-kankaaseen integroitujen erillisten anturipiirien käyttö. Erikoistuneet ja omistetut anturipiirit, kuten Active Probe ja Live Probe, joita Microsemi tarjoaa SmartFusion2 SoC FPGA- ja IGLOO2 FPGA -laitteille, nopeuttavat ja yksinkertaistavat huomattavasti virheenkorjausprosessia. Mahdollisuus muuttaa nopeasti sisäisten signaalien valintaa (ilman tarvetta suorittaa erittäin aikaa vievää uudelleenkäännös- ja uudelleenohjelmointijaksoa) ja kyky tutkia sisäisiä signaaleja (ilman tarvetta käyttää FPGA-kangasta ja mahdollisesti aiheuttaa ajoitusrikkomuksia) osoittautuivat suureksi eduksi.tagFPGA-suunnitelmien virheenkorjauksessa. Lisäksi kuvattiin useiden menetelmien käyttöä, jotka voivat toimia yhdessä tarjotakseen entistä kattavamman virheenkorjausominaisuuden. Lopuksi kaksi example debug -käyttötapauksia annettiin havainnollistamaan kuvattujen menetelmien välisiä kompromisseja.
Lisätietoja
- IGLOO2 FPGA:t
- SmartFusion2 SoC FPGA:t
Microsemi Corporation (Nasdaq: MSCC) tarjoaa kattavan valikoiman puolijohde- ja järjestelmäratkaisuja viestintä-, puolustus- ja turvallisuus-, ilmailu- ja teollisuusmarkkinoille. Tuotteisiin kuuluvat korkean suorituskyvyn ja säteilyä kestävät analogiset sekasignaaliintegroidut piirit, FPGA:t, SoC:t ja ASIC:t; virranhallinnan tuotteet; ajoitus- ja synkronointilaitteet sekä tarkat aikaratkaisut, jotka asettavat ajan mittaan maailman standardin; äänenkäsittelylaitteet; RF-ratkaisut; erilliset komponentit; turvallisuusteknologiat ja skaalautuva anti-tamper tuotteet; Power-over-Ethernet-IC:t ja keskivälit; sekä mukautettuja suunnitteluominaisuuksia ja palveluita. Microsemin pääkonttori sijaitsee Aliso Viejossa, Kaliforniassa, ja sillä on noin 3,400 XNUMX työntekijää maailmanlaajuisesti. Lisätietoja osoitteessa www.microsemi.com.
© 2014 Microsemi Corporation. Kaikki oikeudet pidätetään. Microsemi ja Microsemi-logo ovat Microsemi Corporationin tavaramerkkejä. Kaikki muut tavaramerkit ja palvelumerkit ovat omistajiensa omaisuutta.
Microsemin pääkonttori
- Yksi Enterprise, Aliso Viejo CA 92656 USA
- Sisällä USA: +1 800-713-4113
- Ulkopuolella USA: +1 949-380-6100
- Myynti: +1 949-380-6136
- Faksi: +1 949-215-4996
- Sähköposti: sales.support@microsemi.com
FAQ
- K: Mikä on laitteen suurin tiedonkeruutaajuus?
V: Laite tukee tiedonkeruuta jopa 100 MHz:iin asti, mikä sopii useimpiin kohdemalleihin. - K: Pitääkö minun kääntää suunnittelu uudelleen, kun käytän anturipiirejä virheenkorjaukseen?
V: Ei, mittauspisteiden paikkoja voidaan muuttaa nopeasti ilman suunnittelun uudelleenkääntämistä tai uudelleenohjelmointia.
Asiakirjat / Resurssit
![]() |
Microsemi In-Circuit FPGA -virheenkorjaus [pdfOhjeet In-Circuit FPGA Debug, FPGA Debug, Debug |