Microsemi In-Circuit FPGA Debug

Impormasyon ng Produkto

Mga pagtutukoy

• Uri ng Device: Microsemi SmartFusion2 SoC FPGA
• Petsa ng Paglabas: Mayo 2014
• Mga Kakayahan sa Pag-debug: In-Circuit FPGA Debug, Naka-embed na Logic Analyzer
• Pinakamataas na Dalas ng Pagkuha ng Data: Hanggang 100MHz

Abstract
Ang mga FPGA ay makapangyarihang elemento ng disenyo sa mga naka-embed na system na may maraming advan sa disenyotages, ngunit ang mga device na ito ay maaaring magkaroon ng mga kumplikadong disenyo na may mga kumplikadong isyu sa disenyo na kailangang i-debug. Ang pagsubaybay sa mga isyu sa disenyo tulad ng mga error sa kahulugan, mga problema sa pakikipag-ugnayan ng system, at mga error sa timing ng system ay maaaring maging isang hamon. Ang pagsasama ng mga in-circuit debug na kakayahan sa isang FPGA ay maaaring kapansin-pansing mapabuti ang hardware debug, at maiwasan ang mga oras ng pagkadismaya ng countess. Inilalarawan ng papel na ito ang ilang iba't ibang diskarte sa in-circuit debug para sa mga FPGA, kinikilala ang mga pangunahing trade-off, at sa pamamagitan ng isang exampAng disenyo, na naka-target para sa isang Microsemi SmartFusion®2 SoC FPGA device, ay magpapakita kung paano magagamit ang mga bagong kakayahan upang mapabilis ang pag-debug at pagsubok.

Panimula

Ang mga FPGA ay malaganap at makapangyarihang mga elemento ng disenyo at ngayon ay matatagpuan sa halos lahat ng naka-embed na sistema. Sa pagtaas ng kapasidad, ang pagsasama ng mga kumplikadong on-chip functional block at advanced na serial interface ay maaari ding magkaroon ng mga kumplikadong problema sa disenyo ang mga device na ito na kailangang i-debug. Ang pagsubaybay sa mga isyu gaya ng mga error sa functional definition (sa antas ng FPGA o system), mga problema sa pakikipag-ugnayan sa functional system, mga isyu sa timing ng system, at mga isyu sa fidelity ng signal sa pagitan ng mga IC (tulad ng ingay, crosstalk, o reflection) ay nagiging mas kumplikado kapag gumagamit ng mga advanced na FPGA. Tiyak na malaking tulong ang simulation sa pagtukoy ng maraming problema sa disenyo, ngunit maraming totoong pakikipag-ugnayan sa mundo ang hindi lalabas hanggang sa maipatupad ang disenyo sa hardware. Maraming iba't ibang mga diskarte para sa pag-debug ng mga kumplikadong isyu sa disenyo ay binuo upang pasimplehin ang proseso. Isang maingat na pag-unawa sa bawat isa sa mga pangunahing pamamaraan na ito, kabilang ang iba't ibang advantages at disadvantages, ay kapaki-pakinabang kapag isinasaalang-alang kung aling pamamaraan o kumbinasyon ng mga diskarte ang angkop para sa isang partikular na disenyo.
Isang datingampAng disenyo ng FPGA, na naka-target para sa isang Microsemi SmartFusion2 SoC FPGA device, ay maaaring gamitin upang ipakita ang ilan sa mga advantages at disadvantagng mga karaniwang diskarteng ito pati na rin ang mga pinakabagong in-circuit na kakayahan sa pag-debug. Itong naglalarawang exampIpapakita nito kung paano magagamit ang iba't ibang pamamaraan na ito upang mapabilis ang pagkilala at pag-alis ng mga problema sa hardware sa panahon ng pag-debug ng hardware.

Bakit ang FPGA Debugging ay isang Kritikal na Aspeto ng Disenyo at Pagbuo ng System?
Ang mga FPGA ay may dalawang pangunahing modelo ng paggamit na nagpapaiba sa kanila mula sa iba pang mga elemento ng disenyo. Ang mga FPGA ay maaaring gamitin sa produksyon ng produkto o maaaring gamitin bilang isang development vehicle upang patunayan o prototype ang isang production design concept. Kapag ginamit bilang sasakyan sa produksyon, ang mga FPGA ay maaaring maging isang mas nababaluktot na target kaysa sa ASIC o mga sasakyang pang-produksyon na nakabatay sa CPU. Ito ay partikular na mahalaga para sa isang bagong disenyo, isa na hindi pa naipapatupad sa hardware. Ang mga disenyo na may iba't ibang opsyon sa arkitektura ay madaling magawa at masuri upang matukoy ang pinakamainam na disenyo. Ginagawang posible rin ng mga FPGA na may mga on-chip processor (SoC FPGAs) na i-trade-off ang pagpoproseso na nakabatay sa CPU gamit ang mga function ng acceleration na nakabatay sa FPGA na tinutulungan ng hardware. Ang mga advan na itotagAng mga ito ay maaaring makabuluhang bawasan ang oras na kinakailangan para sa disenyo, pagpapatunay, pagsubok, at pagsusuri ng pagkabigo para sa mga bagong pagpapaunlad ng produkto.
Kapag ginamit para sa prototyping ng isang disenyo, marahil para sa isang produksyon ASIC, FPGA flexibility ay isang pangunahing benepisyo. Ang isang aktwal na platform ng hardware, kahit na hindi tumatakbo sa buong bilis, ay ginagawang mas madali upang makakuha ng mga detalyadong sukatan ng pagganap ng system, data ng pagsusuri sa throughput at mga resulta ng patunay ng konsepto ng arkitektura. Ang suporta ng FPGA para sa mga hardened na pagpapatupad ng mga standard na bus sa industriya (tulad ng PCIe®, Gigabit Ethernet, XAUI, USB, CAN, at iba pa) ay pinapasimple ang pagsubok na nauugnay sa mga interface na ito. Ang pinakabagong mga pamilya ng mga FPGA na may mga on-chip na ARM processor (SoC FPGAs), ay nagpapadali sa pag-prototype ng mga pagpapatupad na may mga naka-embed na processor. Ang dating binuong processor code ay maaaring i-port sa prototype at bagong code na nilikha kasabay ng pagsisikap sa disenyo ng hardware.

Ginagawang posible ng kumbinasyong ito ng karaniwang processor na may mga karaniwang interface bus na magamit ang malaking ecosystem ng mga available na library ng code, driver, functional API, Real Time Operating System, at maging ang buong Operating System para mas mabilis na makagawa ng gumaganang prototype. Bukod pa rito, kapag natibay na ang disenyo, maaaring gamitin ang prototype ng FPGA para kumuha ng mga malawak na hanay ng pagsubok ng simulation (para sa parehong stimulus at tugon) na sumasalamin sa aktwal na data ng system. Ang mga data set na ito ay maaaring maging napakahalaga sa paggawa ng mga huling simulation para sa isang ASIC o iba pang pagpapatupad ng produksyon. Ang advantagAng paggamit ng FPGA bilang isang prototype ng disenyo ay maaaring makabuluhang bawasan ang oras para sa disenyo, pagpapatunay, pagsubok, at pagsusuri ng pagkabigo para sa huling pagpapatupad ng produkto.
Sa parehong mga karaniwang modelo ng paggamit ng FPGA, ang flexibility ng FPGA bilang target ng disenyo ay isang pangunahing advan.tage. Nangangahulugan ito na maraming pagbabago sa disenyo at pag-ulit ang magiging karaniwan, at sa gayon ang kakayahang mabilis na i-debug ang mga error sa disenyo ay magiging kritikal sa pagpapagana ng maraming mga pagpipilian sa disenyo hangga't maaari. Kung walang mahusay na kakayahan sa pag-debug ng karamihan sa advantage ng FPGA design flexibility ay mababawasan ng karagdagang oras ng pag-debug na kinakailangan. Sa kabutihang-palad, ang mga FPGA ay maaari ding magbigay ng mga karagdagang feature ng hardware na kapansin-pansing nagpapasimple sa real-time na pag-debug. Bago tingnan ang mga kakayahan na ito, tingnan muna natin ang mga pinakakaraniwang uri ng mga isyu na maaaring harapin ng isang disenyo ng FPGA upang magkaroon tayo ng tamang background upang suriin ang kahusayan at ang nauugnay na mga trade-off ng iba't ibang mga tool sa pag-debug.

Mga Karaniwang Isyu Kapag Nagde-debug ng Mga Disenyo ng FPGA

Kasama ng mga pinalawak na kakayahan na dinadala ng mga modernong FPGA, ang nauugnay na pagtaas ng pagiging kumplikado ay nagpapahirap sa paggawa ng mga disenyong walang error. Sa katunayan, tinatantya na ang pag-debug ay maaaring tumagal ng higit sa 50% ng ikot ng disenyo ng naka-embed na system. Sa mga panggigipit sa oras-sa-market na patuloy na pumipiga sa ikot ng pag-unlad, ang pag-debug ng hardware ng paunang sistema ay ibinabalik sa isang nahuling pag-iisip—madalas na ipinapalagay na ang pag-verify na iyon (mismo ay isang malaking porsyentotage ng iskedyul ng pag-unlad), sasaluhin ang lahat ng mga bug bago ang paunang paglabas ng system. Tingnan natin ang ilang karaniwang uri ng mga isyu sa system para mas maunawaan ang mga hamon na kakaharapin ng isang tipikal na disenyo sa panahon ng paunang pagpapalabas ng system.

Ang mga error sa functional na kahulugan ay maaaring dobleng mahirap hanapin dahil hindi naintindihan ng taga-disenyo ang isang partikular na pangangailangan, kaya't ang error ay maaaring hindi mapansin kahit na tinitingnang mabuti ang mga detalye ng disenyo. Isang exampAng isang karaniwang error sa pagtukoy sa pagganap ay kung saan ang paglipat ng makina ng estado ay hindi napupunta sa tamang estado. Ang mga error ay maaari ding lumabas sa mga interface ng system bilang isang problema sa pakikipag-ugnayan. Interface latency, halample, ay maaaring maling tinukoy na nagreresulta sa isang hindi inaasahang buffer overflow o underflow na kundisyon.
Ang mga isyu sa timing sa antas ng system ay isa pang napakakaraniwang pinagmumulan ng mga error sa disenyo. Ang mga asynchronous na kaganapan, sa partikular, ay karaniwang pinagmumulan ng mga error kapag hindi maingat na isinasaalang-alang ang pag-synchronize o crossing timing domain effects. Kapag tumatakbo nang mabilis ang mga ganitong uri ng mga error ay maaaring maging napakaproblema at maaaring magpakita nang napakadalas, marahil lamang kapag ang mga partikular na pattern ng data ay nagpapakita mismo. Maraming mga karaniwang paglabag sa timing ang nabibilang sa kategoryang ito at kadalasan ay napakahirap, kung hindi imposibleng gayahin.

Ang mga paglabag sa timing ay maaari ding resulta ng mababang signal fidelity sa pagitan ng mga integrated circuit, lalo na sa mga system na may maraming power rails para sa bawat circuit. Ang mababang signal fidelity ay maaaring magresulta sa ingay ng signal, crosstalk, reflection, labis na pag-load at mga isyu sa Electro-Magnetic Interference (EMI) na kadalasang lumalabas bilang mga paglabag sa timing. Ang mga isyu sa power supply, tulad ng mga lumilipas (lalo na sa panahon ng system start-up o shut-down), ang mga variation ng load at high power dissipation stresses ay maaari ding magresulta sa mga mahiwagang error, kadalasang hindi madaling ma-trace pabalik sa pinagmumulan ng power supply. Kahit na ang disenyo ay ganap na tama ang mga isyu sa paggawa ng board ay maaaring magresulta sa mga pagkakamali. Mga sira na solder joint at hindi wastong pagkakabit ng mga connector, halample, ay maaaring pagmulan ng mga error at maaaring maging depende sa temperatura o lokasyon ng board. Ang paggamit ng mga advanced na diskarte sa packaging ng FPGA ay maaaring maging mahirap na suriin ang mga signal sa naka-print na circuit board, kaya ang pagkuha lamang ng access sa isang nais na signal ay kadalasang nagiging problema. Kadalasan maraming mga isyu sa disenyo ang hindi lumilikha ng isang agarang error at dapat na magulo sa disenyo hanggang sa ang error ay aktwal na magpakita mismo. Ang pagsubaybay sa panimulang error pabalik sa ugat na sanhi ay kadalasang isang nakakabigo, mahirap at nakakaubos ng oras na gawain.

Para kay exampOo, ang isang maliit na mali sa isang talahanayan ng pagsasalin ay maaaring hindi magresulta sa isang error hanggang sa maraming mga cycle mamaya. Ang ilan sa mga tool na tatalakayin natin mamaya sa papel na ito, na gumagamit ng dedikadong in-circuit debug hardware, ay partikular na naka-target sa paggawa ng mga 'bug hunts' na ito nang mas mabilis at mas madali. Bago ang mga detalye ng mga tool na ito, tingnan muna natin ang isang sikat na software-based debugging technique simulation para mas maunawaan ang advantages at disadvantages ng paggamit ng simulation para sa pag-debug.

Paggamit ng Simulation para sa Pag-debug
Karaniwan sa isang simulation ng disenyo, ang lahat ng bahagi ng totoong buhay sa loob at labas ng disenyo ay namodelo sa matematika bilang mga proseso ng software na sunud-sunod na isinasagawa sa isang karaniwang CPU. Ang paglalapat ng malawak na hanay ng stimulus sa disenyo at pagsuri sa inaasahang output laban sa simulate na output ng mga disenyo, ay isang madaling paraan upang mahuli ang karamihan sa mga mali sa disenyo. Ang isang window na nagpapakita ng isang tipikal na simulation run ay ibinigay sa Figure 1 sa ibaba. Ang malinaw na advantage ng simulation verses hardware-based debugging, ay ang simulation ay maaaring gawin sa software—walang aktwal na hardware-based na disenyo at testbench ang kailangan. Mabilis na mahuhuli ng simulation ang maraming error sa disenyo, lalo na ang mga nauugnay sa maling mga detalye, hindi pagkakaunawaan sa mga kinakailangan sa interface, mga error sa pag-andar, at marami pang ibang 'gross' na uri ng mga error na madaling matukoy sa pamamagitan ng mga simpleng stimulus vectors.

Ang simulation ay partikular na epektibo kapag ang malawak na mga kumbinasyon ng pampasigla ay magagamit sa taga-disenyo at ang mga resultang output ay kilala. Sa mga kasong ito, ang simulation ay maaaring gumawa ng halos kumpletong pagsubok ng isang disenyo. Sa kasamaang-palad, karamihan sa mga disenyo ay walang madaling pag-access sa mga malawak na suite ng pagsubok at ang proseso ng paggawa ng mga ito ay maaaring masyadong matagal. Ang paglikha ng isang test suite na sumasaklaw sa 100% ng disenyo ay halos imposible para sa malalaking FPGA-based na mga disenyo at ang mga short cut ay dapat gamitin upang subukan at masakop ang mga pangunahing elemento ng disenyo. Ang isa pang kahirapan sa simulation, ay hindi ito isang 'tunay na mundo' na pagpapatupad at hindi mahuli ang mga asynchronous na kaganapan, mabilis na pakikipag-ugnayan ng system, o mga paglabag sa timing. Sa wakas, ang proseso ng simulation ay maaaring maging napakabagal at kung maraming pag-ulit ang kinakailangan, ang simulation ay mabilis na nagiging pinaka-ubos ng oras, at kadalasan ang pinakamahal na bahagi ng proseso ng pagbuo.

Bilang alternatibo (o marahil mas mainam na sabihin, bilang karagdagan sa simulation) natuklasan ng mga taga-disenyo ng FPGA na maaari silang magdagdag ng debug hardware sa disenyo ng FPGA upang maobserbahan at makontrol ang mga pangunahing signal sa loob ng device. Ang mga diskarteng ito ay orihinal na binuo bilang ad-hoc approach, ngunit unti-unting naging isang karaniwang diskarte sa pag-debug ng hardware. Ang paggamit na ito ng mga in-circuit debug na kakayahan ay nag-aalok ng makabuluhang advantages para sa mga disenyong nakabatay sa FPGA at ang susunod na seksyon ay tuklasin ang tatlong pinakakaraniwang mga diskarte at ang kanilang iba't ibang advantages at disadvantages.

Mga Karaniwang In-Circuit Debug Approaches para sa mga FPGA
Ang pinakakaraniwang mga diskarte sa pagpapatupad ng mga kakayahan sa in-circuit debug sa mga FPGA ay gumagamit ng alinman sa naka-embed na logic analyzer, panlabas na kagamitan sa pagsubok, o nakalaang signal probe hardware na naka-embed sa loob ng FPGA fabric. Ang naka-embed na logic analyzer ay karaniwang ipinapatupad gamit ang FPGA fabric at ipinapasok sa disenyo. Ang JTAG port ay ginagamit upang ma-access ang analyzer at ang nakuhang data ay maaaring ipakita sa isang PC. Kapag ginamit ang panlabas na kagamitan sa pagsubok, ang disenyo ng FPGA sa ilalim ng pagsubok ay binago upang ang mga napiling panloob na signal ng FPGA ay iruruta sa mga output pin. Ang mga pin na ito ay maaaring maobserbahan sa pamamagitan ng panlabas na kagamitan sa pagsubok. Kapag ginamit ang dedikadong signal probe hardware, isang malawak na seleksyon ng mga panloob na signal ang mababasa sa real time. Ang ilang mga pagpapatupad ng probe ay maaari pang gamitin upang magsulat upang magparehistro o mga lokasyon ng memorya na higit na nagpapahusay sa mga kakayahan sa pag-debug. Tingnan natin nang mas detalyado sa advantages at disadvantagng bawat isa sa mga diskarteng ito at pagkatapos ay tumingin sa isang datingampang disenyo upang makita kung paano makakaapekto ang iba't ibang diskarte na ito sa pangkalahatang oras ng pag-debug.

In-Circuit FPGA Debug-Embedded Logic Analyzer
Ang konsepto ng naka-embed na logic analyzer ay direktang resulta ng ad-hoc in-circuit debugging na mga kakayahan na ipinatupad ng mga designer noong unang ginamit ang mga FPGA. Ang mga naka-embed na logic analyzer ay nagdagdag ng mga bagong kakayahan at inalis ang pangangailangan para sa designer na bumuo ng kanilang sariling analyzer. Karamihan sa mga FPGA ay nag-aalok ng mga kakayahan na ito at ang mga third party ay nag-aalok ng mga karaniwang analyzer (Identify®, mula sa Synopsys, ay isang sikat na example) na madaling makipag-interface sa mga mas mataas na antas ng mga tool upang higit pang mapabuti ang pagiging produktibo.

Ang pag-andar ng logic analyzer ay ipinasok sa disenyo, gamit ang tela ng FPGA at naka-embed na mga bloke ng memorya bilang mga trace buffer, gaya ng inilalarawan sa Figure 2. Nililikha din ang mga mapagkukunan ng pag-trigger upang madaling mapili at makuha ang mga kumplikadong pakikipag-ugnayan ng signal. Ang pag-access sa analyzer para sa kontrol at paglipat ng data ay karaniwang ginagawa sa pamamagitan ng karaniwang JTAG port upang gawing simple ang mga kinakailangan sa interface. Maaaring ipakita ang nakuhang data sa isang PC gamit ang common viewsoftware at karaniwang sumasalamin sa output ng waveform ng logic simulator viewestilo.

Ang advantages ng diskarteng ito ay walang karagdagang FPGA I/O pin ang ginagamit, ang karaniwang JTAG mga senyales. Ang naka-embed na logic analyzer IP core ay karaniwang medyo mura at sa ilang mga kaso ay maaaring isang opsyon sa umiiral na FPGA synthesis, o mga tool sa simulation. Sa ilang mga kaso, ang naka-embed na logic analyzer ay maaari ding magbigay ng mga karagdagang output sa hindi nagamit na I/Os, kung ito ay mas maginhawa. Isa sa disadvantages sa diskarteng ito ay ang isang malaking halaga ng mga mapagkukunan ng FPGA ay kinakailangan. Sa partikular, kung gagamitin ang mga trace buffer, mababawasan nito ang bilang ng mga block memory na magagamit. Kung kailangan ng malawak na buffer, ito rin ay isang trade-off laban sa lalim ng memorya (dahil ang paggamit ng mas malawak na memorya ay nagreresulta sa mas mababaw na lalim ng memorya)—isang malaking disadvantage kapag gumagamit ng mas maliliit na device. Marahil ang pinakamalaking disbentaha sa pamamaraang ito ay ang bawat oras na ang isang pagsasaayos sa probe placement ay ginawa, ito ay kinakailangan upang i-recompile at i-reprogram ang disenyo. Kapag gumagamit ng isang malaking aparato, ang prosesong ito ay maaaring tumagal ng maraming oras. Dahil sa paraan ng paglalagay ng mga signal probe sa disenyo, maaaring mahirap iugnay ang mga relasyon sa timing ng signal. Bilang karagdagan, ang mga pagkaantala sa pagitan ng mga signal probe ay hindi pare-pareho at sa gayon ang mga relasyon sa timing ay mahirap ihambing. Ito ay isang partikular na kahirapan kapag naghahambing ng mga asynchronous na signal o signal mula sa iba't ibang mga domain ng oras.

In-Circuit FPGA Debug – External Test Equipment
Ang paggamit ng in-circuit debug code kasabay ng panlabas na kagamitan sa pagsubok ay isang natural na pag-unlad kapag ang isang panlabas na logic analyzer ay magagamit na para sa pagsubok ng system. Sa pamamagitan ng paglikha ng ilang simpleng debug code upang matukoy at pumili ng mga panloob na signal ng pagsubok at ilapat ang mga ito sa FPGA I/Os, tulad ng ipinapakita sa Figure 3, naging posible na gamitin ang mga advanced na kakayahan ng mga analyzer (gaya ng malalaking trace buffer, kumplikadong mga sequence ng pag-trigger, at maramihang viewmga opsyon) upang lumikha ng simple ngunit makapangyarihang mga kapaligiran sa pag-debug. Ang mga mas kumplikadong in-circuit na kakayahan para sa mga advanced na opsyon sa pag-trigger ay maaaring mabawasan ang bilang ng mga kinakailangang output. Para kay exampSa gayon, ang pagpili ng mga partikular na address sa isang malawak na bus ay maaaring maging hadlang kung kinakailangan ang mga panlabas na pin.
Ang paggamit ng panloob na lohika ng FPGA ay kapansin-pansing binabawasan ang mga kinakailangan sa I/O at maaari pang maghanap ng mga partikular na pattern ng address (marahil isang pagkakasunud-sunod ng tawag at pagbabalik) para sa pag-debug ng mas kumplikadong mga problema. Kung available ang isang karaniwang user interface, maaari nitong gawing simple ang curve ng pagkatuto at mapahusay ang pagiging produktibo.

Ang advantagAng mga layunin ng diskarteng ito ay ang paggamit nito sa gastos ng panlabas na kagamitan sa pagsubok at sa gayon ay walang karagdagang gastos sa tool. Ang ilang mga debug circuit IP core ay makukuha mula sa mga tagagawa ng kagamitan o mga tagagawa ng FPGA, at maaaring napakababa ng gastos o kahit na libre. Ang halaga ng mga mapagkukunan ng FPGA na kinakailangan upang ipatupad ang lohika ng pagpili ng signal ay napakaliit, at dahil ang trace function ay ginagawa gamit ang external logic analyzer, walang block memory ang kailangan. Dahil ang lohika ng pagpili ay mura, ang isang malaking bilang ng mga channel na may malawak na pag-trigger ay maaari ding suportahan. Ang logic analyzer ay maaaring gumana sa parehong Timing mode at State mode na tumutulong na ihiwalay ang ilang isyu sa timing.
Ang disadvantagMaaaring kasama sa mga ito ng diskarte ang pangangailangang bumili ng logic analyzer, kung ang isa ay hindi pa nakalaan sa proyekto. Ang disadvan na itotage maaaring sapat na upang pigilan ang diskarteng ito sa maraming pagkakataon. Tandaan gayunpaman, na ang ilang murang opsyon sa logic analyzer ay nagiging available na gumagamit ng PC o isang tablet para ipakita, na ginagawang mas cost-effective ang opsyong ito para sa mga simpleng kinakailangan sa pag-debug.
Ang bilang ng mga FPGA pin na natupok ay maaaring isa pang disadvantage at kung kailangang obserbahan ang malalawak na bus, kailangan ang makabuluhang pagpaplano para sa layout ng board at ang pagdaragdag ng mga debug connector. Ang pangangailangang ito ay kadalasang mahirap hulaan nang maaga sa yugto ng disenyo at isa pang hindi gustong kumplikado. Katulad ng diskarte sa naka-embed na logic analyzer, ang diskarte sa panlabas na pagsubok ay nangangailangan ng muling pag-compile at reprogramming ng isang disenyo, kapag kailangan ang bawat bagong eksperimento.

Ang karaniwang disadvantages ng dalawang diskarteng ito—ang paggamit ng mga on-chip na mapagkukunan (na maaari ring makaapekto sa pagganap ng timing ng disenyo at lumikha ng mga karagdagang kinakailangan sa pag-debug) ang pangangailangan na muling i-compile at i-reprogram ang disenyo (na maaaring magdagdag ng mga oras o kahit na araw sa iskedyul ng pag-debug) ang paunang pagpaplano na kinakailangan para sa pagtukoy ng mga posibleng pagsubok na sitwasyon, at ang paggamit ng karagdagang mga mapagkukunan ng chip I/O ay lumikha ng pangangailangan para sa isang diskarte nang wala itong mga kakulangan. Ang isang tugon ay ang pagdaragdag ng dedikadong debug logic sa FPGA fabric sa ilang device. In-circuit debug gamit ang hardware probes ang resulta.

In-Circuit FPGA Debug – Mga Probe ng Hardware
Ang paggamit ng mga hardware probes ay kapansin-pansing pinapasimple ang mga in-circuit debug techniques para sa mga FPGA. Ang diskarteng ito ay ipinatupad bilang tampok na Live Probe sa SmartFusion2®SoC FPGA at IGLOO®2 FPGA device, nagdaragdag ng mga dedikadong probe lines sa FPGA fabric upang obserbahan ang output ng anumang logic element register bit. Tulad ng ipinapakita sa block diagram sa Figure 4, ang mga hardware probes ay magagamit sa dalawang probe channels A at B.

Ang mga napiling output ng rehistro (mga probe point), tulad ng isang pinanggalingan sa ibaba ng figure, ay iruruta sa itaas ng dalawang probe channel at kung pinili ay maaaring ilapat sa alinman sa A o B channel. Ang mga real-time na signal ng channel na ito ay maaaring ipadala sa mga nakalaang Probe A at Probe B pin sa device. Ang mga signal ng Probe A at Probe B ay maaari ding i-ruta sa loob sa isang naka-embed na logic analyzer.

Tandaan na ang mga katangian ng timing ng mga probe pin ay regular at may hindi gaanong paglihis mula sa isang probe point patungo sa isa pa, na ginagawang mas madaling ihambing ang mga katangian ng timing ng mga real-time na signal. Maaaring makuha ang data nang hanggang 100MHz na ginagawa itong angkop para sa karamihan ng mga target na disenyo.
Marahil ang pinakamahalaga ay ang mga lokasyon ng probe point, dahil hindi sila pinili bilang bahagi ng ipinatupad na disenyo (pinili sila sa pamamagitan ng dedikadong hardware habang tumatakbo ang disenyo sa FPGA), ay maaaring mabilis na mabago sa pamamagitan lamang ng pagpapadala ng data ng pagpili sa device. Walang kinakailangang recompile at reprogramming ng disenyo.
Upang mas pasimplehin ang paggamit ng kakayahan ng Live Probe, ang nauugnay na tool sa pag-debug ng software ay may access sa lahat ng mga lokasyon ng signal ng probe sa pamamagitan ng awtomatikong nabuong debug file. Gaya ng ipinapakita sa Figure 5, maaaring piliin ang pangalan ng signal mula sa listahan ng signal at ilapat sa nais na channel. Magagawa ito kahit na habang tumatakbo ang disenyo upang ang aktibidad ng pagsisiyasat sa loob ng disenyo ay walang putol at napakahusay.

Sa maraming mga kaso, ang kakayahan ng hardware probe, tulad ng Live Probe, ay maaaring gamitin kasabay ng naunang inilarawan na naka-embed na logic analyzer at ang mga panlabas na diskarte sa pagsubok.

Tulad ng ipinapakita sa Figure 6, ang kakayahan ng Live Probe na pumili ng mga signal 'on the fly' ay ginagawang posible na mabilis at madaling baguhin ang mga signal sa ilalim ng pagmamasid nang hindi kinakailangang muling i-compile ang disenyo. Ang isang panlabas na logic analyzer o saklaw ay madaling obserbahan ang mga probed signal, tulad ng inilalarawan sa kanang itaas na bahagi ng figure sa mga nakalaang probe output pin. Bilang kahalili (o marahil bilang karagdagan sa) ang panloob na logic analyzer (ang ILA Identify block, na ipinapakita sa figure) ay maaaring gamitin upang obserbahan ang mga probe pin. Ang mga signal ng probe ay maaaring makuha ng ILA at maobserbahan sa window ng waveform. Ang mga lokasyon ng pagsisiyasat ay maaaring mabago nang hindi kinakailangang muling i-compile ang target na disenyo.
Tandaan na ang mga karagdagang kakayahan para sa pag-trigger at pagsubaybay ay maaaring gamitin upang mapahusay ang pag-andar ng probe, na ginagawang madali upang makita ang kahit na kumplikadong mga isyu sa disenyo.

Available din ang mga karagdagang kakayahan sa pag-debug ng hardware sa SmartFusion2 SoC FPGA at IGLOO2 FPGA device. Ang isa sa mga kakayahan na ito, na tinatawag na Active Probe, ay maaaring magbasa o magsulat nang dynamic at asynchronously sa anumang logic element register bit. Ang isang nakasulat na halaga ay nananatili para sa isang ikot ng orasan upang magpatuloy ang normal na operasyon, na ginagawa itong isang napakahalagang tool sa pag-debug. Ang Active Probe ay partikular na interesado kung ang isang mabilis na pagmamasid sa isang panloob na signal ay ninanais (marahil para lamang suriin kung ito ay aktibo o sa nais na estado, tulad ng isang reset signal), o kung may pangangailangan na mabilis na subukan ang isang logic function sa pamamagitan ng pagsulat sa isang probe point
(marahil upang simulan ang isang state machine transition sa pamamagitan ng mabilis na pagtatakda ng input value para ihiwalay ang isang problema sa control flow).

Ang isa pang kakayahan sa pag-debug na ibinigay ng Microsemi ay ang Memory Debug. Binibigyang-daan ng feature na ito ang taga-disenyo na magbasa o magsulat nang dynamic at asynchronously sa isang napiling FPGA fabric SRAM block. Gaya ng inilalarawan sa screen shot ng Debug Tool (Figure 7), kapag pinili ang tab na Memory Blocks, mapipili ng user ang gustong memoryang babasahin, magsagawa ng snapshot capture ng memory, baguhin ang mga value ng memory, at pagkatapos ay isulat ang mga value pabalik sa device. Maaari itong maging partikular na kapaki-pakinabang para sa pagsuri o pagtatakda ng mga buffer ng data na ginagamit sa mga port ng komunikasyon para sa computation oriented scratch-pad o kahit para sa code na pinaandar ng isang naka-embed na CPU. Ang pag-debug ng mga kumplikadong error na umaasa sa data ay mas mabilis at mas madali kapag ang mga alaala ay maaaring maobserbahan at makontrol nang napakabilis.

Kapag na-debug ang isang disenyo, maaaring kanais-nais na i-off ang mga kakayahan sa pag-debug ng hardware upang maprotektahan ang sensitibong impormasyon. Maaaring gamitin ng isang umaatake ang parehong mga pasilidad na ito upang basahin ang kritikal na impormasyon o baguhin ang mga setting ng system na maaaring magbigay ng madaling pag-access sa mga sensitibong bahagi ng system. Nagdagdag ang Microsemi ng mga feature upang payagan ang taga-disenyo na i-secure ang device pagkatapos makumpleto ang pag-debug. Para kay exampSa gayon, ang pag-access sa Live Probe at Active Probe ay maaaring i-lock upang ganap na i-disable ang function bilang isang posibleng paraan ng pag-atake (tinatanggal pa nito ang posibilidad ng aktibidad ng probe na lumikha ng anumang mga pattern sa kasalukuyang supply na maaaring magamit upang subukan at obserbahan ang data ng probe nang hindi direkta). Bilang kahalili, ang pag-access sa mga napiling bahagi ng disenyo ay maaaring i-lock upang maiwasan ang pag-access sa mga seksyon lamang na iyon. Maaari itong maging maginhawa kung isang bahagi lamang ng disenyo ang kailangang maging ligtas na ginagawang naa-access pa rin ang natitirang bahagi ng disenyo para sa pagsubok sa field o pagsusuri ng error.

In-Circuit Debug Comparison Chart
Ngayon na ang isang detalyadong review sa tatlong pangunahing in-circuit hardware debug techniques ay inilarawan ang isang summary chart, tulad ng ipinapakita sa Figure 8, ay nilikha na nagdedetalye sa iba't ibang advantages at disadvantages ng bawat pamamaraan. Pag-alala na ang ilang mga diskarte ay maaaring gamitin kasama ng (Live Probe at Internal Logic Analyzer (ILA), tulad ng Synopsys Identify, para sa example), makikita natin ang mga pangunahing lakas at kahinaan ng bawat pamamaraan. Ang koleksyon ng mga in-circuit na kakayahan sa pag-debug ng hardware (Live Probe, Active Probe, at Memory Debug—sama-samang tinatawag na SmartDebug), ay pinakamahina kumpara sa iba pang mga diskarte pagdating sa bilang ng kabuuang mga probe na magagamit (isang pulang bilog) at mas mahina kaysa sa pinakamahusay (dilaw na bilog) kapag isinasaalang-alang ang bilis ng pagkuha (maaaring mas mabilis ang panlabas na kagamitan sa pagsubok).
Ang mga diskarteng nakabatay sa ILA, tulad ng Synopsys Identify, ay pinakamahina kung ihahambing sa iba pang mga diskarte at kapag isinasaalang-alang ang mga kinakailangan sa mapagkukunan ng FPGA. Ang mga panlabas na pamamaraang nakabatay sa kagamitan sa pagsubok ay pinakamahina sa ilang pagsasaalang-alang na may pinakamabigat na gastos, epekto sa timing ng disenyo, at paggalaw ng probe sa itaas (dahil sa pangangailangang i-compile ang disenyo). Marahil ang pinakamainam na solusyon ay isang kumbinasyon ng SmartDebug at isa sa iba pang mga diskarte, upang ang bilang ng mga channel na kahinaan ng SmartDebug ay maaaring mabawasan at ang probe point movement disadvantagang iba pang mga diskarte ay nabawasan din.

Mga Pag-uuri ng Signal
Ang isang kapaki-pakinabang na pagkakaiba ay maaaring gawin sa pagitan ng ilan sa mga pinakakaraniwang uri ng mga signal at makakatulong ito kapag nagpaplano ng isang diskarte sa pag-debug. Para kay exampAt, ang mga signal na hindi nagbabago maliban sa pagsisimula ng system, tulad ng pag-reset ng system, pag-reset ng block, o pagsisimula ng mga rehistro ay maaaring uriin bilang mga static na signal. Ang mga uri ng signal na ito ay pinaka-mahusay na naa-access sa pamamagitan ng isang pasilidad na madaling mag-obserba at makokontrol ang signal, nang hindi nangangailangan ng mahabang ikot ng recompile. Ang Active Probe ay isang mahusay na pasilidad para sa pag-debug ng mga static na signal. Katulad nito, ang mga signal na mas madalas na nagbabago ngunit static pa rin sa karamihan ng oras, ay maaaring uriin bilang pseudo-static at pinaka-epektibong na-debug gamit ang Active Probe. Ang mga signal na madalas na nagbabago, tulad ng mga signal ng orasan, ay maaaring mauri bilang dynamic at hindi madaling ma-access sa pamamagitan ng Active Probe. Ang Live Probe ay isang mas mahusay na pagpipilian para sa pagmamasid sa mga signal na ito.

Simpleng Debug Use Case

Ngayon na mayroon na tayong mas mahusay na pag-unawa sa iba't ibang opsyon sa in-circuit debug, tingnan natin ang isang simpleng disenyo example upang makita kung paano gumaganap ang mga diskarteng ito. Ang Figure 9, ay nagpapakita ng isang simpleng disenyo ng FPGA sa isang SmartFusion2 SoC FPGA device. Ang Microcontroller Subsystem (MSS) ay ni-reset ng CoreSF2Reset Soft IP block. Ang mga input sa block na ito ay ang Power On Reset, isang User Fabric Reset, at isang External Reset. Ang mga output ay isang pag-reset sa User Fabric, isang MSS reset, at isang M3 reset. Ang mga sintomas ng error ay walang aktibidad sa I/Os kahit na matagumpay na lumabas ang device sa estado ng POR. Ang tatlong magkakaibang opsyon para sa pag-debug ng error na ito ay inilalarawan din sa figure: Ang asul na kahon (na may label na ETE) ay para sa External Test Equipment na paraan; ang berdeng kahon (na may label na ILA) ay para sa Internal Logic Analyzer na pamamaraan; at ang orange na kahon (may label na AP) ay para sa Active Probe method. Ipagpalagay namin na ang mga potensyal na sanhi ng error ay hindi wastong iginiit ang mga reset input sa CoreSF2Reset Soft IP block.

Tingnan natin ngayon ang proseso ng pag-debug para sa tatlo sa mga naunang inilarawan na in-circuit na pamamaraan.

Panlabas na Kagamitan sa Pagsusulit
Gamit ang pamamaraang ito, ipinapalagay na ang kagamitan sa pagsubok ay magagamit at hindi ginagamit ng mas mataas na priyoridad na proyekto. Bukod pa rito, mahalagang magplano nang maaga upang ang ilang FPGA I/O ay magagamit at madaling maikonekta sa kagamitan sa pagsubok. Ang pagkakaroon ng isang header sa PCB para sa halample, ay magiging lubhang kapaki-pakinabang at bawasan ang oras na ginugol sa pagsubok na kilalanin at kumonekta sa isang 'malamang na pinaghihinalaan' o ang potensyal na pagkukulang ng mga pin sa panahon ng pagsisiyasat. Ang disenyo ay kailangang muling i-compile para piliin ang mga signal na gusto naming siyasatin. Sana, hindi kami 'magbabalat ng sibuyas' at kailangang pumili ng mga karagdagang senyales para sa karagdagang pagsisiyasat, dahil kadalasan ang aming paunang pagsisiyasat ay nagreresulta lamang sa mas maraming katanungan. Sa anumang pangyayari, ang proseso ng recompile at reprogramming ay maaaring tumagal ng isang malaking tagal ng oras, at kung magreresulta ito sa mga paglabag sa timing, kinakailangan ang muling pagdidisenyo (pamilyar tayong lahat kung gaano nakakadismaya ang pagsubok na lutasin ang mga isyu sa pagsasara ng timing, lalo na, kapag gumagawa ka ng mga pagbabago sa disenyo upang makahanap ng bug sa disenyo—ang buong proseso ay maaaring tumagal mula minuto hanggang oras)! Mahalaga rin na tandaan na kung ang disenyo ay walang libreng user I/Os, ang paraang ito ay hindi maipapatupad. Bukod dito, ang pamamaraang ito ay nakakagambala sa disenyo—at ang mga bug na nauugnay sa timing ay maaaring mawala o muling lumitaw sa pagitan ng mga pag-ulit.

Panloob na Logic Analyzer
Gamit ang pamamaraang ito, ang ILA ay dapat na maipasok sa disenyo gamit ang mga mapagkukunan ng tela, at pagkatapos ay kailangang muling i-compile. Tandaan na kung nai-instantiate na ang ILA, maaaring hindi ginamit ang mga senyales na gusto naming siyasatin, na mangangailangan din ng muling pag-compile. Ang prosesong ito ay nanganganib na baguhin ang orihinal na disenyo at lumabag sa mga hadlang sa tiyempo. Kung matutupad ang oras, kailangang i-reprogram at muling simulan ang disenyo. Ang buong prosesong ito ay maaaring tumagal ng ilang minuto o kahit na oras kung ang mga oras ng muling pag-compile ay mahaba at maraming pass ang kailangan. Ang diskarteng ito ay nakakagambala sa istruktura at maaaring magresulta sa mga katulad na problema sa mga inilarawan kapag ginagamit ang pamamaraan sa itaas.

Aktibong Probe
Gamit ang pamamaraang ito, ang Active Probe ay maaaring ituro sa pinagmulan ng iba't ibang reset signal, na ang lahat ay pinanggalingan ng mga output ng rehistro (tulad ng karaniwan sa anumang mahusay na kasanayan sa digital na disenyo). Ang mga signal ay pinili nang paisa-isa, mula sa isang Active Probe menu na ipinapakita sa Figure 10 sa ibaba. Maaaring basahin ang mga napiling halaga ng signal at ipinapakita sa window ng data ng Active Probe. Ang anumang maling assertion ay madaling matukoy. Ang pagsubok na ito ay maaaring gawin kaagad nang hindi kinakailangang muling i-compile at i-reprogram ang device at hindi nakakagambala sa istruktura o pamamaraan. Ang buong proseso ay tumatagal lamang ng ilang segundo. Ang pamamaraang ito ay maaari ring lumikha ng kakayahang kontrolin (pagbabago ng mga halaga nang asynchronous) na hindi papayagan ng iba pang dalawang pamamaraan. Sa partikular na ex na itoampSa gayon, ang reset signal na pinanggalingan ng isang rehistro ay maaaring madaling masuri at matuklasan na gaganapin sa aktibong estado.

Ang panandaliang toggling ng reset signal ay maaaring makamit sa pamamagitan ng asynchronously na pagmamanipula sa register na bumubuo ng mga rest signal.

Mas Kumplikadong Debug Use Case
Ang disenyo sa itaas ay napaka-simple at kapaki-pakinabang bilang panimula sa paggamit ng inilarawang mga diskarte sa disenyo, ngunit isang mas kumplikadong example ay maaaring maging higit pang ilustrasyon. Maraming beses na ang signal ng interes ay hindi isang static na signal tulad ng nangyari sa aming simpleng example ngunit ay dynamic. Ang isang karaniwang dynamic na signal ay isang intermediate na orasan, marahil ay ginagamit para sa timing ng handshake para sa isang serial interface. Ipinapakita ng Figure 11 ang gayong disenyo kasama ang Soft IP core ng gumagamit, sa kasong ito, isang pasadyang serial interface na konektado sa APB bus ng system. Ang mga sintomas ng mga error ay walang aktibidad sa custom na serial interface ng mga user, at kapag nag-isyu ang isang APB bus master ng transaksyon para ma-access ang serial interface, napupunta ito sa isang kundisyon ng exception na nagpapahiwatig ng maling handshake. Ang mga kundisyong ito ay tila nag-aalis ng isang static na dahilan, tulad ng isang maling signal ng pag-reset, dahil ang makina ng estado ng transaksyon ay tila hindi gumagana sa rate na inaasahan at sa gayon ay nagiging sanhi ng pagbubukod. Ang ugat na sanhi ay naisip na ang clock frequency generator sa loob ng user IP core.

Kung hindi ito tumatakbo sa tamang dalas, magreresulta ang mga inilarawang error.

Sa sitwasyong ito, malamang na isang mas mahusay na diskarte na palitan ang Active Probe approach ng Live Probe. Ito ay inilalarawan sa figure sa itaas ng kulay kahel na LP box, gamit ang JTAG signal para sa pagpili ng probe source.

Panlabas na Kagamitan sa Pagsusulit
Para sa kasong ito, ang pamamaraan ay halos kapareho sa naunang inilarawan na simpleng halample. Ang signal ng orasan ng gumagamit ay dinadala sa punto ng pagsubok (sana ay nasa isang header) at kailangan ng isang matagal na pag-recompile. Maaaring makatulong din na maglabas ng reference signal, marahil isang system clock na ginagamit upang i-clock ang IP ng mga user bilang isang paghahambing na signal. Muli tayong sasailalim sa pangangailangang mag-recompile at mag-reprogram upang ang buong proseso ay maaaring tumagal ng mahabang panahon.

Panloob na Logic Analyzer
Ang kasong ito ay halos kapareho sa simpleng example. Ang ILA ay dapat na maipasok, o ang nais na signal ay tinukoy, at isang ikot ng recompile at reprogram ang naisakatuparan. Ang lahat ng naunang inilarawang isyu ay nagreresulta pa rin sa isang makabuluhang cycle ng oras ng pag-debug. Mayroong karagdagang kumplikado, gayunpaman. Ang orasan na nagtutulak sa ILA ay kailangang magkasabay, at mas mainam na mas mabilis na may kinalaman sa orasan na obserbahan mula sa user na Soft IP core. Kung ang mga orasan na ito ay asynchronous, o walang tamang mga ugnayan sa timing, ang pagkuha ng data ay hindi mahuhulaan at posibleng pagmulan ng kalituhan para sa proseso ng pag-debug.
Tandaan na kung ang user na Soft IP clock ay hindi nabuo sa chip (marahil ito ay nakuhang muli mula sa serial interface) maaaring kailanganin ng taga-disenyo na magdagdag ng isang module ng orasan upang makabuo ng isang mas mabilis na orasan ng ILA gamit ang mga karagdagang mapagkukunan at posibleng lumikha ng isang paglabag sa timing.

Live Probe
Gamit ang pamamaraang ito, ang Live Probe ay maaaring mabilis na ituro sa pinagmulan ng orasan ng gumagamit at anumang iba pang mapagkukunan ng orasan mula sa isang rehistro upang habulin ang ugat ng error. Ipapakita ng Live Probe ang mga napiling output ng signal sa real time at ang anumang relasyon sa timing sa pagitan ng mga signal ay mas madaling matukoy. Ang buong proseso ay tumatagal lamang ng ilang segundo.

Iba pang Mga Tampok sa Pag-debug para sa Mga Serial na Interface
Mahalaga ring ituro na maraming karagdagang kakayahan sa pag-debug sa SmartFusion2 SoC FPGA at IGLOO2 FPGA device na maaaring gamitin sa mga serial interface, tulad ng sa dating ex.ample disenyo kung saan ang mga error ay mas kumplikado. SERDES Debug, para sa halample, ay nagbibigay ng mga partikular na kakayahan sa pag-debug para sa nakalaang mataas na bilis na mga serial interface. Ang ilan sa mga feature ng SERDES Debug ay kinabibilangan ng PMA test support (tulad ng PRBS pattern generation at loopback testing) na suporta para sa maramihang SERDES test configurations na may register-level reconfiguration upang maiwasan ang paggamit ng buong daloy ng disenyo para gumawa ng mga pagbabago sa configuration, at mga text report na nagpapakita ng mga naka-configure na protocol, SERDES configuration registers, at Lane configuration registers. Ang mga tampok na ito ay ginagawang mas madali ang pag-debug ng SERDES at maaaring gamitin kasabay ng Live Probe at Active Probe upang mas mapabilis ang pag-debug ng mga kumplikadong circuit.
Ang naunang inilarawan na tool sa Memory Debug ay maaari ding gamitin kasabay ng SERDES Debug upang mapabilis ang pagsubok. Dahil ang mga memory buffer ay maaaring mabilis at madaling masuri at mabago gamit ang Memory Debug, posible na mabilis na lumikha ng 'mga test packet' at obserbahan ang mga resulta ng loopback o inter-system na komunikasyon. Maaaring gamitin ng taga-disenyo ang mga kakayahan na ito at sa gayon ay mabawasan ang pangangailangan para sa mga espesyal na 'test harnesses' na kumonsumo ng karagdagang tela ng FPGA at maaaring makaapekto sa timing ng chip.

Konklusyon
Detalyadong inilarawan ng papel na ito ang ilang magkakaibang diskarte sa pagpapatupad ng in-circuit debug para sa mga FPGA at SoC FPGA—ang paggamit ng Integrated Logic Analyzer, ang paggamit ng mga panlabas na kagamitan sa pagsubok, at ang paggamit ng mga nakalaang probe circuit na isinama sa FPGA fabric. Ang pagdaragdag ng mga dalubhasa at dedikadong probe circuit, tulad ng Active Probe at Live Probe na inaalok ng Microsemi sa SmartFusion2 SoC FPGA at IGLOO2 FPGA na mga device, ay ipinakita sa makabuluhang pagpapabilis at pagpapasimple ng proseso ng pag-debug. Ang kakayahang mabilis na baguhin ang pagpili ng mga panloob na signal (nang hindi kailangang magsagawa ng napakatagal na pag-recompile at muling pag-ikot ng programa), at ang kakayahang suriin ang mga panloob na signal (nang hindi kailangang gumamit ng tela ng FPGA at potensyal na magpakilala ng mga paglabag sa tiyempo) ay ipinakita na pangunahing advantages kapag nagde-debug ng mga disenyo ng FPGA. Bukod pa rito, inilarawan ang paggamit ng maraming pamamaraan, na maaaring magtulungan upang magbigay ng mas malawak na kakayahan sa pag-debug. Sa wakas, dalawang exampAng mga kaso ng paggamit ng debug ay ibinigay upang ilarawan ang mga trade-off sa pagitan ng mga inilarawang pamamaraan.

Para Matuto pa

1. IGLOO2 FPGAs
2. Mga SmartFusion2 SoC FPGA

Ang Microsemi Corporation (Nasdaq: MSCC) ay nag-aalok ng komprehensibong portfolio ng semiconductor at mga solusyon sa system para sa mga komunikasyon, depensa at seguridad, aerospace at industriyal na merkado. Kasama sa mga produkto ang high-performance at radiation-hardened analog mixed-signal integrated circuits, FPGAs, SoCs at ASICs; mga produkto ng pamamahala ng kapangyarihan; timing at synchronization na mga aparato at tumpak na mga solusyon sa oras, na nagtatakda ng pamantayan ng mundo para sa oras; mga aparato sa pagproseso ng boses; Mga solusyon sa RF; hiwalay na mga bahagi; mga teknolohiya sa seguridad at nasusukat na anti-tampmga produkto; Mga Power-over-Ethernet IC at midspan; pati na rin ang mga custom na kakayahan sa disenyo at serbisyo. Ang Microsemi ay headquarter sa Aliso Viejo, Calif., at may humigit-kumulang 3,400 empleyado sa buong mundo. Matuto pa sa www.microsemi.com.

© 2014 Microsemi Corporation. Lahat ng karapatan ay nakalaan. Ang Microsemi at ang Microsemi logo ay mga trademark ng Microsemi Corporation. Ang lahat ng iba pang mga trademark at mga marka ng serbisyo ay pag-aari ng kani-kanilang mga may-ari.

Microsemi Corporate Headquarters

• Isa Enterprise, Aliso Viejo CA 92656 USA
• Sa loob ang USA: +1 800-713-4113
• Sa labas ang USA: +1 949-380-6100
• Benta: +1 949-380-6136
• Fax: +1 949-215-4996
• E-mail: sales.support@microsemi.com

FAQ

• Q: Ano ang maximum na dalas ng pagkuha ng data ng device?
  A: Sinusuportahan ng device ang pagkuha ng data nang hanggang 100MHz, na angkop para sa karamihan ng mga target na disenyo.
• T: Kailangan ko bang muling i-compile ang disenyo kapag gumagamit ng mga probe circuit para sa pag-debug?
  A: Hindi, ang mga lokasyon ng probe point ay maaaring mabilis na mabago nang hindi nangangailangan ng recompilation o reprogramming ng disenyo.

Mga Dokumento / Mga Mapagkukunan

Microsemi In-Circuit FPGA Debug [pdf] Mga tagubilin In-Circuit FPGA Debug, FPGA Debug, Debug

Mga sanggunian

• User Manual