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

[Dadam]

Proč jsem nedostal článek v RSS? Cesta: http://www.abclinuxu.cz/auto/blog/digital_design.rss

[Frenk]

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. :)

[pc2005]

Skvělý článek.

[Pavel Píša]

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.

[hw]

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.

[hw]

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

[Pavel Píša]

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.

[hw]

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

[Pavel Píša]

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.

[hw]

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.

[pc2005]

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

[Pavel Píša]

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.

[pc2005]

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 .

[Pavel Píša]

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]

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.

[pavlix]

Přidal jsem do digestu, mírný odklon od linuxu nevidím jako závadu :).