| 1 |
71 |
guanucolui |
%$Id $
|
| 2 |
|
|
\documentclass[11pt,a4paper,oneside]{article}
|
| 3 |
|
|
\usepackage[utf8]{inputenc}
|
| 4 |
|
|
\usepackage[spanish]{babel}
|
| 5 |
|
|
\usepackage{acronym}
|
| 6 |
|
|
\usepackage{graphicx}
|
| 7 |
|
|
\usepackage{multicol}
|
| 8 |
|
|
\usepackage{balance}
|
| 9 |
|
|
%\usepackage{subfig}
|
| 10 |
|
|
%\usepackage[cm]{fullpage}
|
| 11 |
|
|
\usepackage[a4paper]{geometry}
|
| 12 |
|
|
%\usepackage{subfigure}
|
| 13 |
|
|
\usepackage{float}
|
| 14 |
|
|
\usepackage{fancyhdr}
|
| 15 |
|
|
\usepackage{caption}
|
| 16 |
|
|
\usepackage{subcaption}
|
| 17 |
|
|
\title{Plataforma de hardware recofigurable \\ \small{JTAG -- Configuración OOCD-Links, (\textsl{Hardware \& Software})}}
|
| 18 |
|
|
\author{Luis A. Guanuco}
|
| 19 |
|
|
\date{\today}
|
| 20 |
|
|
\pagestyle{fancy}
|
| 21 |
|
|
\addtolength{\textheight}{2cm}
|
| 22 |
|
|
%\addtolength{\voffset}{-1cm}
|
| 23 |
|
|
%\addtolength{\textwidth}{1cm}
|
| 24 |
|
|
|
| 25 |
|
|
\begin{document}
|
| 26 |
|
|
|
| 27 |
|
|
\maketitle{}
|
| 28 |
|
|
|
| 29 |
|
|
\chead{\includegraphics[width=0.1\textwidth]{images/logov2_ES}}
|
| 30 |
|
|
%\begin{figure}[h]
|
| 31 |
|
|
% \centering
|
| 32 |
|
|
% \includegraphics[width=0.3\textwidth]{images/logov2_ES}
|
| 33 |
|
|
%\end{figure}
|
| 34 |
|
|
|
| 35 |
|
|
\section{Introducción}
|
| 36 |
|
|
\label{sec:intro}
|
| 37 |
|
|
|
| 38 |
|
|
Una gran parte del proyecto \emph{\ac{PHR}} se basa en la implementación de códigos de programación en diferentes lenguajes. En esta etapa
|
| 39 |
|
|
El presente reporte desarrolla la continuación del armado, testeo de las distintas placas que conformarán la \emph{\ac{PHR}}.Gran parte del informe se basa en el \textsl{software} que permitirá la comunicación entre la PC y el programador \ac{JTAG}.
|
| 40 |
|
|
|
| 41 |
|
|
\section{Programador \ac{JTAG}}
|
| 42 |
|
|
\label{sec:prog-jtag}
|
| 43 |
|
|
Gran parte de los \textsl{scripts} utilizados se obtuvieron del manual de usuario de \ac{OpenOCD} que se encuentra publicado en la web. Se recuerda que anteriormente al uso de \ac{OpenOCD}, se intentó utilizar el \textsl{software} Ur\ac{JTAG}, pero debido a la limitaciones que presentaba la versión estable, se optó por cambiarlo. Además existía mayor documentación de \ac{OpenOCD} que de UrJTAG.
|
| 44 |
|
|
|
| 45 |
|
|
\subsection{\textsl{Software} \ac{OpenOCD}}
|
| 46 |
|
|
\label{sec:soft-openocd}
|
| 47 |
|
|
En el proceso de lograr obtener el \textsl{software} funcional, se realizó un gran trabajo que se podría diferenciar en tres etapas:
|
| 48 |
|
|
\begin{itemize}
|
| 49 |
|
|
\item Instalación del \textsl{software} \ac{OpenOCD}
|
| 50 |
|
|
\item \textsl{Interface}
|
| 51 |
|
|
\item \textsl{Target}
|
| 52 |
|
|
\end{itemize}
|
| 53 |
|
|
|
| 54 |
|
|
\subsubsection{Instalación del \textsl{software} \ac{OpenOCD}}
|
| 55 |
|
|
Para la instalación se recurrió a la documentación del \textsl{software}. En dicho documento se hace referencia a los requerimientos para cada \ac{SO}. Como ya se mencionó en anteriormente reportes, se utilizará herramientas libres, por lo que se realizará la instalación en un \ac{SO} GNU/Linux Debian ``Squeeze'' 6.0.
|
| 56 |
|
|
|
| 57 |
|
|
\subsubsection{\textsl{Interface}}
|
| 58 |
|
|
El \textsl{Interface} hace referencia al \textsl{hardware} que realiza el enlace entre el dispositivo que queremos programar y la PC. En éste caso el \textsl{interface} será nuestra placa OOCD-Links. \ac{OpenOCD} dispone de \textsl{scripts} para varios \textsl{interface} entre los cuales se encuentra nuestra placa programadora. La información que proporciona éste código hace a que tipo de driver se utilizará como así también identificación del dispositivo central. A continuación se puede ver la estructura del archivo \texttt{oocdlink.cfg}.
|
| 59 |
|
|
\begin{verbatim}
|
| 60 |
|
|
#
|
| 61 |
|
|
# Joern Kaipf's OOCDLink
|
| 62 |
|
|
#
|
| 63 |
|
|
# http://www.joernonline.de/contrexx2/cms/index.php?page=126
|
| 64 |
|
|
#
|
| 65 |
|
|
|
| 66 |
|
|
interface ft2232
|
| 67 |
|
|
ft2232_device_desc "OOCDLink"
|
| 68 |
|
|
ft2232_layout oocdlink
|
| 69 |
|
|
ft2232_vid_pid 0x0403 0xbaf8
|
| 70 |
|
|
jtag_khz 5
|
| 71 |
|
|
\end{verbatim}
|
| 72 |
|
|
|
| 73 |
|
|
\subsubsection{\textsl{Target}}
|
| 74 |
|
|
\textsl{Target} define las especificaciones del \textsl{hardware} al cual queremos acceder con el \textsl{interface} OOCD-Links. Al igual que con los \textsl{interfaces}, \ac{OpenOCD} dispone de \textsl{scripts} con varias \textsl{targets} conocidas. En nuestro caso vamos a utilizar éstos archivos como ejemplo para configurar y adaptar a nuestra placa de prueba. Por último se probará agregar varios dispositivos al archivo que se generé y poder programarlos a la vez con la placa OOCD-Links.
|
| 75 |
|
|
|
| 76 |
|
|
\subsection{Documentación de comandos y \textsl{scripts}}
|
| 77 |
|
|
Luego de la configuración del \textsl{software} \ac{OpenOCD}, se procede a generar código de programa que nos permita realizar las tareas que necesitamos para nuestros proyecto \emph{\ac{PHR}}.
|
| 78 |
|
|
En principio se agregarán comandos útiles que servirán en general para cualquier dispositivo. Entre ellos se puede destacar,
|
| 79 |
|
|
\begin{itemize}
|
| 80 |
|
|
\item Identificar información de un dispositivo sin datos del proveedor, para agregarlo a una cadena \ac{JTAG} como \ac{TAP}.
|
| 81 |
|
|
\item Configurar dispositivo en modo \textsl{halt}.
|
| 82 |
|
|
\end{itemize}
|
| 83 |
|
|
|
| 84 |
|
|
\subsubsection{Agregar \ac{TAP}}
|
| 85 |
|
|
Para acceder a un dispositivo mediante el protocolo \ac{JTAG}, se debe proporcionar información del \textsl{hardware} al \textsl{interface}. Muchas veces ésta información no se encuentra fácil de acceder en la hoja de datos de dichos dispositivos por lo que \ac{OpenOCD} dispone de un modo \textsl{Autoprobing}, para más información sobre éste modo se puede obtener del Manual de Usuario de \ac{OpenOCD} en la sección 10.7 Autoprobing.
|
| 86 |
|
|
En definitiva, para capturar la información del dispositivo conectado se debe generar una archivo \texttt{openocd.cfg} base como el que se muestra a continuación,
|
| 87 |
|
|
\begin{verbatim}
|
| 88 |
|
|
# OpenOCD configuration script
|
| 89 |
|
|
# 2013-03-25 lguanuco
|
| 90 |
|
|
# Hardware:
|
| 91 |
|
|
# - OOCD-Link-s
|
| 92 |
|
|
|
| 93 |
|
|
# ("3": max. verbosity level)
|
| 94 |
|
|
debug_level 3
|
| 95 |
|
|
# (set log file)
|
| 96 |
|
|
log_output out.log
|
| 97 |
|
|
|
| 98 |
|
|
source [find core.cfg]
|
| 99 |
|
|
|
| 100 |
|
|
# 3. Other configs
|
| 101 |
|
|
|
| 102 |
|
|
reset_config trst_and_srst
|
| 103 |
|
|
jtag_rclk 8
|
| 104 |
|
|
\end{verbatim}
|
| 105 |
|
|
Luego de correr \ac{OpenOCD}, se debe acceder al archivo de salida con el nombre que se asignó en el archivo \texttt{openocd.cfg}, \texttt{out.log}. Este archivo registra todos los mensajes de salida que genera \ac{OpenOCD}, a continuación se muestra parte de éste archivo donde se puede observar información útil para generar el \ac{TAP} de dicho dispositivo.
|
| 106 |
|
|
\begin{verbatim}
|
| 107 |
|
|
...
|
| 108 |
|
|
Debug: 129 273 core.c:323 jtag_call_event_callbacks(): jtag event: TAP reset
|
| 109 |
|
|
Warn : 130 359 core.c:1145 jtag_examine_chain(): AUTO auto0.tap - use "jtag newtap auto0 tap -expected-id 0x4f1f0f0f ..."
|
| 110 |
|
|
Debug: 131 359 core.c:1323 jtag_tap_init(): Created Tap: auto0.tap @ abs position 0, irlen 0, capture: 0x1 mask: 0x3
|
| 111 |
|
|
Debug: 132 359 core.c:1208 jtag_validate_ircapture(): IR capture validation scan
|
| 112 |
|
|
Warn : 133 369 core.c:1244 jtag_validate_ircapture(): AUTO auto0.tap - use "... -irlen 4"
|
| 113 |
|
|
Debug: 134 369 core.c:1267 jtag_validate_ircapture(): auto0.tap: IR capture 0x01
|
| 114 |
|
|
Debug: 135 369 openocd.c:145 handle_init_command(): Examining targets...
|
| 115 |
|
|
...
|
| 116 |
|
|
\end{verbatim}
|
| 117 |
|
|
|
| 118 |
|
|
Una vez obtenida éstas lineas se puede rescatar los datos más importantes que son,
|
| 119 |
|
|
\begin{itemize}
|
| 120 |
|
|
\item \emph{id}
|
| 121 |
|
|
\item \emph{irlen}
|
| 122 |
|
|
\item \emph{capture}
|
| 123 |
|
|
\item \emph{mask}
|
| 124 |
|
|
\end{itemize}
|
| 125 |
|
|
|
| 126 |
|
|
\subsubsection{Modo \textsl{Halt}}
|
| 127 |
|
|
El modo \textsl{halt}, permite congelar al dispositivo tanto para agregar \textsl{breakpoints} como también programar el dispositivo. Un problema común es que dicho modo no puede ser aplicado, para solucionar ésto es necesario realizar un \textsl{reset}, con el comando \texttt{reset halt}. Luego de esto se puede pasar al modo \textsl{halt} sin problemas.
|
| 128 |
|
|
|
| 129 |
|
|
\subsubsection{Programación \ac{CPLD}}
|
| 130 |
|
|
Para los \ac{CPLD}, primero se debe tener el archivo \ac{SVF}, que es generado por la herramienta con la que se diseña y sintetiza el código VHDL o Verilog. En éste caso se utiliza el \textsl{software} ISE Xilinx. Una vez que se tiene el archivo \ac{SVF}, desde \ac{OpenOCD}, se corre el siguiente comando;
|
| 131 |
|
|
\begin{verbatim}
|
| 132 |
|
|
svf {file.svf} quiet
|
| 133 |
|
|
\end{verbatim}
|
| 134 |
|
|
Lo que generaría una salida como la que sigue,
|
| 135 |
|
|
\begin{verbatim}
|
| 136 |
|
|
svf processing file: "file.svf"
|
| 137 |
|
|
500 kHz
|
| 138 |
|
|
|
| 139 |
|
|
Time used: 0m7s478ms
|
| 140 |
|
|
svf file programmed successfully for 8468 commands
|
| 141 |
|
|
\end{verbatim}
|
| 142 |
|
|
|
| 143 |
|
|
En el caso de que se tenga problemas en la transferencia del archivo, se podría probar bajando la frecuencia de la comunicación \ac{JTAG}. Recordar que esto quizá se deba cambiar también desde el entorno ISE Xilinx.
|
| 144 |
|
|
|
| 145 |
|
|
Algo interesante se puede observar en el archivo \texttt{fiel.svf}, pues en una de sus lineas tiene el IDCODE del dispositivo al que se va a transferir, que debería coincidir con el que se le pasa cuando se agrega el \ac{TAP} al código de \ac{OpenOCD}.
|
| 146 |
|
|
\begin{verbatim}
|
| 147 |
|
|
...
|
| 148 |
|
|
//Loading device with 'idcode' instruction.
|
| 149 |
|
|
SIR 8 TDI (fe) SMASK (ff) ;
|
| 150 |
|
|
SDR 32 TDI (00000000) SMASK (ffffffff) TDO (f9604093) MASK (0fffffff) ;
|
| 151 |
|
|
//Check for Read/Write Protect.
|
| 152 |
|
|
SIR 8 TDI (ff) TDO (01) MASK (e3) ;
|
| 153 |
|
|
//Boundary Scan Chain Contents
|
| 154 |
|
|
//Position 1: xc9572xl
|
| 155 |
|
|
...
|
| 156 |
|
|
\end{verbatim}
|
| 157 |
|
|
|
| 158 |
|
|
En la conexión de los puertos \ac{JTAG}, hemos encontrado un problema y es el nivel de tensión que maneja éstos pines con respecto a los de la placa OOCD-Links.
|
| 159 |
|
|
La placa OOCD-Links cuenta con un dispositivo central, FT2232D. Éste dispositivo posee dos alimentaciones, por una parte la alimentación de núcleo del circuito integrado y por otro lado la alimentación de los \textsl{interfaces} de salida. La primera alimentación es tomada desde el puerto USB al que se encuentra conectado, mientas que la alimentación de sus puertos de conexión lo toma del conector \emph{P1}. Éste último debería tener el mismo nivel de tensión que la placa con la que se conecte. Es decir, si se hace una conexión entre la placa OOCD-Links y una placa con un CPLD XC9572XL, se debería asegurar que ambas tengan la misma tensión en sus puertos \ac{JTAG}, en éste caso 3.3V.
|
| 160 |
|
|
Una solución transitoria a éste problema sería proporcionar la alimentación de los \textsl{interfaces} de la placa OCD-Links desde el puerto de alimentación de la placa CPLD. La placa OT-CPLD posee los puertos de alimentación, regulado a 3.3V, como salida en sus pines de conexión \emph{P1} y \emph{P2}. El principal inconveniente que se podría encontrar es el consumo de corriente. Pues el regulador de la placa OT-CPLD se tendría que proporcionar energía a la placa OOCD-Links, pero como es en el proceso de programación y como proceso de testeo, no debería haber inconvenientes.
|
| 161 |
|
|
|
| 162 |
|
|
Otra posible solución sería implementar los puertos de \ac{JTAG} como lo tiene la placa ARM de ĺa Cátedra Técnicas Digitales II. Al parecer presenta solo unos resistores pullup a la salida de los pines que van al conector \ac{JTAG}.
|
| 163 |
|
|
|
| 164 |
|
|
Se investiga la posibilidad de que el problema de la placa OT-CPLD sea la falta de resistores pull-up en los puertos \ac{JTAG}; TDI, TDO, TMS, TCK.
|
| 165 |
|
|
|
| 166 |
|
|
|
| 167 |
|
|
\section{Documentación}
|
| 168 |
|
|
La documentación resulta fundamental en ésta etapa del desarrollo. Si bien se quiere lograr el correcto funcionamiento de las placas, la documentación sirve para realizar correciones a las versiones futuras de cada placa. Otro objetivo es documentar el funcionamiento de cada dispositivo que sirvan al reporte final como así también a los usuarios de la \emph{Plataforma de Hardware Reconfigurable}.
|
| 169 |
|
|
|
| 170 |
|
|
|
| 171 |
|
|
\newpage{}
|
| 172 |
|
|
|
| 173 |
|
|
\appendix{}
|
| 174 |
|
|
\section{Acrónimos}
|
| 175 |
|
|
\begin{acronym}
|
| 176 |
|
|
\acro{PHR}[PHR]{Plataforma de Hardware Reconfigurable}
|
| 177 |
|
|
\acro{OpenOCD}[OpenOCD]{Open On-Chip Debugger}
|
| 178 |
|
|
\acro{JTAG}[JTAG]{Joint Test Action Group}
|
| 179 |
|
|
\acro{TAP}[TAP]{Test Access Port}
|
| 180 |
|
|
\acro{SVF}[SVF]{Serial Vector Format}
|
| 181 |
|
|
\acro{CPLD}[CPLD]{Complex Programmable Logical Device}
|
| 182 |
|
|
\acro{SO}[SO]{sistema operativo}
|
| 183 |
|
|
\acro{UTN-FRC}{Universidad Tecnológica Nacional -- Facultad Regional Córdoba}
|
| 184 |
|
|
\end{acronym}
|
| 185 |
|
|
|
| 186 |
|
|
\section{Repositorio de proyecto}
|
| 187 |
|
|
|
| 188 |
|
|
El proyecto se encuentra alojado en los servidores de \emph{OpenCores}. Por lo que se puede acceder a los repositorios mediante el siguiente link, \texttt{http://opencores.org/project,phr}
|
| 189 |
|
|
De todas formas se pueden comunicar por correo, \texttt{guanucoluis@gmail.com}.
|
| 190 |
|
|
|
| 191 |
|
|
\end{document}
|
