Microsemi In-Circuit FPGA Debug
Produkt ynformaasje
Spesifikaasjes
- Apparaattype: Microsemi SmartFusion2 SoC FPGA
- Release Date: Mei 2014
- Debuggingmooglikheden: In-Circuit FPGA Debug, Embedded Logic Analyzer
- Maksimum data capture frekwinsje: oant 100MHz
Abstrakt
FPGAs binne krêftige design eleminten yn ynbêde systemen mei in protte design advantages, mar dizze apparaten kinne komplekse ûntwerpen hawwe mei komplekse ûntwerpproblemen dy't moatte wurde debugged. It opspoaren fan ûntwerpproblemen lykas definysjefouten, systeemynteraksjeproblemen en systeemtimingfouten kin in útdaging wêze. It opnimmen fan yn-circuit debugmooglikheden yn in FPGA kin hardware-debug dramatysk ferbetterje en ûntelbere oeren frustraasje foarkomme. Dit artikel beskriuwt ferskate oanpakken foar yn-circuit debug foar FPGA's, identifisearret wichtige ôfwagings, en fia in eks...ample-ûntwerp, rjochte op in Microsemi SmartFusion®2 SoC FPGA-apparaat, sil sjen litte hoe't nije mooglikheden kinne wurde brûkt om debuggen en testen te rapperjen.
Ynlieding
FPGA's binne pervasive en krêftige ûntwerpeleminten en wurde no fûn yn praktysk elk ynbêde systeem. Mei tanimmende kapasiteit, opnimmen fan komplekse on-chip funksjonele blokken en avansearre seriële ynterfaces kinne dizze apparaten ek komplekse ûntwerpproblemen hawwe dy't moatte wurde debuggen. It folgjen fan problemen lykas funksjonele definysje-flaters (op it FPGA- as systeemnivo), problemen mei funksjonele systeemynteraksje, problemen mei systeemtiming, en problemen mei sinjaalfidelity tusken IC's (lykas lûd, crosstalk, of refleksjes) wurde allegear folle komplekser by it brûken fan avansearre FPGA's. Simulaasje is grif in grutte help by it identifisearjen fan in protte ûntwerpproblemen, mar in protte ynteraksjes yn 'e echte wrâld sille net ferskine oant it ûntwerp is ymplementearre yn hardware. Ferskate ferskillende techniken foar it debuggen fan komplekse ûntwerpproblemen binne ûntwikkele om it proses te ferienfâldigjen. In soarchfâldich begryp fan elk fan dizze kaai techniken, ynklusyf de ferskate advantages en disadvantages, is nuttich as jo beskôgje hokker technyk of kombinaasje fan techniken geskikt is foar in bepaald ûntwerp.
In eksample FPGA-ûntwerp, rjochte op in Microsemi SmartFusion2 SoC FPGA-apparaat, kin brûkt wurde om guon fan 'e advan te demonstrearjentages en disadvantages fan dizze standert techniken likegoed as de nijste yn-circuit debug mooglikheden. Dit yllustrative eksample sil sjen litte hoe't dizze ferskate techniken kinne wurde brûkt om de identifikaasje en eliminaasje fan hardwareproblemen by hardware-debug te fersnellen.
Wêrom is FPGA-debuggen in kritysk aspekt fan systeemûntwerp en -ûntwikkeling?
FPGA's hawwe twa haadgebrûksmodellen dy't se ûnderskiede fan oare ûntwerpeleminten. FPGA's kinne brûkt wurde yn it produksjeprodukt of kinne brûkt wurde as in ûntwikkelingsauto om in produksjeûntwerpkonsept te bewizen of prototype te meitsjen. As se brûkt wurde as produksjeauto, kinne FPGA's in folle fleksibeler doel wêze dan ASIC- as CPU-basearre produksjeauto's. Dit is foaral wichtich foar in nij ûntwerp, ien dat noch net yn hardware is ymplementearre. Untwerpen mei ferskate arsjitektoanyske opsjes kinne maklik wurde makke en hifke, sadat it optimale ûntwerp wurdt identifisearre. FPGA's mei on-chip processors (SoC FPGAs) meitsje it ek mooglik om CPU-basearre ferwurking te ruiljen mei hardware-assistearre FPGA-basearre fersnellingsfunksjes. Dizze advantages kinne de tiid dy't nedich is foar ûntwerp, falidaasje, testen en mislearringsanalyse foar nije produktûntwikkelingen dramatysk ferminderje.
Wannear't brûkt foar prototyping in ûntwerp, miskien foar in produksje ASIC, FPGA fleksibiliteit is in wichtich foardiel. In eigentlik hardwareplatfoarm, sels ien dy't net op folsleine snelheid rint, makket it folle makliker om detaillearre systeemprestaasjesmetriken, gegevens foar trochputanalyse en arsjitektuerbewiis-fan-konseptresultaten te krijen. FPGA-stipe foar ferhurde ymplemintaasjes fan bussen fan yndustrystandert (lykas PCIe®, Gigabit Ethernet, XAUI, USB, CAN, en oaren) simplifies de testen ferbûn mei dizze ynterfaces. De nijste famyljes fan FPGAs mei on-chip ARM Prozessoren (SoC FPGAs), makket it maklik om prototype ymplemintaasjes mei ynbêde processors oan. Earder ûntwikkele prosessorkoade kin wurde porteare nei it prototype en nije koade makke parallel mei de hardware-ûntwerppoging.
Dizze kombinaasje fan in standert prosessor mei standert ynterface bussen makket it mooglik in leverage it grutte ekosysteem fan beskikbere koade biblioteken, drivers, funksjonele APIs, Real Time Operating Systems, en sels folsleine bestjoeringssystemen foar in folle flugger meitsje in wurkjend prototype. Derneist, as it ûntwerp fersteurd is, kin it FPGA-prototype wurde brûkt om wiidweidige simulaasjetestsets te fangen (foar sawol stimulus as antwurd) dy't wirklike systeemgegevens reflektearje. Dizze datasets kinne fan ûnskatbere wearde wêze by it meitsjen fan de definitive simulaasjes foar in ASIC of oare produksje-ymplemintaasje. De advantagIt brûken fan in FPGA as ûntwerpprototype kin de tiid foar ûntwerp, falidaasje, testen en mislearringsanalyse foar de ymplemintaasje fan it definitive produkt dramatysk ferminderje.
Yn beide fan dizze gewoane FPGA-gebrûksmodellen is de fleksibiliteit fan 'e FPGA as ûntwerpdoel in wichtich foardieltage. Dit betsjut dat in protte ûntwerpwizigingen en iteraasjes de noarm soene wêze, en dus soe de mooglikheid om ûntwerpflaters rap te debuggen kritysk wêze om safolle mooglik ûntwerpopsjes mooglik te meitsjen. Sûnder in effisjinte debug-mooglikheid in protte fan 'e advantage fan FPGA-ûntwerpfleksibiliteit sil wurde fermindere troch de ekstra fereaske tiid foar debuggen. Gelokkich kinne FPGA's ek ekstra hardwarefunksjes leverje dy't real-time debuggen dramatysk ferienfâldigje. Foardat wy nei dizze mooglikheden sjogge, litte wy earst sjen nei de meast foarkommende soarten problemen wêrmei in FPGA-ûntwerp kin wurde konfrontearre, sadat wy de juste eftergrûn hawwe om de effisjinsje en de byhearrende ôfwikselingen fan ferskate debuggen-ark te evaluearjen.
Algemiene problemen by it debuggen fan FPGA-ûntwerpen
Tegearre mei de útwreide mooglikheden dy't moderne FPGA's bringe, makket de byhearrende ferhege kompleksiteit it dreger om flaterfrije ûntwerpen te meitsjen. Eins is rûsd dat debuggen mear as 50% fan 'e ûntwerpsyklus fan it ynbêde systeem yn beslach nimme kin. Mei de druk op 'e tiid om op 'e merk te kommen dy't de ûntwikkelingssyklus bliuwt te drukken, wurdt hardware-debuggen fan it earste systeem nei in neitocht ferwiisd - al te faak wurdt oannommen dat ferifikaasje (sels in grut persintaazje)...tage fan it ûntwikkelingskema), sil alle bugs fange foarôfgeand oan it earste systeem opbringen. Litte wy nei mar in pear gewoane soarten systeemproblemen sjen om de útdagings better te begripen dy't in typysk ûntwerp sil tsjinkomme tidens it earste systeem opbringen.
Funksjonele definysjeflaters kinne dûbeld lestich te finen wêze, om't de ûntwerper in bepaalde eask ferkeard begrepen hat, sadat de flater kin wurde oersjoen, sels as se soarchfâldich sjogge nei de details fan it ûntwerp. In eksample fan in mienskiplike funksjonele definysje flater soe wêze dêr't in steat masine oergong net einigje yn de rjochter steat. Flaters kinne ek ferskine yn systeem ynterfaces as in ynteraksje probleem. Interface latency, bygelyksample, miskien ferkeard oantsjutte resultearret yn in ûnferwachte buffer oerstreaming of underflow betingst.
Timingproblemen op systeemnivo binne in oare heul foarkommende boarne fan ûntwerpflaters. Benammen asynchrone eveneminten binne in mienskiplike boarne fan flaters as syngronisaasje of oerstekkende timingdomein-effekten net soarchfâldich beskôge wurde. By it operearjen op snelheid kinne dizze soarten flaters heul problematysk wêze en kinne heul selden ferskine, miskien allinich as spesifike gegevenspatroanen har manifestearje. In protte mienskiplike oertredings fan timing falle yn dizze kategory en binne normaal heul lestich, as net ûnmooglik om te simulearjen.
Timing oertredings kinne ek wêze it gefolch fan lege sinjaal trou tusken yntegrearre circuits, benammen yn systemen mei meardere macht rails foar elk circuit. Lege sinjaalfidelity kin resultearje yn sinjaallûd, oerspraak, refleksjes, tefolle laden en problemen mei elektromagnetyske ynterferinsje (EMI) dy't faak ferskine as timing-oertredings. Stromforsyningsproblemen, lykas transients (benammen tidens it opstarten of ôfsluten fan it systeem), loadfariaasjes en spanningen mei hege krêftdissipaasje kinne ek resultearje yn mysterieuze flaters, faaks net maklik werom te finen nei in boarne fan stroomfoarsjenning. Sels as it ûntwerp folslein korrekt is, kinne problemen mei boardfabrikaasje flaters opleverje. Defekte solder gewrichten en ferkeard taheakke Anschlüsse, bygelyksample, kin wêze de boarne fan flaters en kin sels wêze temperatuer of board lokaasje ôfhinklik. It gebrûk fan avansearre FPGA-ferpakkingstechniken kin it dreech meitsje om sinjalen op 'e printe circuit board te probearjen, dus gewoan tagong ta in winske sinjaal kin faaks problematysk wêze. Faak meitsje in protte ûntwerpproblemen gjin direkte flater en moatte se troch it ûntwerp rimpelje oant de flater himsels wirklik manifesteart. It opspoaren fan de startflater werom nei de woartel oarsaak kin faaks in frustrearjende, drege en tiidslinende taak wêze.
Bygelyksample, in inkele bit ferkeard yn in oersettingstabel kin pas in protte syklusen letter yn in flater resultearje. Guon fan 'e ark dy't wy letter yn dit artikel sille besprekke, dy't spesjale yn-circuit debug-hardware brûke, binne spesifyk rjochte op it rapper en makliker meitsjen fan dizze 'bug hunts'. Foardat wy yngeane op 'e details fan dizze ark, litte wy earst in populêre software-basearre debuggingtechnyksimulaasje besjen om de foardielen better te begripen.tages en disadvantages fan it brûken fan simulaasje foar debuggen.
Gebrûk fan simulaasje foar debuggen
Typysk yn in ûntwerpsimulaasje wurde alle echte komponinten binnen en bûten it ûntwerp wiskundich modeleare as softwareprosessen dy't sequentieel wurde útfierd op in standert CPU. It tapassen fan in breed skala oan stimulâns op it ûntwerp en it kontrolearjen fan de ferwachte útfier tsjin 'e simulearre ûntwerpútfier, is in maklike manier om de meast foar de hân lizzende ûntwerpflaters te fangen. In finster toant in typyske simulaasje run wurdt jûn yn figuer 1 hjirûnder. De dúdlike advantagIt ferskil tusken simulaasje en hardware-basearre debuggen is dat simulaasje yn 'e software dien wurde kin - der binne gjin echte hardware-basearre ûntwerp- en testbanken nedich. Simulaasje kin in protte ûntwerpflaters fluch opspoare, benammen dyjingen dy't ferbûn binne mei ferkearde spesifikaasjes, misferstannen fan ynterface-easken, funksjeflaters en in protte oare 'grove' soarten flaters dy't maklik ûntdutsen wurde troch ienfâldige stimulusfektoaren.
Simulaasje is benammen effektyf as wiidweidige stimuluskombinaasjes beskikber binne foar de ûntwerper en de resultearjende útfier goed bekend is. Yn dizze gefallen kin simulaasje in hast útputtende test fan in ûntwerp dwaan. Spitigernôch hawwe de measte ûntwerpen gjin maklike tagong ta wiidweidige testsuites en it proses fan it meitsjen dêrfan kin tige tiidslinend wêze. It meitsjen fan in testsuite dy't 100% fan it ûntwerp beslacht is praktysk ûnmooglik foar grutte FPGA-basearre ûntwerpen en moatte fluchtoetsen brûkt wurde om te besykjen de kaaieleminten fan it ûntwerp te dekken. In oare swierrichheid mei simulaasje is dat it gjin 'echte wrâld'-ymplemintaasje is en gjin asynchrone eveneminten, systeemynteraksjes op snelheid of timingoertredings kin fange. Uteinlik kin it simulaasjeproses tige stadich wêze en as in protte iteraasjes nedich binne, wurdt simulaasje al gau it meast tiidslinende, en faak it djoerste diel fan it ûntwikkelingsproses.
As alternatyf (of miskien better sein, as tafoeging oan simulaasje) fûnen FPGA-ûntwerpers dat se debug-hardware yn it FPGA-ûntwerp kinne tafoegje om wichtige sinjalen binnen it apparaat te observearjen en te kontrolearjen. Dizze techniken ûntwikkele oarspronklik as ad-hoc oanpak, mar hawwe stadichoan ûntwikkele ta in standert hardware debug strategy. Dit gebrûk fan yn-circuit-debugmooglikheden biedt signifikant foardieltages foar FPGA-basearre ûntwerpen en de folgjende seksje sil de trije meast foarkommende strategyen en har ferskate advan ûndersykjetages en disadvantages.
Common In-Circuit Debug Approaches foar FPGAs
De meast foarkommende techniken foar it ymplementearjen fan yn-circuit-debug-mooglikheden yn FPGA's brûke of in ynbêde logyske analysator, eksterne testapparatuer, as tawijde sinjaalprobe-hardware ynbêde yn 'e FPGA-stof. De ynbêde logyske analysator wurdt typysk ymplementearre mei FPGA-stof en wurdt ynfoege yn it ûntwerp. De JTAG poarte wurdt brûkt om tagong te krijen ta de analysator en de fongen gegevens kinne wurde werjûn op in PC. As eksterne testapparatuer wurdt brûkt, wurdt it FPGA-ûntwerp ûnder test oanpast sadat selekteare ynterne FPGA-sinjalen wurde trochstjoerd nei útfierpinnen. Dizze pinnen kinne dan wurde waarnommen fia de eksterne testapparatuer. As tawijde hardware foar sinjaalsonde wurdt brûkt, kin in brede seleksje fan ynterne sinjalen yn realtime lêzen wurde. Guon probe-ymplemintaasjes kinne sels brûkt wurde om te skriuwen nei registraasje of ûnthâldlokaasjes, wêrtroch debugmooglikheden fierder ferbetterje. Lit ús yn mear detail sjen nei de advantages en disadvantages fan elk fan dizze techniken en dan sjoch nei in eksample ûntwerp om te sjen hoe't dizze ferskillende oanpakken de totale debuggentiid kinne beynfloedzje.
In-Circuit FPGA Debug-ynsletten logyske analysator
It konsept fan 'e ynbêde logika-analysator wie in direkt resultaat fan' e ad-hoc yn-circuit-debuggen mooglikheden dy't ûntwerpers ymplementearre doe't FPGA's foar it earst waarden brûkt. Ynbêde logika-analyzers tafoege nije mooglikheden en elimineare de eask foar de ûntwerper om har eigen analysator te ûntwikkeljen. De measte FPGA's biede dizze mooglikheden en tredden biede standert analyzers (Identify®, fan Synopsys, is ien populêre eksample) dat kin maklik ynterface mei ark op heger nivo om de produktiviteit fierder te ferbetterjen.
De logika analyzer funksjonaliteit wurdt ynfoege yn it ûntwerp, mei help fan FPGA stof en ynbêde ûnthâld blokken as trace buffers, lykas yllustrearre yn figuer 2. Triggering boarnen wurde ek makke sadat komplekse sinjaal ynteraksjes kinne maklik wurde selektearre en fêstlein. Tagong ta de analysator foar kontrôle en gegevensoerdracht wurdt typysk dien fia de standert JTAG poarte te ferienfâldigjen ynterface easken. Fongen gegevens kinne wurde werjûn op in PC mei help fan mienskiplik viewsoftware en spegelt typysk in logikasimulatorgolffoarmútfier viewyn styl.
De advantages fan dizze oanpak binne dat gjin ekstra FPGA I/O-pins wurde brûkt, allinich de standert JTAG sinjalen. De ynbêde logyske analysator IP-kearnen binne normaal relatyf goedkeap en kinne yn guon gefallen in opsje wêze foar besteande FPGA-synteze, as simulaasje-ark. Yn guon gefallen kin de ynbêde logika-analysator ek ekstra útgongen leverje op net brûkte I / O's, as it handiger is. Ien fan 'e neidielentagIt neidiel fan dizze oanpak is dat in grutte hoemannichte FPGA-boarnen nedich binne. Benammen as tracebuffers brûkt wurde, sil dit it oantal beskikbere blokûnthâlden ferminderje. As in brede buffer nedich is, sil dit ek in ôfwaging wêze tsjin ûnthâlddjipte (om't it gebrûk fan in breder ûnthâld resulteart yn in ûndjippere ûnthâlddjipte) - in grut neidieltage by it brûken fan lytsere apparaten. Miskien is it grutste neidiel fan dizze technyk dat elke kear as in oanpassing oan sonde pleatsing wurdt makke, is it nedich om it ûntwerp opnij te kompilearjen en te programmearjen. By it brûken fan in grut apparaat kin dit proses in signifikante tiid nimme. Troch de manier wêrop de sinjaalprobes yn it ûntwerp pleatst wurde, kin it lestich wêze om sinjaaltimingsrelaasjes te korrelearjen. Derneist binne de fertragingen tusken sinjaalprobes net konsekwint en dus binne timingrelaasjes lestich te fergelykjen. Dit is in bysûndere muoite by it fergelykjen fan asynchrone sinjalen as sinjalen fan ferskate tiiddomeinen.
In-Circuit FPGA Debug - Eksterne testapparatuer
It brûken fan yn-circuit debug koade yn gearhing mei eksterne test apparatuer wie in natuerlike ûntwikkeling doe't in eksterne logika analyzer wie al beskikber foar systeem testen. Troch wat ienfâldige debugkoade te meitsjen om ynterne testsinjalen te identifisearjen en te selektearjen en se oan te passen op FPGA I/O's, lykas werjûn yn figuer 3, wie it mooglik om de avansearre mooglikheden fan 'e analysator te benutten (lykas grutte tracebuffers, komplekse triggerende sekwinsjes, en meardere viewing-opsjes) om ienfâldige, mar krêftige debug-omjouwings te meitsjen. Mear komplekse yn-circuit-mooglikheden foar avansearre triggeropsjes kinne it oantal needsaaklike útgongen minimalisearje. Bygelyksample, selektearje spesifike adressen op in brede bus kin wêze ferbean as eksterne pins wiene nedich.
It brûken fan ynterne FPGA-logika fermindert dramatysk I / O-easken en kin sels sykje nei spesifike adrespatroanen (miskien in oprop- en weromreis) foar it debuggen fan mear komplekse problemen. As in mienskiplike brûkersynterface beskikber is, kin dit de learkurve ferienfâldigje en de produktiviteit ferbetterje.
De advantages fan dizze oanpak is dat it de kosten fan 'e eksterne testapparatuer makket en dus gjin ekstra arkkosten binne. Guon debug circuit IP kearnen binne beskikber fan apparatuer fabrikanten of FPGA fabrikanten, en kin wêze hiel lege kosten of sels fergees. It bedrach fan FPGA-boarnen dy't nedich binne foar it útfieren fan de logika foar seleksje fan sinjaal is heul lyts, en om't de spoarfunksje wurdt dien mei de eksterne logika-analysator, binne gjin blokûnthâld nedich. Sûnt seleksjelogika goedkeap is, kinne in grut oantal kanalen mei brede triggering ek wurde stipe. De logika-analyzer kin sawol yn in timingmodus as in steatmodus operearje, wat helpt by it isolearjen fan guon timingproblemen.
It neidieltagDizze oanpak kin de needsaak omfetsje om in logyske analysator te keapjen, as men net al oan it projekt is tawiisd. Dit neidieltage kin genôch wêze om dizze oanpak yn in protte gefallen te ûntmoedigjen. Tink derom lykwols dat guon goedkeape logika-analyzeropsjes beskikber wurde dy't de PC as in tablet brûke foar werjefte, wêrtroch dizze opsje folle mear kosten-effektiver is foar ienfâldige debug-easken.
It oantal konsumearre FPGA-pins kin in oar nadeel wêzetage en as brede bussen moatte wurde waarnommen, wichtige planning foar board yndieling en de tafoeging fan debug Anschlüsse is nedich. Dizze eask is meastentiids lestich te foarsizzen betiid yn de ûntwerp faze en in oare net winske kompleksiteit. Fergelykber mei de oanpak fan 'e ynbêde logika-analyzer fereasket de eksterne teststrategy opnij kompilearjen en werprogrammearjen fan in ûntwerp, as elk nij eksperimint nedich is.
De mienskiplike neidieltages fan dizze twa techniken - it gebrûk fan on-chip-boarnen (dy't ek ynfloed hawwe kinne op 'e timingprestaasjes fan it ûntwerp en ekstra debug-easken oanmeitsje) de needsaak om it ûntwerp opnij te kompilearjen en opnij te programmearjen (wat oeren of sels dagen tafoegje kin oan it debugskema) de foarôfgeande planning dy't nedich is foar it identifisearjen fan wierskynlike testscenario's, en it gebrûk fan ekstra chip I/O-boarnen makken in needsaak foar in oanpak sûnder dizze neidielen. Ien reaksje wie de tafoeging fan tawijde debuglogika oan 'e FPGA-fabric op guon apparaten. In-circuit debug mei hardwareprobes wie it resultaat.
In-Circuit FPGA Debug - Hardware Probes
It gebrûk fan hardwareprobes makket yn-circuit-debugtechniken foar FPGA's dramatysk simplifies. Dizze technyk ymplementearre as in Live Probe-funksje op SmartFusion2®SoC FPGA- en IGLOO®2 FPGA-apparaten, foeget tawijde sondelinen ta oan 'e FPGA-stof om de útfier fan elke logyske elemintregisterbit te observearjen. Lykas werjûn yn it blokdiagram yn figuer 4, binne hardwareprobes beskikber yn twa probekanalen A en B.
Selekteare registerútgongen (probepunten), lykas dejinge dy't oan 'e ûnderkant fan' e figuer komt, wurde stjoerd boppe de twa probekanalen en kinne as selekteare wurde tapast op it A- as B-kanaal. Dizze real-time kanaalsinjalen kinne dan wurde stjoerd nei tawijde Probe A- en Probe B-pins op it apparaat. De sonde A- en sonde B-sinjalen kinne ek yntern wurde trochstjoerd nei in ynbêde logyske analysator.
Tink derom dat de timing skaaimerken fan 'e sonde pins binne regelmjittich en hawwe negligible ôfwiking fan de iene sonde punt nei in oare, wêrtroch't it folle makliker te ferlykje timing skaaimerken fan de real-time sinjalen. Gegevens kinne wurde fêstlein op maksimaal 100MHz, wêrtroch it passend is foar de mearderheid fan doelûntwerpen.
Miskien it wichtichste is dat de lokaasjes fan de sondepunt, om't se net binne selektearre as ûnderdiel fan it ymplementearre ûntwerp (se wurde selektearre troch tawijd hardware wylst it ûntwerp rint op 'e FPGA), kinne fluch feroare wurde troch gewoan de seleksjegegevens nei it apparaat te stjoeren. Gjin ûntwerp opnij kompilearje en opnij programmearje is nedich.
Om it gebrûk fan 'e Live Probe-mooglikheid noch mear te ferienfâldigjen, hat it assosjearre debug-software-ark tagong ta alle sondesignallokaasjes fia in automatysk oanmakke debug file. Lykas werjûn yn figuer 5, de sinjaal namme kin selektearre út de sinjaal list en tapast op it winske kanaal. Dit kin sels dien wurde wylst it ûntwerp rint, sadat ûndersyksaktiviteit binnen it ûntwerp naadloos en heul effisjint is.
Yn in protte gefallen kin de hardwareprobe-mooglikheid, lykas Live Probe, wurde brûkt yn kombinaasje mei de earder beskreaune ynbêde logika-analysator en de eksterne testtechniken.
Lykas te sjen is yn figuer 6, makket de Live Probe-mooglikheid om sinjalen 'ûnderweis' te selektearjen it mooglik om de sinjalen ûnder observaasje fluch en maklik te feroarjen sûnder dat it ûntwerp opnij kompilearre hoecht te wurden. In eksterne logika-analysator of oscilloscope kin de probede sinjalen maklik observearje, lykas yllustrearre yn it rjochtsboppeste diel fan 'e figuer op' e tawijde probe-útfierpinnen. As alternatyf (of miskien sels neist) kin de ynterne logika-analysator (it ILA Identify-blok, werjûn yn 'e figuer) brûkt wurde om de probepinnen te observearjen. De probesignalen kinne wurde fongen troch de ILA en waarnommen yn it golffoarmfinster. Probelokaasjes kinne wurde feroare sûnder dat it doelûntwerp opnij kompilearre hoecht te wurden.
Tink derom dat de ekstra mooglikheden foar triggering en trace kinne wurde brûkt om sondefunksjonaliteit te ferbetterjen, wêrtroch it maklik is om sels komplekse ûntwerpproblemen te spotten.
Ekstra hardware-debugmooglikheden binne ek beskikber op 'e SmartFusion2 SoC FPGA- en IGLOO2 FPGA-apparaten. Ien fan dizze mooglikheden, Active Probe neamd, kin dynamysk en asynchroon lêze of skriuwe nei elke logyske elemintregisterbit. In skreaune wearde bliuwt foar ien kloksyklus, sadat normale operaasje trochgean kin, wêrtroch it in heul weardefol debugging-ark is. Active Probe is fan bysûnder belang as in rappe observaasje fan in yntern sinjaal winske is (miskien gewoan om te kontrolearjen dat it aktyf is of yn 'e winske steat is, lykas in reset-sinjaal), of as it nedich is om in logyske funksje fluch te testen troch te skriuwen nei in probepunt.
(miskien om in oergong fan in steatmasine te begjinnen troch fluch in ynfierwearde yn te stellen om in kontrôlestreamprobleem te isolearjen).
In oare debugmooglikheid fersoarge troch Microsemi is Memory Debug. Dizze funksje lit de ûntwerper dynamysk en asynchronous lêze of skriuwe nei in selektearre FPGA-stof SRAM-blok. Lykas yllustrearre yn it skermôfbylding fan it Debug-ark (figuer 7), as de ljepper Unthâldblokken selektearre is, kin de brûker it winske ûnthâld selektearje om te lêzen, in momintopname fan it ûnthâld útfiere, ûnthâldwearden wizigje, en dan de wearden weromskriuwe nei it apparaat. Dit kin benammen nuttich wêze foar it kontrolearjen of ynstellen fan gegevensbuffers dy't brûkt wurde yn kommunikaasjepoarten foar berekkeningsrjochte scratch-pad of sels foar koade útfierd troch in ynbêde CPU. Debuggen fan komplekse data-ôfhinklike flaters is folle flugger en makliker as oantinkens sa fluch kinne wurde waarnommen en kontroleare.
Ienris in ûntwerp is debuggen, kin it winsklik wêze om de hardware-debugmooglikheden út te skeakeljen om gefoelige ynformaasje te beskermjen. In oanfaller koe deselde foarsjenningen brûke om krityske ynformaasje út te lêzen of systeemynstellingen te feroarjen dy't maklike tagong ta gefoelige dielen fan it systeem mooglik meitsje kinne. Microsemi hat funksjes tafoege om de ûntwerper it apparaat te befeiligjen neidat debuggen foltôge is. Bygelyksample, tagong ta Live Probe en Active Probe kin wurde beskoattele om folslein útskeakelje de funksje as in mooglike middel fan oanfal (it sels elimineert de mooglikheid fan probe aktiviteit it meitsjen fan alle patroanen yn de oanbod stroom dy't koe wurde brûkt om te besykjen en observearje sonde gegevens yndirekt). As alternatyf kin tagong ta selektearre dielen fan it ûntwerp wurde beskoattele om tagong te foarkommen ta allinich dy seksjes. Dit kin handich wêze as mar in diel fan it ûntwerp feilich moat wêze, wêrtroch de rest fan it ûntwerp noch tagonklik is foar fjildtesten as flateranalyse.
In-Circuit Debug Comparison Chart
No dat in detaillearre review fan de trije wichtichste yn-circuit hardware debug techniken binne beskreaun in gearfetting chart, lykas werjûn yn figuer 8, is makke dat details de ferskate advantages en disadvantages fan elke metoade. Tink derom dat guon techniken kinne wurde brûkt yn gearhing (Live Probe en Internal Logic Analyzer (ILA), lykas Synopsys Identify, bygelyksample), kinne wy de wichtichste sterke en swakke punten fan elke technyk sjen. De kolleksje fan yn-circuit hardware debugmooglikheden (Live Probe, Active Probe, en Memory Debug - kollektyf SmartDebug neamd), binne it swakst yn ferliking mei de oare techniken as it giet om it oantal beskikbere probes (in reade sirkel) en binne swakker as de bêste (giele sirkel) as de fêstlizzende snelheid yn oanmerking nommen wurdt (eksterne testapparatuer kin rapper wêze).
ILA-basearre techniken, lykas Synopsys Identify, binne it swakste yn ferliking mei de oare techniken en as FPGA-boarneeasken wurde beskôge. Eksterne testapparatuer-basearre techniken binne it swakste oer in oantal oerwagings mei kosten, ûntwerptiming-ynfloed, en sondebewegingsoverhead (fanwege de needsaak om it ûntwerp opnij te kompilearjen) de meast lestich. Miskien is de optimale oplossing in kombinaasje fan SmartDebug en ien fan 'e oare techniken, sadat it oantal kanalen swakke fan SmartDebug kin wurde fermindere en it neidiel fan' e sondepuntbewegingtages fan de oare techniken fermindere ek.
Signal Classifications
In nuttich ûnderskied kin makke wurde tusken guon fan 'e meast foarkommende soarten sinjalen en dit kin helpe by it plannen fan in oanpak foar debuggen. BygelyksampDat betsjut dat sinjalen dy't net feroarje, útsein by it opstarten fan it systeem, lykas systeemreset, blokreset of inisjalisaasjeregisters, klassifisearre wurde kinne as statyske sinjalen. Dizze soarten sinjalen wurde it effisjintst tagonklik makke fia in foarsjenning dy't it sinjaal maklik observearje en kontrolearje kin, sûnder in lange rekompilaasjesyklus nedich te hawwen. Active Probe is in poerbêste foarsjenning foar it debuggen fan statyske sinjalen. Op deselde wize kinne sinjalen dy't faker feroarje, mar it grutste part fan 'e tiid noch statysk binne, klassifisearre wurde as pseudo-statysk en wurde se ek it effektyfst debugged mei Active Probe. Sinjalen dy't faak feroarje, lykas kloksinjalen, kinne klassifisearre wurde as dynamysk en binne net sa maklik tagonklik fia Active Probe. Live Probe is in bettere kar foar it observearjen fan dizze sinjalen.
Ienfâldige debug-gebrûk
No't wy in better begryp hawwe fan 'e ferskate yn-circuit-debug-opsjes, litte wy sjen nei in ienfâldige ûntwerpeks.ample om te sjen hoe't dizze techniken prestearje. Figuer 9, lit in ienfâldich FPGA-ûntwerp sjen yn in SmartFusion2 SoC FPGA-apparaat. It Microcontroller Subsystem (MSS) wurdt weromset troch it CoreSF2Reset Soft IP-blok. De yngongen nei dit blok binne de Power On Reset, in User Fabric Reset, en in External Reset. De útgongen binne in reset nei de User Fabric, in MSS reset, en in M3 reset. De flatersymptomen binne dat d'r gjin aktiviteit is op 'e I / O's, hoewol it apparaat de POR-tastân mei súkses útgiet. De trije ferskillende opsjes foar it debuggen fan dizze flater wurde ek yn 'e figuer yllustrearre: De blauwe doaze (labeld ETE) is foar de metoade foar eksterne testapparatuer; de griene doaze (label ILA) is foar de Ynterne Logic Analyzer metoade; en de oranje doaze (label AP) is foar de Aktive Probe metoade. Wy sille oannimme dat de potinsjele oarsaken fan 'e flater ferkeard bewearde reset-ynputen binne nei it CoreSF2Reset Soft IP-blok.
Litte wy no sjen nei it debugproses foar trije fan 'e earder beskreaune yn-circuit-metoaden.
Eksterne Test Equipment
Mei dizze metoade wurdt oannommen dat de testapparatuer beskikber is en net wurdt brûkt troch in projekt mei hegere prioriteit. Derneist is it wichtich om foarút te hawwen pland sadat guon FPGA I / O's beskikber binne en maklik kinne wurde ferbûn mei de testapparatuer. In koptekst hawwe op 'e PCB foar bglample, soe tige nuttich wêze en de tiid minimalisearje dy't bestege wurdt oan it identifisearjen en ferbinen fan in 'wierskynlike fertochte' of de mooglike koartsluting fan pinnen tidens it probearjen. It ûntwerp sil opnij kompilearre wurde moatte om de sinjalen te selektearjen dy't wy ûndersykje wolle. Hopelik sille wy net 'de sipel ôfskilje' en ekstra sinjalen moatte selektearje foar fierder ûndersyk, om't ús earste ûndersyk faak allinich resulteart yn mear fragen. Yn alle gefallen kin it opnij kompilearjen en opnij programmearjen in flinke hoemannichte tiid duorje, en as it resulteart yn timing-oertredings is in opnij ûntwerp fereaske (wy binne allegear bekend mei hoe frustrerend it besykjen om timing-slutingsproblemen op te lossen kin wêze, foaral as jo de ûntwerpwizigingen meitsje om in ûntwerpbug te finen - it heule proses kin minuten oant oeren duorje)! It is ek wichtich om te ûnthâlden dat as it ûntwerp gjin frije brûkers-I/O's hat, dizze metoade net ymplementearre wurde kin. Boppedat is dizze metoade struktureel yndringend foar it ûntwerp - en timing-relatearre bugs kinne ferdwine of weromkomme tusken iteraasjes.
Ynterne Logic Analyzer
Mei dizze metoade moat de ILA wurde ynfoege yn it ûntwerp mei stofboarnen, en moat dan opnij kompilearre wurde. Tink derom dat as de ILA al ynstantiearre is, de sinjalen dy't wy wolle ûndersykje miskien net ynstrumintearre binne, wat ek in opnij kompilearje soe. Dit proses riskearret it feroarjen fan it orizjinele ûntwerp en it skeinen fan timingbeheiningen. As de timing foldien wurdt, moat it ûntwerp opnij programmearre wurde en opnij inisjalisearre. Dit hiele proses kin ferskate minuten of sels oeren duorje as recompile tiden binne lang en meardere passes binne nedich. Dizze oanpak is struktureel yngripend en kin resultearje yn ferlykbere problemen as dy beskreaun by it brûken fan de boppesteande metoade.
Aktive Probe
Mei help fan dizze metoade kin de Aktive Probe wiisd wurde op 'e boarne fan' e ferskate resetsignalen, dy't allegear wurde krigen troch registerútgongen (lykas gewoan is yn elke goede digitale ûntwerppraktyk). De sinjalen wurde selektearre ien op in tiid, út in Active Probe menu werjûn yn figuer 10 hjirûnder. De selekteare sinjaalwearden kinne wurde lêzen en wurde werjûn op it Active Probe-gegevensfinster. Alle misbewearingen wurde maklik identifisearre. Dizze test kin fuortendaliks dien wurde sûnder de needsaak om it apparaat opnij te kompilearjen en te programmearjen en is net struktureel of prosedureel yngripend. It hiele proses duorret mar in pear sekonden. Dizze metoade kin ek kontrolearberens oanmeitsje (wearden asynchronous feroarjen) dy't de oare twa metoaden net tastean. Yn dit bysûndere eksample, de reset sinjaal sourced troch in register kin maklik probed en ûntdutsen wurde holden yn aktive steat.
Momenteel wikseljen fan it reset-sinjaal kin wurde berikt troch asynchronous manipulearjen fan it register dat de restsinjalen genereart.
Mear komplekse debug-gebrûk
It boppesteande ûntwerp wie hiel simpel en is nuttich as in ynlieding ta it brûken fan de beskreaune design techniken, mar in mear komplekse eksample soe noch mear yllustratyf wêze kinne. In protte kearen is it sinjaal fan belang gjin statysk sinjaal sa't it wie yn ús ienfâldige eksample mar is dynamysk. In mienskiplik dynamysk sinjaal is in tuskenlizzende klok, faaks brûkt foar timing in handshake foar in serial ynterface. figuer 11 toant sa'n ûntwerp mei de brûker Soft IP kearn, yn dit gefal, in oanpaste serial ynterface ferbûn mei it systeem APB bus. De flaters symptomen binne dat der gjin aktiviteit op de brûkers oanpaste serial ynterface, en dat as in APB bus master jout in transaksje foar tagong ta de serial ynterface it giet yn in útsûndering betingst wat oanjout in ferkearde handshake. Dizze betingsten lykje in statyske oarsaak út te sluten, lykas in ferkeard reset-sinjaal, om't de transaksjestatemasine net liket te wurkjen op it ferwachte taryf en dus de útsûndering feroarsaket. De woartel oarsaak wurdt nei alle gedachten de klok frekwinsje generator binnen de brûker IP kearn.
As it net op de juste frekwinsje rint, soene de beskreaune flaters resultearje.
Yn dizze situaasje is it wierskynlik in bettere strategy om de Active Probe-oanpak te ferfangen mei de Live Probe. Dit wurdt yn 'e boppesteande figuer yllustrearre troch it oranje kleurde LP-doaze, mei de JTAG sinjaal foar de sonde boarne seleksje.
Eksterne Test Equipment
Foar dit gefal is de metodyk tige ferlykber mei de earder beskreaune ienfâldige eksample. De brûker klok sinjaal wurdt brocht út nei it test punt (hooplik op in koptekst) en in tiid tiidslinend recompile is nedich. It kin ek nuttich wêze om in referinsjesinjaal út te bringen, miskien in systeemklok dy't wurdt brûkt om de brûkers IP te klokken as in fergelikingssinjaal. Wy sille wer ûnderwurpen wurde oan de needsaak om opnij te kompilearjen en opnij te programmearjen, sadat it heule proses in signifikante tiid kin nimme.
Ynterne Logic Analyzer
Dit gefal is heul gelyk oan 'e ienfâldige eksample. De ILA moat wurde ynfoege, of it winske sinjaal definiearre, en in recompile en reprogramming syklus útfierd. Alle earder beskreaune problemen resultearje noch yn in wichtige debug-syklustiid. D'r is lykwols in ekstra kompleksiteit. De klok dy't de ILA driuwt moat syngroan wêze, en by útstek folle flugger mei respekt foar de klok dy't moat wurde waarnommen fan 'e brûker Soft IP-kearn. As dizze klokken asynchronous binne, of net de juste timingrelaasjes hawwe, sil gegevensopfang ûnfoarspelber wêze en in mooglike boarne fan betizing foar it debugproses.
Tink derom dat as de brûker Soft IP-klok wurdt net oanmakke on-chip (miskien wurdt hersteld út de seriële ynterface) de ûntwerper kin moatte tafoegje in klok module foar in generearje in flugger ILA klok mei help fan ekstra middels en mooglik meitsje in timing oertreding.
Live Probe
Mei dizze metoade kin de Live Probe fluch oanwiisd wurde op 'e boarne fan' e brûkersklok en elke oare klokboarne fan in register om de woartel oarsaak fan 'e flater te jagen. De Live Probe sil de selekteare sinjaalútgongen yn realtime sjen litte en elke timingrelaasje tusken de sinjalen is dus folle makliker te bepalen. It hiele proses duorret mar in pear sekonden.
Oare debugfunksjes foar serial ynterfaces
It is ek wichtich om te wizen dat d'r in protte ekstra debugmooglikheden binne yn SmartFusion2 SoC FPGA- en IGLOO2 FPGA-apparaten dy't kinne wurde brûkt op seriële ynterfaces, lykas dy yn 'e foarige eks.ample ûntwerp dêr't flaters binne noch mear yngewikkelder. SERDES Debug, bygelyksample, jout spesifike debug mooglikheden foar de tawijd hege-snelheid serial Schnittstellen. Guon fan 'e SERDES Debug-funksjes omfetsje PMA-teststipe (lykas PRBS-patroangeneraasje en loopback-testen) stipe foar meardere SERDES-testkonfiguraasjes mei rekonfiguraasje op registernivo om it gebrûk fan 'e folsleine ûntwerpstream te foarkommen om konfiguraasjewizigingen te meitsjen, en tekstrapporten dy't konfigureare protokollen sjen litte, SERDES-konfiguraasjeregisters, en Lane-konfiguraasjeregisters. Dizze funksjes meitsje SERDES-debuggen folle makliker en kinne brûkt wurde yn kombinaasje mei Live Probe en Active Probe om fierdere fluggens fan debuggen fan komplekse circuits te meitsjen.
De earder beskreaune Memory Debug-tool kin ek brûkt wurde yn kombinaasje mei SERDES Debug om testen te fersnellen. Om't ûnthâldbuffers fluch en maklik ynspektearre en feroare wurde kinne mei Memory Debug, is it mooglik om fluch 'testpakketten' te meitsjen en loopback- of yntersysteemkommunikaasjeresultaten te observearjen. De ûntwerper kin dizze mooglikheden brûke en sa de needsaak foar spesjalisearre 'testharnassen' minimalisearje dy't ekstra FPGA-fabric ferbrûke en dy't ynfloed hawwe kinne op 'e chiptiming.
Konklúzje
Dit artikel hat yn detail ferskate oanpakken beskreaun foar it ymplementearjen fan in-circuit debug foar FPGA's en SoC FPGA's - it gebrûk fan in Integrated Logic Analyzer, it gebrûk fan eksterne testapparatuer, en it gebrûk fan tawijde probesirkwy's yntegrearre yn 'e FPGA-fabriek. De tafoeging fan spesjalisearre en tawijde probesirkwy's, lykas Active Probe en Live Probe oanbean troch Microsemi op SmartFusion2 SoC FPGA- en IGLOO2 FPGA-apparaten, die bliken it debugproses signifikant te fersnellen en te ferienfâldigjen. De mooglikheid om de seleksje fan ynterne sinjalen fluch te wizigjen (sûnder de needsaak om in heul tiidslinende rekompilaasje- en opnij programmearringssyklus út te fieren), en de mooglikheid om ynterne sinjalen te probearjen (sûnder de needsaak om FPGA-fabriek te brûken en potinsjeel timingoertredings yn te fieren) die bliken in grut foardiel te wêzen.tages by it debuggen fan FPGA-ûntwerpen. Derneist waard it gebrûk fan meardere metoaden beskreaun, dy't gearwurkje kinne om in noch wiidweidigere debugmooglikheid te leverjen. Ta beslút, twa eksample debug gebrûk gefallen waarden jûn te yllustrearjen de trade-offs tusken de beskreaun metoaden.
Om mear te learen
- IGLOO2 FPGA's
- SmartFusion2 SoC FPGA's
Microsemi Corporation (Nasdaq: MSCC) biedt in wiidweidige portefúlje fan semiconductor- en systeemoplossingen foar kommunikaasje, definsje en feiligens, loftfeart en yndustriële merken. Produkten befetsje hege-optreden en strieling-ferhurde analoge mingd-sinjaal yntegrearre circuits, FPGAs, SoCs en ASICs; produkten foar enerzjybehear; timing- en syngronisaasjeapparaten en krekte tiidoplossingen, it ynstellen fan 'e wrâldstandert foar tiid; apparaten foar stimferwurking; RF oplossings; diskrete komponinten; feiligens technologyen en scalable anty-tamper produkten; Power-over-Ethernet IC's en midspans; lykas oanpaste ûntwerpmooglikheden en tsjinsten. Microsemi hat syn haadkantoar yn Aliso Viejo, Kalifornje, en hat sawat 3,400 meiwurkers wrâldwiid. Lear mear op www.microsemi.com.
© 2014 Microsemi Corporation. Alle rjochten foarbehâlden. Microsemi en it Microsemi-logo binne hannelsmerken fan Microsemi Corporation. Alle oare hannelsmerken en tsjinstmerken binne it eigendom fan har respektive eigners.
Microsemi Corporate Headquarters
- Ien Enterprise, Aliso Viejo CA 92656 Feriene Steaten
- Binnen de Feriene Steaten: +1 800-713-4113
- Bûten de Feriene Steaten: +1 949-380-6100
- Ferkeap: +1 949-380-6136
- Fax: +1 949-215-4996
- E-post: sales.support@microsemi.com
FAQ
- F: Wat is de maksimale gegevensopfangfrekwinsje fan it apparaat?
A: It apparaat stipet gegevensopname oant 100 MHz, geskikt foar de measte doelûntwerpen. - F: Moat ik it ûntwerp opnij kompilearje by it brûken fan sondekringen foar debuggen?
A: Nee, de lokaasjes fan sondepunten kinne fluch feroare wurde sûnder dat it ûntwerp opnij kompilearre of opnij programmearre hoecht te wurden.
Dokuminten / Resources
 |
Microsemi In-Circuit FPGA Debug [pdfYnstruksjes In-Circuit FPGA Debug, FPGA Debug, Debug |
