Portál AbcLinuxu, 18. dubna 2024 06:34
2.12.2014 13:12
| Přečteno: 2128×
|
Je tu další pokračování seriálu o programovatelné logice. Tentokrát si místo obecných popisů ukážeme pár praktických obvodů, které mohou ušetřit mnoho bezesných nocí strávených hledáním chyb v návrhu těsně před termínem odevzdání. Minulý díl najdete zde, odtud se pak dá postupně proklikat ke všem předchozím dílům.
V minulé kapitole byla zmíněna důležitost synchronního návrhu pro FPGA. Vnější signály připojené ke vstupně-výstupním pinům hradlového pole jsou však většinou asynchronní vůči interním hodinovým signálům. Často také bývá nutné v rámci jednoho návrhu použít několik různých, navzájem asynchronních hodinových signálů. V obou těchto případech je nutné věnovat zvláštní pozornost vstupu asynchronních signálů do synchronního obvodu a přechodu datových signálů mezi jednotlivými bloky pracujícími s různými hodinami.
V následujícím textu bude často používán výraz hodinová doména. Za hodinovou doménu je považována část obvodu, jejíž všechny synchronní sekvenční prvky používají jeden společný hodinový signál. Synchronní prvky v rámci FPGA mohou být kromě samotných klopných obvodů například i synchronní blokové paměti, aritmetické bloky a podobně.
Asynchronní signály na vstupu synchronního obvodu mohou obecně způsobit dva různé problémy. Prvním z nich je uvedení některých klopných obvodů do nestabilního nebo pravděpodobněji metastabilního stavu. Častější problém je způsoben nekoherencí propojovacích cest jednotlivých synchronních prvků připojených k jednomu společnému asynchronnímu vstupu.
Metastabilita je dočasné uvedení klopného obvodu do nestabilního stavu. Tato dočasná nestabilita se může projevovat například oscilacemi na výstupu nebo častěji nedefinovanou výstupní logickou úrovní mezi logickou nulou a jedničkou. Metastabilní stav může být způsoben mnoha fyzikálními vlivy, ale v FPGA pracujících při výrobcem doporučených provozních podmínkách připadá prakticky v úvahu pouze porušení vstupních časových parametrů konkrétního klopného obvodu. Pokud vstupní signál klopného obvodu mění úroveň v době vymezené časovými parametry setup time a hold time, existuje nenulová pravděpodobnost přivedení klopného obvodu do metastabilního stavu.
Metastabilní chování klopného obvodu typu D je znázorněno časovým průběhem na obrázku 4.1. V obrázku jsou vyznačeny časové parametry setup time (tSU), hold time (tH) a clock to output time (tCO).
Obr. 4.1: Metastabilní chování klopného obvodu typu D
Vstupní signál D na obrázku 4.1 mění úroveň příliš blízko aktivní hrany hodin CLK čímž porušuje tSU. Důsledkem je metastabilní stav výstupu Q vyjádřený nedefinovanou úrovní mezi logickou nulou a jedničkou. Po době delší než tCO se výstup nakonec překlopí do některé definované logické úrovně. Může to být ale jak logická jednička, tak i nula.
Na rozdíl od zákaznických integrovaných obvodů není u programovatelných hradlových polí metastabilita klopných obvodů tak výrazný problém, přesto však není setkání s tímto jevem nijak neobvyklé. Pro zamezení vzniku problémů způsobených metastabilitou je důležité vždy správně ošetřit vstupy asynchronních signálů tak, aby nedošlo k porušení podmínek daných tSU a tH nebo zajistit aby případná metastabilita neohrozila funkci obvodu. Jednotlivé metody synchronizace asynchronních signálů jsou popsány dále v této kapitole.
Pokud je asynchronní signál připojen do vstupů několika synchronních prvků zároveň, velmi často nastává problém s nekoherencí jednotlivých signálových a hodinových cest. Tento případ je znázorněn na obrázku 4.2, kde je asynchronní signál data připojen na vstupy dvou klopných obvodů. Zpoždění tohoto signálu od jeho zdroje do jednotlivých vstupů klopných obvodů je rozdílné, stejně jako zpoždění hodinového signálu clk. Různá zpoždění jednotlivých signálových a hodinových cest mohou způsobit rozdílné hodnoty na výstupech jednotlivých klopných obvodů, přestože teoreticky by oba výstupy měly být shodné.
Obr. 4.2: Vstup asynchronního signálu do několika klopných obvodů
Časové průběhy signálů v obvodu z obrázku 4.2 jsou znázorněny na obrázku 4.3. Okótované hodnoty představují jednotlivá zpoždění průchodu signálu od jeho zdroje ke konkrétnímu vstupu. Hodnoty tPc0 a tPc1 představují zpoždění hodinového signálu clk, zatímco hodnoty tPd0 a tPd1 reprezentují zpoždění vstupního signálu data. Na obrázku je zachycen případ, kdy kvůli rozdílným zpožděním vstupních a hodinových signálů dojde k nastavení výstupů do rozdílných logických úrovní.
Obr. 4.3: Časové průběhy signálů v obvodu z obrázku 4.2
Řešením problémů způsobených nekoherencí je opět nutnost vždy zajistit správnou synchronizaci asynchronních signálů. V rámci jedné hodinové domény je pak nutné používat výhradně nový synchronizovaný signál namísto původního asynchronního. Jednotlivé metody synchronizace asynchronních signálů jsou podrobně popsány v následující části.
Správné ošetření asynchronních vstupů je nezbytné pro korektní funkci synchronního logického obvodu. Toto téma se týká jak externích asynchronních signálů, tak i interních signálů generovaných v jiné hodinové doméně. Existuje několik různých metod synchronizace asynchronních signálů, přičemž každá je vhodná pro jiný typ signálu.
Nejjednodušším případem přechodu mezi hodinovými doménami je synchronizace samostatného signálu. Potlačení vlivu metastability na zbytek obvodu se dosáhne několikanásobným registrováním signálu v nové hodinové doméně podle obrázku 4.4. Pro synchronizaci musí být použity minimálně dva klopné obvody v hodinové doméně clk2. V závislosti na použité technologii a chování vstupního signálu může být nutné počet synchronizačních klopných obvodů zvýšit.
Obr. 4.4: Přechod jednotlivého signálu do jiné hodinové domény
Časové průběhy synchronizačního obvodu z obrázku 4.4 jsou znázorněny na obrázku 4.5. Přestože může být první klopný obvod uveden do metastabilního stavu, výstup druhého klopného obvodu se nachází již pouze ve stabilních stavech. Tento synchronizační obvod je funkční pokud platí, že
Tclk2 − tSU ≥ tmet
kde Tclk2 je perioda hodinového signálu clk2, tSU je setup time daných klopných obvodů a tmet je maximální doba po kterou setrvává klopný obvod v metastabilním stavu měřená od aktivní hrany hodinového signálu.
Obr. 4.5: Synchronizace asynchronního signálu
Tato synchronizační metoda je obecně vhodná pouze pro jednotlivé signály. Její použití pro vektory nebo sběrnice je možné pouze ve speciálních případech. Typicky lze tuto metodu použít tam, kde nová hodnota vektoru v cílové hodinové doméně bude využita až dostatečný počet hodinových cyklů po změně, tak aby nová hodnota vektoru byla stabilní a konzistentní. Pokud není možné tuto podmínku splnit, je třeba použít některou ze složitějších synchronizačních metod popsaných dále.
Tato metoda je vhodná pro synchronizaci vektorů v cílové hodinové doméně s vyšší hodinovou frekvencí než má zdrojová doména nebo pro synchronizaci vektorů, které mění svou hodnotu pouze občas. Metoda je založena na využití samostatného pomocného signálu, který signalizuje změnu hodnoty vektoru. Schéma tohoto synchronizačního obvodu je na obrázku 4.6.
Při každé změně hodnoty vektoru vect dojde k invertování hodnoty pomocného signálu t, který je v cílové hodinové doméně synchronizován metodou popsanou v předchozí části. Následuje detektor hran, který při změně logické úrovně synchronizovaného signálu t povolí zápis nové hodnoty vektoru vect do vstupních registrů cílové hodinové domény.
Obr. 4.6: Přenos hodnoty vektoru mezi hodinovými doménami
Časové průběhy tohoto synchronizačního obvodu jsou znázorněny na obrázku 4.7. Průběhy jsou důležité pro základní představu o použitelnosti, protože tento způsob synchronizace je vhodný pouze pokud zůstává vektor vect konstantní po dostatečně dlouhou dobu vzhledem k periodě hodinového signálu clk2.
Obr. 4.7: Synchronizace hodnoty vektoru
Pro správnou funkci tohoto synchronizačního obvodu musí platit, že hodnoty vektoru vect a pomocného signálu t jsou stabilní minimálně po dobu
tset ≥ tSU + 2 Tclk2 + tH + tM
kde tSU je setup time použitých klopných obvodů, Tclk2 je perioda hodinového signálu clk2, tH je hold time použitých klopných obvodů a tM je rezerva daná časovým posunem mezi aktivní hranou hodinového signálu clk1 v okamžiku změny hodnot vect a t a následující aktivní hranou hodinového signálu clk2. Praktická bezpečná hodnota doby, po kterou musejí zůstat hodnoty vect a t stabilní je typicky
tset ≥ 3 Tclk2
Pokud mění vektor vect svou hodnotu častěji než s periodou tset, je nutné použít některou z následujících metod synchronizace. Konkrétní výběr závisí na vlastnostech synchronizovaného vektoru.
Často je třeba přenést mezi hodinovými doménami hodnotu čítače. Pokud je možné zajistit, že se mezi dvěma aktivními hranami cílového hodinového signálu změní maximálně jediný bit, je možné provést jednoduchou synchronizaci pomocí klopných obvodů. Čítače se v tomto případě realizují buď přímo v Grayově kódu, nebo se do Grayova kódu převádí hodnota binárního čítače. Základní vlastností Grayova kódu je právě změna pouze jediného bitu mezi jednotlivými kroky. Samozřejmě se během jedné periody cílových hodin nesmí změnit hodnota čítače více než o jedničku. Na obrázku 4.8 je schéma tohoto synchronizačního obvodu.
Obr. 4.8: Přenos hodnoty čítače mezi hodinovými doménami
Tento obvod synchronizuje hodnotu binárního čítače v hodinové doméně clk1 do asynchronní hodinové domény clk2. Binární hodnota synchronního čítače je převedena na Grayův kód, registrována a převedena do nové hodinové domény. Zde je synchronizována vůči novému hodinovému signálu dvouúrovňovými registry stejně jako běžné skalární signály. Vzhledem k tomu, že se během jedné periody mění hodnota pouze jediného bitu, nebude na výstupu z druhé úrovně registrů nikdy nekonzistentní hodnota. V limitním případě může nastat pouze situace, kdy se hodnota změní o jeden hodinový cyklus později. Výstup ze synchronizačních registrů je převeden z Grayova kódu zpět na binární reprezentaci a může být dále používán v rámci hodinové domény clk2.
Takovýto synchronizační obvod se často používá například pro přenos hodnot adresových čítačů mezi hodinovými doménami v asynchronních pamětech typu FIFO založených na dvouportových RAM.
Předchozí metody nejdou využít přímo pro přenos hodnot rychle se měnících vektorů mezi asynchronními hodinovými doménami. Na jejich základě je ale možné vytvořit asynchronní FIFO, které je k tomuto účelu ideální. Velmi zjednodušené blokové schéma asynchronní paměti FIFO je znázorněno na obrázku 4.9. Slovo asynchronní označuje vztah mezi hodinovými doménami clk1 a clk2. Chování každé části v rámci vlastní hodinové domény je plně synchronní.
Obr. 4.9: Asynchronní FIFO
Asynchronní FIFO je tvořeno dvouportovou blokovou pamětí, řídící logikou zápisu a blokem řídící logiky čtení. Na schématu nejsou znázorněny další signály, mezi které patří asynchronní reset, stavové výstupy signalizující blízkost zaplnění nebo vyprázdnění a podobně. Vlastní FIFO není v dnešní době nutné vyvíjet od začátku. Mnoho současných FPGA umožňuje nakonfigurovat blokové paměti přímo do režimu FIFO a přímo je do návrhu vložit. Všechna vývojová prostředí hlavních výrobců FPGA obsahují také plně konfigurovatelná jádra implementující asynchronní FIFO.
Přechod rychlých datových cest nebo sběrnic mezi asynchronními doménami je realizován právě umístěním asynchronní FIFO do cesty. Tím sice dojde ke zvýšení latence celé cesty, ale zamezí se případným problémům s metastabilitou nebo nekoherencí.
Mnoho projektů vyžaduje využití několika asynchronních hodinových domén. Často je ale možné počet hodinových domén zredukovat, v ideálním případě až na jednu jedinou. Redukce počtu domén výrazně omezí možnost vzniku chyb a problémů způsobených metastabilitou nebo nekoherencí a také často zrychlí běh implementačních nástrojů. Časová analýza, ale i optimalizace časování během syntézy a implementace proběhne tím rychleji, čím méně je v návrhu přechodů mezi asynchronními hodinovými doménami.
Redukce počtu hodinových domén je možná v zásadě dvěma způsoby. V případě, že je skutečně nutné použít fyzicky rozdílné hodinové signály, je dobré zvolit jeden hlavní hodinový signál a ten použít pro většinu návrhu. V ostatních hodinových doménách pak řešit jenom nejnutnější minimum, jako jsou například vnější rozhraní a co nejrychleji přejít do hlavní, systémové, hodinové domény.
Druhá možnost je použitelná tam, kde skutečně fyzicky rozdílné hodinové signály nutné nejsou. V takovém případě je možné použít pouze jediný hodinový signál o dostatečně vysoké frekvenci a pomocí děliček k němu vyrobit několik pomocných signálů typu clock-enable. Jednotlivé části návrhu pak budou pracovat vždy na společném hodinovém signálu, ale mohou využívat různé signály clock-enable. Každý clock-enable aktivuje danou část obvodu pouze v některých periodách systémových hodin. Jednotlivé části obvodu však mohou být přímo propojeny, protože se jedná o plně synchronní obvod s jediným hodinovým signálem.
Tiskni
Sdílej:
http://www.abclinuxu.cz/auto/blog/digital_design.rss
Pěkný článek
Problém přechodu mezi doménami jsem teď zrovna několikrát řešil. V jednom případě tak, že je známá doba, kdy se v rychlé doméně čítač na delší dobu zastaví a tak v této době hodnotu čítače z pomalejší domény mohu načíst do registru v pomalé doméně.
Druhý případ je návrat sériového streamu z externí galvanicky oddělené periferie. Stream je sice řízen hodinami ze synchronní domény, ale hodiny jsou oddělovači posunuté, deklarovaný posun je větší než hodinový cyklus a teoreticky i prakticky se zpoždění vlivem teploty a dalších vlivů může měnit v tak velkém rozsahu, že postavení zpětných hodin k synchronním nelze učit. Pro toto řešení jsem navrhl malé/několikabitové FIFO. Bylo mi líto použít celou BRAM nebo něco složitějšího, když vím, že frekvence je shodná. řešení chodí dobře, nutně vyžaduje zákaz REGISTER_DUPLICATION. Možná by se řešení mohlo hodit i někomu jinému a zároveň by mě zajímal názor na robustnost řešení někoho s většími znalostmi. Rád bych měl jistotu, že návrhový systém nemůže i tak udělat něco, co by vedlo k problému. Zároveň mě zajímá i alternativa ke Xilinx REGISTER_DUPLICATION na Alteře. Tam jsem to zatím nestudoval a jeden náš student, který na podobný problém v diplomové práci narazil, to zatím řešil zakázáním duplikace registrů na úrovni celého návrhu, příkazové řádky. Na Microsemi jsem něco Synplify dokumetaci našel, ale v reálu si nejsem jistý, jestli to opravdu systém vezme správně.
lx_crosdom_ser_fifo.vhdPřidal jsem ještě ke komponentě i BSD licenci, kdyby to někdo chtěl použít přímo, tak aby neměl obavy.
V komentáři jste zmínil něco, co jsem v zápisku zamlčel. Jedná se o vliv implementačních nástrojů. Protože to běžnému čtenáři nemusí být jasné, trochu to zde rozvedu.
To, že návrh popisuje například v synchronizačním obvodu na konkrétním místě pouze jeden jediný klopný obvod ještě nemusí znamenat, že výsledná implementace nepoužije na jeho místě klopných obvodů více. Tento princip se jmenuje replikace (duplikace) registrů a používá se především pro zlepšení časování. Rychlost překlopení výstupu registru záleží kromě technologických parametrů, napájecího napětí, a teploty na výstupní zátěži a především na její kapacitní složce. Čím větší je zatěžovací kapacita, tím pomaleji se výstup překlopí z jednoho logického stavu do druhého. Replikace registrů nahradí jediný klopný obvod dvěma nebo více, které pak budí menší množství dalších obvodů. Schématicky je to znázorněné třeba zde. Výsledkem replikace je zvýšení maximální hodinové frekvence. Pokud však dojde na replikaci v synchronizačním obvodu, nastane obvykle problém s koherencí spojů a synchronizační obvod přestane plnit svoji funkci. Proto je důležité implementačním nástrojům zakázat replikaci synchronizačních registrů.
Nástroje se o implementačním záměru vývojáře obvykle instruují pomocí tzv. atributů. V ISE k zákazu duplikace/replikace slouží atribut REGISTER_DUPLICATION. Ve Vivadu se používá atribut KEEP. Altera má atribut KEEP také a myslím, že by měl fungovat stejně. Případně by bylo možné zabránit replikaci třeba pomocí dostatečně vysoké hodnoty MAXFAN. Synopsys Synplify a DC stejně jako většina ostatních "velkých" syntezátorů používá obvykle atribut SYN_KEEP.
Synchronizace dat z externí asynchronní periférie s pomocí FIFO je obecně naprosto správný přístup. Otázka je, jestli to ve vašem případě není skoro až zbytečné. Podle kódu předpokládám, že se jedná o galvanicky oddělený SPI slave. Jelikož odpověď dostáváte pouze fázově posunutou (je jedno, že o více než 360°), ale v principu na stejných hodinách, osobně bych to řešil jednodušším způsobem.
Namísto zpětné vazby hodin, bych použil zpětnou vazbu SPI signálu slave select (není to náhodou vstup acd_sync_i ve vaší entitě?). Signály MISO a zpětný SS bych pak přímo synchronizoval v interní hodinové doméně clk_i dvěma registry. SPI master pak musí pouze odpověď od slave zpracovávat podle zpětnovazební verze SS místo původního signálu. Jedná se ale už o jednoduchý, čistě synchronní obvod, kde MISO a zpětnovazební SS mohou být vůči teoretické pozici posunuty o 2 nebo více hodinových cyklů.
Především díky za prohlédnutí/komentář. Dále uvádím trochu více kontextu, aby byla jasná omezení a řešený problém. Opět zpětná vazba vítaná.
U atributu KEEP jsem měl pocit, že především zajistí, že signály zůstanou tak, jak jsou navržené na hranici komponety. Takže to chápu tak, že je rozumné to použít dohromady s komponentou, která se bude skládat jen z jednoho registru (o šířce jeden nebo více bitů).
Co se týče konkrétního FIFO, tak se sice o koncept SPI/SSI jedná, ale průchod hodin přes izolátory je natolik posunutý, že hodiny pro MOSI (clk_i ) jdou s daty do slave (zpoždění může být však větší něž clock, naopak max frekvence kanálů oddělovače je mnohem výše a rozdíly zpoždění mezi kanály čipu jsou mnohem níže než frekvence clock_i). Slave je tedy taktovaný clockem z masteru, ale přes oddělení zpět posílá data na signálu MISO (acd_miso_i) a musí s nimi dopravit přes oddělovač zpět i hodiny (acd_clock_i) a frame signal (acd_sync_i), protože proti původnímu clk_i je fáze zpoždění nedefinovaná.
Alternativou by možná bylo snímat acd_miso_i, acd_sync_i a acd_clock_i na vyšší frekvenci (např rise i fall clk_i) a vybrat stav dat vždy půl periody po detekci změny acd_sync_i. Ale výše uvedené řešení se mi zdálo lepší.
Návrh je pak určený pro naší novou firemní platformu na řízení viceosých robotů. Návrh HW této CPU desky (LPC4088 Cortex-M4F + Xilinx XC6SLX9) děláme pro sebe a rozhodli jsme se, že tato deska zařazena mezi několik našich otevřeným platforem => dokumetace plně k dispozici a pokud někdo projeví zájem tak i kompletní návrhová data v PCB systému PEDA. Počítáme jak s otevřenými tak našimi uzavřenými aplikacemi. Ty pak budou především pro laboratorní přístroje a některé průmyslové aplikace. Pokud by měl někdo o desku zájem, tak bude i k prodeji, ale výrobní cena při našich počtech vychází vysoká a náklady na návrh a experimenty byly také značné. Naopak pokud by někdo chtěl desku vyrábět ve velkých počtech, tak se s ním rádi dohodneme na tom, že si od něj těch pár kusů, které potřebujeme na naše high-tech drahá zařízení, rádi koupíme.
PiKRON LX_CPUNa desku máme bare-metal support, běží na ní MBED.org a RTEMS.
Co se týče konkrétního FIFO, tak se sice o koncept SPI/SSI jedná, ale průchod hodin přes izolátory je natolik posunutý, že hodiny pro MOSI (clk_i ) jdou s daty do slave (zpoždění může být však větší něž clock, naopak max frekvence kanálů oddělovače je mnohem výše a rozdíly zpoždění mezi kanály čipu jsou mnohem níže než frekvence clock_i). Slave je tedy taktovaný clockem z masteru, ale přes oddělení zpět posílá data na signálu MISO (acd_miso_i) a musí s nimi dopravit přes oddělovač zpět i hodiny (acd_clock_i) a frame signal (acd_sync_i), protože proti původnímu clk_i je fáze zpoždění nedefinovaná.
Přesně tak jsem to pochopil a něco jako FIFO je v tomto případě zbytečné. Předpokládejme následující zapojení:
FPGA SPI slave +-------+ +----+ | clk|----[>]--*----|sck | | | | | | | clk_fb|----[<]--+ | | | | | | | mosi|----[>]-------|mosi| | | | | | ssel|----[>]--*----|ssel| | | | | | |ssel_fb|----[>]--+ | | | | | | | miso|----[<]-------|miso| +-------+ +----+
Oproti tomu, co jsem psal v komentáři výše bych přidal ještě vstupní registry na externích hodinách clk_fb. Tím by se fakticky eliminoval vliv rozdílných zpoždění jednotlivých kanálů oddělovače. Zbytek toho co jsem psal platí. Takže naprosto jednoduše:
IN_REGS: process (clk_fb)
begin
if rising_edge(clk_fb) then
ssel_fb_r <= ssel_fb;
miso_r <= miso;
end if;
end process IN_REGS;
SYNC_REGS: process (clk)
begin
if rising_edge(clk) then
ssel_fb_x <= ssel_fb_r;
ssel_fb_sync <= ssel_fb_x;
miso_x <= miso_r;
miso_sync <= miso_x;
end if;
end process SYNC_REGS;
Signály ssel_fb_sync a miso_sync teď máte ve správné hodinové doméně a dostat z miso_sync data není problém. Pouze začátek platných bitů nebudete odpočítávat od sestupné hrany ssel, ale ssel_fb_sync. Ten bude vůči ssel posunutý o několik hodinových cyklů.
Osobně bych použil řešení, které nestojí vůbec žádné prostředky navíc, je velmi jednoduché a robustní. Váše externí zapojení je totiž z pohledu časování v podstatě statické, kdy teplotní změny a pohyb napájecího napětí ovlivňují pouze jitter. Střední hodnota zpoždění vnější zpětné vazby je konstantní a jde jednoduše spočítat nebo změřit. Se znalostí střední hodnoty zpoždění a za předpokladu, že jitter způsobený oddělovacími obvody je nižší než perioda hodinového signálu, jde velmi jednoduše posunout vstupní signály přímo v I/O buňkách FPGA tak, aby se nastavilo bezpečné vzorkovací okno. To se provede nastavením hodnot vstupního zpoždění primitiv pro I/O zpoždění. Mám dojem, že jsem někde u vás na webu zahlédl Spartan-6, tam by to byla primitiva IODELAY2 a parametr IDELAY_VALUE.
Další možností, která už ale stojí prostředky navíc je použití PLL nebo DLL pro potlačení jitteru a fázový posun hodin, tak aby se opět nastavilo bezpečné vzorkovací okno. Oproti předchozí metodě je tato varianta teplotně a napěťově kompenzovaná, takže se dá dosáhnout lepších výsledků, především vyšší hodinové frekvence a může se pracovat s vyšší úrovní vstupního jitteru.
Samozřejmě další možnost je použít plně asynchronní FIFO. Opět to bude stát více prostředků. Jistota je asynchronní FIFO založené na pravé asynchronní dvouportové RAM, ať už blokové nebo jenom distribuované, tvořené LUT. Na tomto místě se musím přiznat, že jsem podrobně nezkoumal váš kód, takže následující poznámky berte prosím s velkou rezervou. Je dost možné, že se mýlím. Na první pohled mi přijde, že váš synchronizační obvod obsahuje docela dost kombinačních signálů přecházejících mezi doménami a je založen na běžných registrech a nikoli na dual-port RAM. Obával bych se, že situace popsaná ve vašem příspěvku na který reaguji nebo i nějaký jiný hraniční případ může vést ke špatné funkci obvodu.
nebo by se na druhé straně muselo počítat CRC z paralelních datNo sice nevím, jak je to CRC řešený (netriviální protokol přímo v těch datech?), ale CRC se dá počítat i z vektoru (já bych byl určitě líný a hodil bych tam nějakej realtime MCU, co to stejně spočítá sekvenčně
).
Otázka je, jestli vygenerovaný multiplexer pro vyčítání bitů z FIFO/bitového cyklického bufferu nemůže být navržen tak, že ho asynchronní změna na jiném, než vybraném bitu rozhodí. V klasické TTL logice je to určitě v pořádku.A to FIFO je pomocí LUTu v módu shiftregistr? Tam se při vstupu nového bitu posunou i všechny ostatní ne? U BRAM by to mělo bejt asi jedno (je na to právě určena).
Pak se koupí jiná série oddělovačů a při určité teplotě se zpětná proudová vazba v řízení motorů robota zhroutí.To bys mohl naměřit třeba ohřevem fénem nebo něčím takovým
.
11.12.2014 18:51
vlastikroot | skóre: 24
| blog: vlastikovo
| Milevsko
Delas si srandu ale v praci kolegovi prestaval fungovat program na FPGA nekde kolem 100°C, kdyz se v zesilovaci ohral vnitrek na 80°C, tak FPGA prestalo zpracovavat signal a v tu nejhorsi dobu (uprostred koncertu pro n tisic lidi) pustilo do koncu sum plnou urovni (nejakych 135dB akusticky).
On vedel, jak program upravit, aby casovani splnil, ale to se uz neveslo do FPGA - bylo vyrobenych hromada osazenych desek. Bylo to kruty, testoval to horkovzduskou a zkousel, az se tesne vesel a funguje to. Pro jistotu se jeste vsude daly chladice a deska se otocila, aby mela lepsi pristup vzduchu.
Tyhle FPGA docela zerou, topi jak FPGA, tak pameti a hlavne linearni LDO stabilizatory.
9.12.2014 00:40
pavlix | skóre: 54
| blog: pavlix
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.