abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 13:33 | Zajímavý článek

Craig Loewen se v příspěvku na blogu Microsoftu věnuje novinkách ve WSL (Windows Subsystem pro Linux), které přinese Windows 10 1903. Jedná se především o možnost přístupu z Windows (Průzkumník souborů, explorer.exe) k souborům v nainstalovaných linuxových distribucích. Použit je protokol 9P.

Ladislav Hagara | Komentářů: 3
dnes 10:44 | Zajímavý software

Byl vydán Hangover ve verzi 0.4.0. Jedná se o součást projektu Wine umožňující spouštět Windows aplikace pro x86 a x86_64 na architektuře ARM64 (AArch64). Zdrojové kódy této alfa verze jsou k dispozici na GitHubu.

Ladislav Hagara | Komentářů: 0
včera 03:00 | Nová verze

Byla vydána nová major verze 3.0.0-1 linuxového prostředí pro operační systémy Windows Cygwin (Wikipedie). Přehled novinek v oficiálním oznámení.

Ladislav Hagara | Komentářů: 6
včera 02:00 | Nová verze

Byl vydán Debian 9.8, tj. osmá opravná verze Debianu 9 s kódovým názvem Stretch. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Předchozí instalační média Debianu 9 Stretch lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.

Ladislav Hagara | Komentářů: 0
15.2. 12:33 | Pozvánky

Příští týden bude na MFF UK zahájena série přednášek o architektuře a implementaci operačních systémů. Mezi přednášejícími budou odborníci z firem Kernkonzept, Oracle, Red Hat, SUSE či SYSGO. Pokud si chcete rozšířit obzory (virtualizace, ptrace, ZFS, kdump, ...), vyberte si z harmonogramu téma, které vás zajímá a přijďte. Přednášky se konají každý čtvrtek od 15:40 v učebně S4 na Malostranském náměstí 25 v Praze. Přednášky jsou přístupné veřejnosti (registrace není nutná), studenti UK a ČVUT si je mohou zapsat jako standardní předmět.

Vojtěch Horký | Komentářů: 14
15.2. 05:00 | Nová verze

Bylo vydáno Ubuntu 18.04.2 LTS, tj. druhé opravné vydání Ubuntu 18.04 LTS s kódovým názvem Bionic Beaver. Přehled novinek v poznámkách k vydání a v přehledu změn.

Ladislav Hagara | Komentářů: 0
15.2. 03:00 | Zajímavý software

Git History umí u souborů v git repozitářích zajímavým způsobem zobrazit jejich historii a následně jednotlivé změny, viz animovaný gif. Použít jej lze lokálně nebo aktuálně na soubory umístěné na GitHubu. Máte-li ve webovém prohlížeči zobrazen soubor umístěný na GitHubu, nahraďte v URL doménu github.com doménou github.githistory.xyz a nové URL odešlete. Využít lze také rozšíření Chrome i Firefoxu. V plánu je vedle GitHubu také podpora GitLabu a Bitbucketu.

Ladislav Hagara | Komentářů: 3
15.2. 01:00 | Nová verze

Byla vydána verze 1.0 webové a na frameworku Electron postavené desktopové verze svobodného decentralizovaného skupinového komunikátoru Riot (Wikipedie) využívajícího protokolu Matrix (Wikipedie). Přehled novinek i s náhledy v příspěvku na blogu. Zdrojové kódy jsou k dispozici na GitHubu.

Ladislav Hagara | Komentářů: 4
14.2. 14:22 | Nová verze

Společnost Collabora oznámila vydání verze 4.0 online kancelářského balíku Collabora Online a také Collabora Online Development Edition (CODE) pro domácí uživatele. Kancelářský balík vychází z LibreOffice Online (cgit).

Ladislav Hagara | Komentářů: 0
14.2. 12:11 | Nová verze

Byla vydána verze 241 správce systému a služeb systemd (GitHub, NEWS). Řešeny jsou také bezpečnostní chyby.

Ladislav Hagara | Komentářů: 0
Máte v desktopovém prostředí zapnutou zvukovou znělku po přihlášení se do systému?
 (7%)
 (1%)
 (90%)
 (1%)
Celkem 339 hlasů
 Komentářů: 11, poslední 14.2. 07:59
Rozcestník

Programovatelná logika VI: Asynchronní signály a hod. domény

2.12.2014 13:12 | Přečteno: 1883× | Výběrový blog

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.

4 Asynchronní signály a hodinové domény

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ě.

4.1 Vliv asynchronních signálů

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.

4.1.1 Metastabilita

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.

4.1.2 (Ne)koherence

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.

4.2 Přechod mezi hodinovými doménami

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.

4.2.1 Jednotlivé signály

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.

4.2.2 Pomalu se měnící vektory

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.

4.2.3 Čítače

Č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.

4.2.4 Rychlé datové cesty

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í.

4.3 Redukce počtu hodinových domén

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.

       

Hodnocení: 100 %

        špatnédobré        

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Vložit další komentář

2.12.2014 13:23 Dadam | skóre: 12 | blog: dadamovo
Rozbalit Rozbalit vše Re: Programovatelná logika VI: Asynchronní signály a hod. domény
Proč jsem nedostal článek v RSS? Cesta: http://www.abclinuxu.cz/auto/blog/digital_design.rss
A i B mají svoje výhody a nevýhody. Vyberte si to, co vám vyhovuje víc, a necpěte A tam, kam patří B.
2.12.2014 15:11 Frenk | blog: cojavim
Rozbalit Rozbalit vše Re: Programovatelná logika VI: Asynchronní signály a hod. domény
Díky za tento blog, já se tím snad zase začnu zabývat, na škole mne to velmi bavilo a měl jsem k tomu i diplomku, i když hodně chyběla praxe nejdál jsme se ve VHDL dostali ke kodovému zámku a vůbec první předmět okolo byl ještě v ABELu na CPLD. :)
2.12.2014 22:04 pc2005 | skóre: 37 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: Programovatelná logika VI: Asynchronní signály a hod. domény
2.12.2014 23:18 Pavel Píša | skóre: 12
Rozbalit Rozbalit vše Re: Programovatelná logika VI: Asynchronní signály a hod. domény

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.vhd

Přidal jsem ještě ke komponentě i BSD licenci, kdyby to někdo chtěl použít přímo, tak aby neměl obavy.

3.12.2014 09:08 hw | skóre: 22 | blog: Digital Design
Rozbalit Rozbalit vše Re: Programovatelná logika VI: Asynchronní signály a hod. domény

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.

3.12.2014 09:35 hw | skóre: 22 | blog: Digital Design
Rozbalit Rozbalit vše Re: Programovatelná logika VI: Asynchronní signály a hod. domény

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ů.

3.12.2014 10:23 Pavel Píša | skóre: 12
Rozbalit Rozbalit vše Re: Programovatelná logika VI: Asynchronní signály a hod. domény

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_CPU

Na desku máme bare-metal support, běží na ní MBED.org a RTEMS.

3.12.2014 13:07 hw | skóre: 22 | blog: Digital Design
Rozbalit Rozbalit vše Re: Programovatelná logika VI: Asynchronní signály a hod. domény

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ů.

3.12.2014 17:08 Pavel Píša | skóre: 12
Rozbalit Rozbalit vše Re: Programovatelná logika VI: Asynchronní signály a hod. domény
U tohoto řešení jsem právě měl obavu z toho, co se stane, když se vlivem změny teploty akorát clk_fb a clk sejsou tak, že posun hodin clk proti clk_fb bude rovný/bude fluktuovat okolo doby rovné zpoždění výstupu registru miso_r + požadavek na předstih miso_x. Pak teoreticky jeden bit občas mohu navzorkovat dvakrát a pak zase nějaký bit přeskočit.
3.12.2014 22:03 hw | skóre: 22 | blog: Digital Design
Rozbalit Rozbalit vše Re: Programovatelná logika VI: Asynchronní signály a hod. domény

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.

4.12.2014 06:30 pc2005 | skóre: 37 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: Programovatelná logika VI: Asynchronní signály a hod. domény
Já mám dojem, že to zpoždění hodin a frame synchronizace před SPI zařízení může být klidně delší, než když se udělá zpětná vazba hned na výstupu čipu. Na něco takového jsem narazil s jedním ADC.

BTW pokud by součástí toho FIFO byla třeba paralelizace dat na sběrnici, tak by bylo docela užitečné (většina SPI řadičů stejně má nějaký vyrovnávací buffery).
4.12.2014 11:44 Pavel Píša | skóre: 12
Rozbalit Rozbalit vše Re: Programovatelná logika VI: Asynchronní signály a hod. domény
O přijímači a převodu na paralelní data v asynchronní doméně jsem uvažoval. Nakonec stejně končí v BRAM. Ale vzhledem k tomu, že by tam pak musel být celý stavový automat včetně kontroly CRC nebo by se na druhé straně muselo počítat CRC z paralelních dat, tak jsem volil možnost přes rozhraní domén přenést je bitový stream. Přitom je to udělané jako n-bitové (fifo_len_g) fifo/registr, který se cyklicky plní a vyčítání se provádí se zpožděním rovnajícím se půlce délky FIFO. Bit obsahu FIFO, který bude z druhé clock domény čtený je tedy vždy stabilní alespoň po fifo_len_g/2-1 clocků. Jediný signál, který není mezi doménami přenášený "staticky" je acd_sync_i, ale ten prochází fifo_len_g/2 registry, takže by se metastabilní stav neměl nikdy skrz dostat.

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.

Určité pochyby (nejistotu) o mém návrhu vyjádřil i můj kolega, který se FPGA zabývá na mnohem vyšší úrovni. Proto jsem se ptal zde, abych získal více názorů. Díky za ně.

Jinak v reálném nasazení řešení chodí spolehlivě. Jenže předpokládám, že by se i problém s návrhem, který by přestup domén vůbec neřešil, nemusel po roky projevit. Pak se koupí jiná série oddělovačů a při určité teplotě se zpětná proudová vazba v řízení motorů robota zhroutí. Podle grade mají totiž oddělovače ISO7240M zpoždění od od 10 do 42 ns, to je na dvou v sérii rozptyl +/-32 ns a perioda hodin je 20 ns. Přitom rise/fall nesymetrie je okolo 2 ns, stejně jako rozdíl zpoždění kanálů uvnitř jednoho pouzdra.
9.12.2014 01:40 pc2005 | skóre: 37 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: Programovatelná logika VI: Asynchronní signály a hod. domény
nebo by se na druhé straně muselo počítat CRC z paralelních dat
No 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 :-D.
10.12.2014 17:45 Pavel Píša | skóre: 12
Rozbalit Rozbalit vše Re: Programovatelná logika VI: Asynchronní signály a hod. domény
FIFO není navržené jako posuvný registr. Je navržené jako n samostatných bitových registrů, které jsou adresované samostatným čítačem dekódovaným na 1 z n na vstupu (např přivedeným na CE déček) a druhým čítačem a multiplexerem z n na jeden signál na výstupu. Takže je to v podstatě BRAM o třeba 8 x 1-bit. Ale tím, že je to z bitů, tak se na těch několik bitů neplýtvá BRAM, kterých je omezený počet. Přímý přechod domén se pak stará pouze o ten jeden signál, který s určitým zpožděním spustí čítač na výstupu.
vlastikroot avatar 11.12.2014 18:51 vlastikroot | skóre: 24 | blog: vlastikovo | Milevsko
Rozbalit Rozbalit vše Re: Programovatelná logika VI: Asynchronní signály a hod. domény

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.

Sg1-game | We will destroys the Christian's legion ... and the cross, will be inverted | IP 80.188.182.6
pavlix avatar 9.12.2014 00:40 pavlix | skóre: 54 | blog: pavlix
Rozbalit Rozbalit vše Re: Programovatelná logika VI: Asynchronní signály a hod. domény
Přidal jsem do digestu, mírný odklon od linuxu nevidím jako závadu :).
Já už tu vlastně ani nejsem. Abclinuxu umřelo.

Založit nové vláknoNahoru

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.