% Diplomova prace: pos_buf
% Michal Trs
% Návrh vlastního řešení

Vzhledem k tomu, že neexistuje komplexní řešení, bylo nutné vyvinout vlastní s ohledem na Combo 4SFPRO/OC-48 kartu. V této kapitole je uveden ideový návrh, detailnější návrh, ze kterého vychází implementace, je popsán v následující kapitole.



\section{Blokový návrh}
Navržené blokové schéma je dané jednotlivými kroky, které je nutné provádět během příjmu/vysílání SONET/SDH rámce.

S ohledem na čas vývoje jsem se snažil využít již hotové jednotky s odpovídající licencí. Těmto požadavků odpovídají pouze Xilinx aplikační příklady a generické jednotky vyvinuté v rámci projektu Liberouter.

Jednotka \emph{pos\_buf} přímo neimplementuje rozhraní RocketIO-X, ale poskytuje k němu 16b rozhraní. Tato jednotka je vložena do \uv{obálky} \emph{pos\_buf\_rio}, která instancuje RocketIO-X rozhraní a komponentu pro změnu datové šířky. Důvodem k takové implementaci je požadavek na externí násobičku nebo druhý přesný krystal o frekvenci 124,416 MHz, který na kartě není k dispozici (viz. kapitola \ref{par:xapp649}). Toto řešení přináší výhody v následném testování, kdy je od sebe odděleno poměrně složité rozhraní RocketIO a vlastní jednotka \emph{pos\_buf}.

\begin{figure}[!htp]
\begin{center}
\scalebox{0.8}{\includegraphics{img/block_sch.pdf}}
\end{center}
\caption{Navrhované blokové schéma jednotky pos\_buf}
\label{img:block_sch}
\end{figure}

Obrázek \ref{img:block_sch} představuje blokové schéma vlastního řešení jednotky pro zpracování PoS. PPP je stavový protokol a vyžaduje propojení vstupní a výstupní části. Proto je návrh jednotky řešen jako celek. Budu jej označovat \emph{pos\_buf}. V následujícím textu nastíním implementaci této jednotky.



\section{SONET/SDH (de)framer}
Pro realizaci fyzické vrstvy není možné použít žádné z popsaných existujících
řešení. Řešení f. Altera je licenčně svázáno s FPGA obvody této firmy. Řešení f. Xelic není příliš dokumentováno a jeho koupě by byla riskantní. Z těchto důvodů je nezbytné tuto jednotku navrhnout. Při vlastním návrhu bylo využito Xilinx aplikačních příkladů a blokových schémat od firmy Altera.

Blokový návrh (obrázek \ref{img:sonet_framer_blsch}) je inspirován SONET/SDH Framerem od f. Altera. Bloky označené šedou barvou jsou již hotové (xapp), ostatní bloky je nutné implementovat. Níže jsou popsány části, ze kterých se jednotka skládá.

\begin{figure}[!htp]
\begin{center}
\scalebox{0.9}{\includegraphics{img/sonet_framer_blsch.pdf}}
\end{center}
\caption{Blokové schéma SONET/SDH (de)frameru}
\label{img:sonet_framer_blsch}
\end{figure}


\subsection{Rocket IO komponenta (RocketIO\_comp)}
Tato komponenta není součástí SONET/SDH (de)frameru, ale obálky \emph{pos\_buf\_rio}. Popisuji ji na tomto místě z důvodů přímé návaznosti na SONET/SDH (de)framer. Zahrnuje v sobě kódy z core generátoru pro zpřístupnění Rocket IO-X rozhraní. Pro přenosovou rychlost \mbox{2.488 Gb/s} je doporučená datová šířka 16b. Combo 4SFPRO karta je osazena oscilátorem o frekvenci \mbox{155.52 MHz} což odpovídá 2.488 Gb / 16. Použité nastavení GT10\_OC48\_2 je popsáno v \cite{ug035} na str. 195. Tato konfigurace poskytuje 20b datovou šířku, protože je vnitřně uzpůsobena pro kódování 8/10. Z tohoto důvodu je hned za RocketIO rozhraním připojena xapp649 \cite{xapp649}, která převádí 20b na 16b.


\subsection{Generátor pozice (position\_gen)}
Jedná se o dva čítače, které generují pozice SONET/SDH rámce. Výstupem této jednotky je pozice v hlavičce rámce a signál, který přepíná multiplexer mezi hlavičkou a daty.

\subsection{Generování (overhead\_gen) a zpracování (overhead\_proc) SONET/SDH hlaviček}
Jednotka pro generování hlavičky obsahuje paměť, ve které jsou uloženy jednotlivé položky. Čítače z generátoru pozic slouží jako adresa do paměti. Některé údaje je nutné počítat přímo z dat (kontrolní součty, ukazatel na data, ...).

Naopak pro ověření informací v hlavičce slouží overhead\_proc. Plná implementace je však nepovinná. Např. chyby v komunikačním kanále můžeme detekovat až při ověření kontrolního součtu po HDLC dekapsulaci. Pro naši aplikaci postačí implementovat pouze položky \uv{Požadováno} z tabulky \ref{tab:reduce_toh} (převzato z ITU-T G.707 \cite{itu707} str.85).

\begin{table}[!htp]
   \begin{center}
   \begin{tabular}{|l|l|l|}
      \hline
      SOH byte & Vysílací část & Přijímací část \\
      \hline \hline
         A1, A2 & Požadováno & Požadováno \\ \hline
         J0-Z0/C1 & Nepovinné & Nepovinné \\ \hline
         B1 & Požadováno & Nepoužito \\ \hline
         E1 & Nepoužito & Nepoužito \\ \hline
         F1 & Nepoužito & Nepoužito \\ \hline
         D1-D3 &Nepoužito & Nepoužito \\ \hline
         B2 & Požadováno & Požadováno \\ \hline
         K1, K2 (APS) & Nepovinné & Nepovinné \\ \hline
         K2 (MS-AIS) & Požadováno & Požadováno \\ \hline
         K2 (MS-RDI) & Požadováno & Požadováno \\ \hline
         D4-D12 & Nepoužito & Nepoužito \\ \hline
         S1 & Nepoužito, generováno 00001111 & Nepoužito \\ \hline
         M1 & Požadováno & Nepovinné \\ \hline
         E2 & Nepoužito & Nepoužito \\ \hline
      \hline
   \end{tabular}
   \end{center}
   \caption{Redukované TOH položky}
   \label{tab:reduce_toh}
\end{table}



\subsection{POS scrambler}
Implementuje polynom pro kódování dat (payload) $1 + x^{43}$ popsaný v RFC 2615 \cite{rfc2615}.


\subsection{Discard FIFO}
Zaobaluje FIFO paměť \cite{liberouter} z projektu Liberouter. Přidává možnost odstranění flagu 0x7E z dat. Flag buď není do FIFO paměti vůbec vložen, nebo naopak je vyčten a není poslán na výstup. Tato funkcionalita je zavedena k odstranění přeplňování FIFO paměti, ke které by jinak docházelo důsledkem vkládání SONET/SDH hlavičky.


\subsection{Fill FIFO}
Tato jednotka generuje nepřetržitý datový tok. Data jsou do FIFO paměti ukládána pouze, přichází-li SONET/SDH data (SPE). Tím by docházelo k vyprázdnění FIFO paměti a možnému přerušení rámce. Proto je výstupní datový tok doplněný o flagy 0x7E ve vhodných místech. Vhodným místem se rozumí situace, kdy je flag ve výstupních datech z FIFO paměti.



\section{HDLC kontrolér}

Na linkové vrstvě je situace obdobná. HDLC kontrolérů je dostupných několik, ale vždy jen pro datovou cestu širokou 8b. Na obrázku \ref{img:multi8b_path} je návrh jak zapojit dva (snadno rozšířitelné pro N) 8b HDLC (PPP) kontroléry.

\begin{figure}[!htp]
\begin{center}
\scalebox{0.75}{\includegraphics{img/multi8b_path.pdf}}
\end{center}
\caption{Paralelní zapojení 8b HDLC kontrolérů}
\label{img:multi8b_path}
\end{figure}

Obrázek popíšu z levé strany. Na vstupu je \uv{demultiplexor}, který je pravidelně přepínán po průchodu celého rámce. Rámec je uložen ve FIFO paměti o datové šířce 16b. Z ní jsou data vyčítána 2x pomaleji (na stejné hodinové frekvenci) a převedeny na datovou šířku 8b, zpracovány HDLC (PPP) kontrolérem. Poté jsou převedeny zpět na 16b a uloženy do vyrovnávací FIFO paměti. Odtud jsou vyčítány přes \uv{multiplexor} plnou rychlostí. Multiplexor je opět přepínán po průchodu celého rámce.

Druhou možností je napsat vlastní HDLC kontrolér, který bude nativně 16b. Tento přístup je vhodnější, protože zabere přibližně jen 2x víc zdrojů na čipu než HDLC 8b. U prvního řešení musíme započítat 2x FIFO16, multiplexor, demultiplexor, čítač pro přepínání mezi toky a registry pro změnu datové šířky.

Z těchto důvodů budu realizovat druhý návrh, tj. nativně 16b HDLC kontrolér. Realizován bude pomocí konečných automatů, konkrétně dvou na vysílací a dvou na přijímací straně. První automat vytváří HDLC protokol, tj. vkládá pole address, control a kontrolní součet. Následuje automat, který se stará o tzv. \uv{Byte stuffing}. Pokud nejsou žádná data vysílána, generuje výplň 0x7E. Ve vysílaných datech nahrazuje byty 0x7D a 0x7E za 0x7D a xor původního bytu s 0x20. Analogická situace je na přijímající straně.



\section{PPP kontrolér}
\label{par:ppp}
Poměrně dost času jsem věnoval hledáním PPP kontroléru, který implementuje LCP a NCP protokol a je napsaný v jazyce, který se dá syntetizovat. Mé hledání bylo však neúspěšné. Proto navrhnu vlastní (nativně 16b) kontrolér.

\begin{figure}[!htp]
\begin{center}
\scalebox{1.0}{\includegraphics{img/ppp_blsch.pdf}}
\end{center}
\caption{Návrh PPP kontroléru}
\label{img:ppp_blsch}
\end{figure}

Jedná-li se o rámec, ve kterém je vložen paket síťové vrstvy (pole \uv{Protocol} v PPP rámci má hodnotu menší než 0x4000) musí být co nejrychleji přenášen ze vstupu na výstup. V opačném případě se jedná o řídicí paket linkové vrstvy, a proto je přesměrován do řídicí jednotky. Pro implementaci se nabízí konečný automat, nebo jednoduchý procesor. Druhá možnost je vhodnější. Umožňuje postupné přidávání dalších protokolů (PAP, CHAP, ...) bez složitého zásahu do HW. Také se tím zjednoduší implementace. Jako procesor bude použit softprocesor \mbox{PicoBlaze} \cite{ug129} \cite{pb_manual}, který svým výkonem pro tuto aplikaci postačuje. Pro naši aplikaci postačí implementovat pouze základní řídicí protokol LCP. Vzhledem k navržené architektuře je možné následně přidat další protokoly dopsáním programu pro procesor. Na obrázku \ref{img:ppp_blsch} je pro představu blokové schéma této jednotky.



\section{Nastavení a informace o stavu jednotky}
Přes tuto jednotku bude možné konfigurovat celou jednotku a naopak o ní zjišťovat informace. Bude jen zaobalovat kontrolní výstupy z ostatních jednotek. Připojení k SW bude realizováno přes sběrnici MI32, která je vyvinuta v rámci projektu Liberouter. Ve schématu je pod názvem Status/control unit.

