Skip to content
Snippets Groups Projects
Commit 1e35b88e authored by bence98's avatar bence98
Browse files

JTAM impl, referencia fix, egyéb átvitelek

parent 9f850e29
No related branches found
No related tags found
No related merge requests found
...@@ -360,7 +360,7 @@ Ha nincs a RST lábat használó átvitel megnyitva, lehetőségünk van aszinkr ...@@ -360,7 +360,7 @@ Ha nincs a RST lábat használó átvitel megnyitva, lehetőségünk van aszinkr
\subsection{Átviteli módok} \subsection{Átviteli módok}
\subsubsection{JTAG} \subsubsection{JTAG}
% TODO \label{ssssec:JTAG xfer}
Az első és talán legfontosabb implementált átviteli mód a JTAG. Ez a 0. interfész 0x01/0x82 enpoint-párját használja, valamint az LDC TDI, TDO, TMS, TCK és JTREF lábait. Ezen az interfészen keresztül lehetséges az LDC-hez illesztett elektronika konfigurálása és hibakövetése. Az első és talán legfontosabb implementált átviteli mód a JTAG. Ez a 0. interfész 0x01/0x82 enpoint-párját használja, valamint az LDC TDI, TDO, TMS, TCK és JTREF lábait. Ezen az interfészen keresztül lehetséges az LDC-hez illesztett elektronika konfigurálása és hibakövetése.
\noindent\\A JTAG megnyitásához két Control blokkot kell kiadnunk: \noindent\\A JTAG megnyitásához két Control blokkot kell kiadnunk:
...@@ -409,6 +409,8 @@ A LDC kétféle módban tudja a JTAG interfészt kezelni: ...@@ -409,6 +409,8 @@ A LDC kétféle módban tudja a JTAG interfészt kezelni:
\item Ellenőrzés mód: ekkor a számítógép a TDI-vel együtt a várt TDO értékeket is elküldi, majd a transzfer után egy Control blokkal lekérdezi, hogy történt-e hiba (várttal nem egyező TDO érték) \item Ellenőrzés mód: ekkor a számítógép a TDI-vel együtt a várt TDO értékeket is elküldi, majd a transzfer után egy Control blokkal lekérdezi, hogy történt-e hiba (várttal nem egyező TDO érték)
\end{itemize} \end{itemize}
Visszaolvasás módban működik pl. a Boundary Scan, mert ott az eszköz ID code-ját vissza kell adnunk a számítógépnek. SVF fájlok letöltése (lásd lejjebb, az "FPGA konfigurációs fájlok" részben) során azonban tudjuk, hogy milyen TDO értéket várunk (ez benne van az SVF állományban). Így ahelyett, hogy visszaolvasnánk USB-n keresztül, és a számítógép hasonlítaná össze, használhatjuk az LDC ellenőrzéses módját, ezáltal USB sávszélességet takarítva meg.
\noindent Az ellenőrzést a következő kéréssel végezzük: \noindent Az ellenőrzést a következő kéréssel végezzük:
\noindent\textbf{URB Control blokk:}\\ \noindent\textbf{URB Control blokk:}\\
...@@ -517,7 +519,6 @@ Ellenőrzés módban a számítógépnek ugyanannyi bájtot kell visszaolvasnia, ...@@ -517,7 +519,6 @@ Ellenőrzés módban a számítógépnek ugyanannyi bájtot kell visszaolvasnia,
A visszaolvasott bájtok közül csak minden második a hasznos TDO adat, a többi bájt értéke 0.\cite{RT-dipterv} A visszaolvasott bájtok közül csak minden második a hasznos TDO adat, a többi bájt értéke 0.\cite{RT-dipterv}
\noindent\textbf{FPGA konfigurációs fájlok} \noindent\textbf{FPGA konfigurációs fájlok}
\label{ssssec:JTAG SVF}
A libxsvf-nek köszönhetően SVF és XSVF formátumú fájlokat képes a program natívan kezelni. Azonban a BIT (és JED) formátumok nem nyíltak, így azok kezeléséhez a Xilinx egyik segédprogramjával (iMPACT) át kell konvertálnom SVF-re. (ugyanezt teszi egyébként a Logsys GUI is). A segédprogrammal való kommunikációhoz a libc \texttt{popen} metódusát használom, ami a Unix pipe-okat használja (a Logsys GUI pedig temporális fájlokat hoz létre ugyanerre a célra). Azonban az iMPACT-nak nem lehet megmondani, hogy ne hozzon létre logfájlt, így hogy ne szemetelje tele a munkakönyvtárat, a szubprocessz elindítása előtt átlépek a \texttt{/tmp} könyvtárba, ami Unix-szerű rendszereken általában bárki által írható és nem perzisztens tároló. Ennek következtében azonban elveszítjük a relatív útvonalak használatának lehetőségét (hiszen mappát váltunk, és az így a \texttt{/tmp}-hez képest értelmeződne). Valamint mivel a terminálból olvasáskor a parancsok paramétereit szóközzel választom el, problémás a szóközt tartalmazó útvonalak használata. Speciális esetként beletettem, hogy az aposztrófok vagy idézőjelek közötti szóköz ne törje az argumentumlistát, de pl. nem támogatom a "\texttt{\textbackslash~}" formátumú escape-lést. Valamint ha egy útvonal tartalmaz aposztrófot ÉS idézőjelet IS, akkor nem reprezentálható. A libxsvf-nek köszönhetően SVF és XSVF formátumú fájlokat képes a program natívan kezelni. Azonban a BIT (és JED) formátumok nem nyíltak, így azok kezeléséhez a Xilinx egyik segédprogramjával (iMPACT) át kell konvertálnom SVF-re. (ugyanezt teszi egyébként a Logsys GUI is). A segédprogrammal való kommunikációhoz a libc \texttt{popen} metódusát használom, ami a Unix pipe-okat használja (a Logsys GUI pedig temporális fájlokat hoz létre ugyanerre a célra). Azonban az iMPACT-nak nem lehet megmondani, hogy ne hozzon létre logfájlt, így hogy ne szemetelje tele a munkakönyvtárat, a szubprocessz elindítása előtt átlépek a \texttt{/tmp} könyvtárba, ami Unix-szerű rendszereken általában bárki által írható és nem perzisztens tároló. Ennek következtében azonban elveszítjük a relatív útvonalak használatának lehetőségét (hiszen mappát váltunk, és az így a \texttt{/tmp}-hez képest értelmeződne). Valamint mivel a terminálból olvasáskor a parancsok paramétereit szóközzel választom el, problémás a szóközt tartalmazó útvonalak használata. Speciális esetként beletettem, hogy az aposztrófok vagy idézőjelek közötti szóköz ne törje az argumentumlistát, de pl. nem támogatom a "\texttt{\textbackslash~}" formátumú escape-lést. Valamint ha egy útvonal tartalmaz aposztrófot ÉS idézőjelet IS, akkor nem reprezentálható.
...@@ -728,6 +729,9 @@ Az átvitelt lezárni pedig a következőképpen lehet: ...@@ -728,6 +729,9 @@ Az átvitelt lezárni pedig a következőképpen lehet:
\item Bitmaszkok: \texttt{enum LogsysSerialPin} (\textit{include/logsys/serio.h:18}) \item Bitmaszkok: \texttt{enum LogsysSerialPin} (\textit{include/logsys/serio.h:18})
\end{itemize} \end{itemize}
\subsubsection{Egyéb átviteli módok}
Az LDC képes I\textsuperscript{2}C master és PIC ISP átvitelekre is, azonban ezekhez nem elérhető dokumentáció. Az I\textsuperscript{2}C átvitelhez létezett egy terminál app (az Interneten találni képet róla), azonban a futtatható állományt nem sikerült fellelnem, így ezeket nem tudtam beépíteni.
\pagebreak \pagebreak
\section{A driver felépítése} \section{A driver felépítése}
% TODO % TODO
...@@ -751,7 +755,6 @@ A függvénykönyvtár a \textit{src/shared} mappa fájljaiból fordul, valamint ...@@ -751,7 +755,6 @@ A függvénykönyvtár a \textit{src/shared} mappa fájljaiból fordul, valamint
\end{itemize} \end{itemize}
\subsection{JTAG implementáció} \subsection{JTAG implementáció}
% TODO JTAG, libxsvf
Az SVF fájlok feldolgozását a libxsvf végzi. A feldolgozást a \texttt{libxsvf\_play} függvény meghívásával indítjuk, aminek első paramétere egy \texttt{struct libxsvf\_host} típusú változó. Ez a struktúra definiálja a libxsvf számára a JTAG vonalak beállításához hívandó függvény-pointereket. Ezeket a callbackeket tartalmazza a \textit{src/shared/jconf.c} fájl. A függvény-implementációk neve szisztematikusan, a pointer nevéből egy "\texttt{lsvf\_host\_}" prefixszel képződik (azaz a \texttt{foo} metódust a \texttt{lsvf\_host\_foo} valósítaná meg). A továbbiakban ezekre a pointer nevével (a példámban a \texttt{foo}) hivatkozom. Az SVF fájlok feldolgozását a libxsvf végzi. A feldolgozást a \texttt{libxsvf\_play} függvény meghívásával indítjuk, aminek első paramétere egy \texttt{struct libxsvf\_host} típusú változó. Ez a struktúra definiálja a libxsvf számára a JTAG vonalak beállításához hívandó függvény-pointereket. Ezeket a callbackeket tartalmazza a \textit{src/shared/jconf.c} fájl. A függvény-implementációk neve szisztematikusan, a pointer nevéből egy "\texttt{lsvf\_host\_}" prefixszel képződik (azaz a \texttt{foo} metódust a \texttt{lsvf\_host\_foo} valósítaná meg). A továbbiakban ezekre a pointer nevével (a példámban a \texttt{foo}) hivatkozom.
A struktúra tartalmaz még egy \texttt{struct udata\_s}-re mutató pointert is, ahol tetszőleges felhasználói adatot tárolhatunk. Az én esetemben ebben található a LibUSB eszközre, illetve a nyitott SVF fájlra mutató pointer, a kiírandó, de még ki nem írt (LDC-nek el nem küldött) JTAG adatokat tároló puffer, valamint egy flag, hogy a legutolsó tranzakció (LDC-vel való kommunikáció) során lépett-e fel TDO összehasonlítási hiba. A struktúra tartalmaz még egy \texttt{struct udata\_s}-re mutató pointert is, ahol tetszőleges felhasználói adatot tárolhatunk. Az én esetemben ebben található a LibUSB eszközre, illetve a nyitott SVF fájlra mutató pointer, a kiírandó, de még ki nem írt (LDC-nek el nem küldött) JTAG adatokat tároló puffer, valamint egy flag, hogy a legutolsó tranzakció (LDC-vel való kommunikáció) során lépett-e fel TDO összehasonlítási hiba.
...@@ -775,6 +778,35 @@ A \texttt{realloc} hívást változatlanul továbbítom a libc felé. ...@@ -775,6 +778,35 @@ A \texttt{realloc} hívást változatlanul továbbítom a libc felé.
\subsubsection{\texttt{pulse\_tck}} \subsubsection{\texttt{pulse\_tck}}
Ez a JTAG konfiguráció "lelke". Nevével ellentétben nem csupán egy TCK pulzust ad ki, hanem rögtön be is állítja a kívánt TDI/TMS értékeket, sőt, a várt TDO-t is ekkor kapjuk meg (ha van). Ez a JTAG konfiguráció "lelke". Nevével ellentétben nem csupán egy TCK pulzust ad ki, hanem rögtön be is állítja a kívánt TDI/TMS értékeket, sőt, a várt TDO-t is ekkor kapjuk meg (ha van).
Ezeket az adatokat eltároljuk a \texttt{struct udata\_s}-ban található pufferbe, és ha szükséges, meghívjuk a \texttt{lsvf\_flush\_iobuf} függvényt, ami majd kiküldi az LDC-nek.
Visszatérési értékként a \texttt{struct udata\_s}-ban található hibaflaget adjuk. Ezáltal ugyan a libxsvf késleltetve értesül a TDO ellenőrzési hibáról, de a tapasztalat azt mutatja, hogy ez nem okoz problémát.
\subsubsection{\texttt{lsvf\_flush\_iobuf} és \texttt{lsvf\_write\_pack}}
A \texttt{lsvf\_flush\_iobuf} függvény végzi a munka oroszlánrészét: az ő dolga a pufferelt TMS, TDI, TDO és TDO maszk adatokból az LDC csomagformátumának megfelelő kérést előállítani.
A függvény feladata "összevárni" a homogén adatokat (legfeljebb 8-at), majd őket egy keretbe tenni. Ezért először eldönti, hogy TMS vagy TDI írással valósítsa meg.
\noindent\textbf{TMS írás}
A TMS írás feltétele, hogy a TDI "Don't Care" legyen (a kódban -1), a TMS pedig 0 vagy 1. A \texttt{dbit} egy ring countert valósít meg, ami az éppen írandó bitet jelöli ki. A \texttt{data} tárolja a kiírandó adatot, a \texttt{chk} a várt TDO értékeket, a \texttt{cmask} pedig a TDO maszkot.
Amíg a TMS írás feltétele fennáll, \texttt{data}-ban eltároljuk a kiírandó TMS értéket (a \texttt{dbit} által kijelölt biten), valamint ha TDO nem "Don't Care", akkor őt eltárojluk \texttt{chk}-ben és bebillentjük \texttt{cmask} megfelelő bitjét.
Ha már összegyűjtöttünk 8 TCK pulzust, vagy már nem TMS írás történik, akkor \texttt{bulk\_out}-ban létrehozunk egy keretet a kiszámított értékek számára.
\noindent\textbf{TDI írás}
A TDI írás feltétele, hogy a TDI 0 vagy 1 legyen, a TMS pedig az utolsó bit kivételével 0 (az utolsó bitnél lehet más is, az lesz az 1. bájt 6. bitje, lást \ref{ssssec:JTAG xfer}/JTAG adatátvitel). A \texttt{dbit} itt is az éppen írandó bitet jelöli ki. A \texttt{data} tárolja a kiírandó adatot, a \texttt{chk} a várt TDO értékeket, a \texttt{cmask} pedig a TDO maszkot. Különbség csupán a \texttt{tmsAfter} változó jelenléte.
Amíg a TDI írás feltétele fennáll, \texttt{data}-ban eltároljuk a kiírandó TDI értéket (a \texttt{dbit} által kijelölt biten), valamint ha TDO nem "Don't Care", akkor őt eltárojluk \texttt{chk}-ben és bebillentjük \texttt{cmask} megfelelő bitjét.
Ha már összegyűjtöttünk 8 TCK pulzust, vagy már nem TDI írás történik, esetleg elértünk egy TDI+TMS íráshoz (ami csak a TDI írás utolsó bitjeként szerepelhet), akkor \texttt{bulk\_out}-ban létrehozunk egy keretet a kiszámított értékek számára.
\noindent\textbf{Tranzakció}
Ezek után \texttt{lsvf\_write\_pack} feladata a keretek tömbjéből összeállítani egy Bulk átvitelt. Ehhez csupán sorosítania kell a tömböt, kiküldeni a 0x01-es végpontra, majd megnézni, történt-e hiba az összehasonlítás során.
\pagebreak \pagebreak
\section{A parancssori alkalmazás felépítése} \section{A parancssori alkalmazás felépítése}
A konzolos teszt alkalmazás a \texttt{logsys-test} fájlnevet viseli. A programon belül különféle parancsokat adhatunk ki, amiket az LDC végre fog hajtani. A konzolos teszt alkalmazás a \texttt{logsys-test} fájlnevet viseli. A programon belül különféle parancsokat adhatunk ki, amiket az LDC végre fog hajtani.
...@@ -827,7 +859,7 @@ Ennek a kategóriának nincsenek operációi. Kiadáskor kiírja az LDC állapot ...@@ -827,7 +859,7 @@ Ennek a kategóriának nincsenek operációi. Kiadáskor kiírja az LDC állapot
\subsubsection{\texttt{conf}} \subsubsection{\texttt{conf}}
\textbf{Operációk:} \textbf{Operációk:}
\begin{itemize} \begin{itemize}
\item \texttt{<formátum> <fájl>}: Konfiguráció letöltése. A \texttt{<formátum>} lehet \texttt{svf}, \texttt{xsvf}, \texttt{bit} vagy \texttt{jed}. A \texttt{<fájl>} egy \textbf{abszolút} elérési útvonal (lásd \ref{ssssec:JTAG SVF}/FPGA konfigurációs fájlok) \item \texttt{<formátum> <fájl>}: Konfiguráció letöltése. A \texttt{<formátum>} lehet \texttt{svf}, \texttt{xsvf}, \texttt{bit} vagy \texttt{jed}. A \texttt{<fájl>} egy \textbf{abszolút} elérési útvonal (lásd \ref{ssssec:JTAG xfer}/FPGA konfigurációs fájlok)
\end{itemize} \end{itemize}
\subsubsection{\texttt{quit}} \subsubsection{\texttt{quit}}
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment