ID USB

From Qi-Hardware
Jump to: navigation, search
ID USB

Fabian Leonardo Salas 261253       Gilber Andrés Rincón 261578        Jorge Alberto Diaz 261542

Contents

[edit]
IDENTIFICADOR DE DISPOSITIVOS USB

[edit] INTRODUCCION:

El presente proyecto se da en el marco de proyecto final para Electrónica Digital II en la Universidad Nacional de Colombia. Como requisito indispensable se debe trabajar con la tarjeta SIE. El objetivo de este proyecto es crear un instrumento que pueda identificar el IDvendor y El IDproduct de un dispositivo USB.

[edit] ESPECIFICACIONES DEL SISTEMA

[edit] FUNCIONAMIENTO

El dispositivo funcionará de la siguiente manera: Inicialmente estará en un estado de espera, este se indicará en el display, al momento de conectar un dispositivo USB el instrumento procederá a obtener los identificadores de este, ID_vendor e ID product y mostrarlos en el display además de indicar la velocidad del dispositivo.

Diagrama de funcionamiento basico

[edit] DIAGRAMA DE BLOQUES

Diagrama de bloques
Datapad


[edit] TAREAS SOFTWARE

  • La principal tarea software es manejar las señales de control, recibir datos y enviar datos del core Host USB, además de encargarse de la visualización de los resultados obtenidos en el display 2x16.

[edit] MAPA GENERAL DE MEMORIA

Memory map.png

[edit] MAPA DE MEMORIA DEL PERIFERICOS USB Y LCD

Se observa que el mapa de memoria del periferico USB es extenso, esto se debe a la cantidad de registros que se encuentran en el core USB de opencores ( http://opencores.org/project,usbhostslave ) que se uso en este proyecto, dentro de la documentación de este core se encuentra un documento donde se explica la funcionalidad de cada uno de estos registros, a continuación se muestra el listado de registros que aparece en el documento, cabe aclarar que cada uno de estos registros esta formado por 16 subregistros de 32 bits.

Listaregistros2.png
Listaregistros3.png
Listaregistros12.png

Los siguientes son los mapas de memoria de los registros del USB Host con sus respectivos subregistros. En la sección USB de esta página se encuentra una explicación detallada de cada subregistro del mismo.

Mapamem1.png
Mapamem2.png
Mapamem3.png
Mapamem4.png
Mapamem5.png
Mapamem6.png
Mapamem7.png

En la ultima parte de la siguiente imagen se muestra el mapa de memoria del LCD.

Mapamem81.png

[edit] TAREAS HARDWARE

  • Controlar la visualizacion del display
  • En un dispositivo Host USB se reconocen dos bloques de hardware importantes, eston son la "SIE" y el "Host controler", el primero se encarga de la codificación y decodificación de la información que se transmite entre un device y el Host USB, esto lo hace usando el protocolo NRZY que se explica mas adelante, además se encarga de la detección de errores en la transmisión, por otro lado, el Host controler que esta conectado directamente a la SIE se encarga de analizar la información que recibe de esta para determinar que tipo de peticiones o respuestas se obtienen del device, y también es el encargado de decir a la SIE que tipos de datos son los que se están enviando a través de ella

[edit] ESQUEMATICO Y PCB DE LA TARJETA HIJA

La siguiente fotografia muestra el dispositivo funcionando, se observa que se le a conectado una memoria USB y el en el LCD nos muestra su ID Vendor y el ID product.

Pcbidusb4.JPG

[edit] HARDWARE USADO

Los componentes que tendra la tarjeta hija implementada para el proyecto son los siguientes:

  • Display LCD 2x16.
  • Conector USB hembra tipo A.
  • 2 Pulsadores.
  • Resistencias SMD.
  • Condensadores SMD.
  • Cristal de 12 MHz
  • Circuito integrado CDCS 502 de texas instruments el cual se encargara de multiplicar por 4 la frecuencia del clock con el fin de obtener 48MHz necesarios para el correcto funcionamiento del sistema

[edit] RTL DEL SISTEMA

La siguiente imagen muestra el RTL del sistema, las señales se pueden dividir en cuatro subgrupos: display (bus_control, bus_datos), clock's (clk y usbClk), pulsadores (key1 y key2) y usb(USBWireVM,USBWireVP,USBFullSpeed, USBWireOE_n ).

USBhostslave rtl2.png

[edit] LCD

Para efectos de visualización, en este proyecto usaremos un LCD 16x2, cuya referencia es:LCM1602A-NSW-BBW.
Para utilizar este LCD tenemos en cuenta los comandos que recibe, estos se pueden visualizar en la siguiente tabla de instrucciones extraida del datasheet del LCD.

Tabla comandos lcd1.png

Se debe tener en cuenta que cada vez que se le envía un comando al LCD se debe habilitar una señal enable en nivel alto para que el LCD se disponga a recibir la instrucción.
Para efectos de nuestro proyecto se realiza un inicialización básica del LCD y se deja listo para que este reciba lo que debe imprimir, esto se realiza mediante el bus de datos de 8 bits.
Para inicializar el LCD se le envían las primeras 6 instrucciones de la tabla.
En la siguiente imagen se podrá apreciar la simulación de esas 6 primeras instrucciones, observar las señales llamadas "bus_datos" y "bus_control"

Inicio lcd.png

Ahora veremos unas imágenes RTL del periférico LCD integrado con el Wishbone.

Rtl lcd1.png

[edit] USB

El modulo USB en que se basa el proyecto se encuentra publicado en OpenCores ( http://opencores.org/project,usbhostslave ), este modulo esta compuesto por tres bloques principales para nuestro interés, estos son: Bus interface, SIE (Serial Interface Engine) y HostController, a continuación explicaremos la función de cada uno de estos módulos apoyados con simulaciones usando para este fin IVerilog y GTKWave


[edit] MÁQUINA DE ESTADOS

MAQUINA ESTADOS.png

[edit] DIAGRAMA DE BLOQUES

Cuando se conecta un dispositivo USB se genera una default pipe, mediante la cual se realiza la asociación lógica entre el Host y el dispositivo USB para desarrollar el proceso de enumeración, aquí se ubica inicialmente en el address 0x0 el dispositivo conectado para posteriormente direccionarlo a un address definitivo el cual usara el sistema para la transferencia de datos, de esta forma queda libre el address 0x0 para recibir un nuevo dispositivo. El componente que se encarga de controlar este default pipe es el USB Driver(USBD). Otros elementos necesarios para la comunicación entre el Host y el dispositivo USB son el Host Controller(HC) y la SIE, quienes se encargaran de la transferencia de las cadenas de bytes y bits. El HC debe llevar a cabo las siguientes tareas:

  • Manejo de estados del Host
  • Generación de frames y microframes, que son los paquetes en los cuales se transporta la información. Estos deben tener al inicio un Start Of Frame(SOF) y al final un End Of Frame(EOF), que deben respetar tiempos específicos entre cada uno según la velocidad del dispositivo USB. La generación de estos se visualiza en el siguiente gráfico:

Frame generation.png

La SIE debe llevar a cabo las siguientes tareas:

  • Codificacion y decodificacion de los datos de salida y entrada respectivamente, esto lo hace basándose en el protocolo NRZY.
  • Detección de errores en la transmisión de datos.
  • Es el puente entre el USB System y el dispositivo USB

Esta lógica se resume en el siguiente diagrama de bloques, donde el "Host controller" y la "SIE" componen el "USB bus interface":


Diagrama de bloque generaldel periferico USB

A continuación se muestra un diagrama mas detallado del camino que recorren los datos en el "USB bus interface"


Camino de datos en el "USB bus interace"

En el siguiente diagrama se aprecian el RTL del USB bus interface, se pueden observar las señales que pertenecen al protocolo del Wishbone, estas son: addres_i(7:0), data_i(7:0), clk_i, rst_i, strobe_i, data_o(7:0), we_i, ack_o, por otro lado esta la señal del clock del USB (usbClk) la cual debe tener una frecuencia aproximada de 48 MHz, las señales USBWireVP y USBWireVM son las que en D+ y D-, la señal USBWireOE_n nos indica si hay lectura o esritura en el dispositivo y la señal USBFullSpeed nos indica si la conexion se realiza en fullspeed (12Mbs) o lowspeed (1.5 Mbs).


RTL del periferico USB

[edit] MAPA DE MEMORIA(REGISTROS)

En esta sección se explicará detalladamente cada uno de los resgistros, con sus respectivos subregistros, que componen el mapa de memoria del código USB Host usado en este proyecto.

FUNCIONES Y ESPECIFICACIONES DE REGISTROS DEL MAPA DE MEMORIA USB

**HCREG_BASE (0x00 - 0x0f)**
Este grupo de registros contienen las configuraciones necesarias para cada tipo de transacción y las respuestas del device a las peticiones del host.

  • TX_CONTROL_REG (0X00)

Este registro utiliza los cuatro primeros bits, [0:3].
[0] TRANS_REQ_BIT : Este registro se escribe para habilitar transacción, y se borra automaticamente al completar cada transacción.
[1]SOF_SYNC_BIT : Señal para sincronizar transacción con cada Start of Frame(SOF)
[2]PREAMBLE_ENABLE_BIT : Utilizada en [1] para habilitar un preamble que es un paquete vacio antes de cada transacción y habilita automaticamente velocidad alta.
[3]ISO_ENABLE_BIT: utilizado en [1] para habilitar transacción asincrona la cual no se utiliza para las transacción de entrada y salida de enumeración.

  • TX_TRANS_TYPE_REG (0x01)

Es un vector de dos bits [0:1], el cual define el tipo de transacción que vamos a utilizar, se debe escribir de la siguiente forma:
[00] SETUP_TRANS
[01]IN_TRANS
[10]OUTDATA0_TRANS
[11]OUTDATA1_TRANS
Para efectos del proceso de enumeración, se utilizan los tipos SETUP_TRANS e IN_TRANS en la petición de los descriptores y la entrada de los mismos, respectivamente.

  • TX_LINE_CONTROL_REG (0x02)

Este registro utiliza los 5 primeros bits, [0:4]
[1:0] TX_LINE_STATE: Cuando se tiene el control directo sobre los cables físicos del USB, TX_LINE_STATE[0] corresponde a D- y TX_LINE_STATE[1] corresponde a D+.
[2]DIRECT_CONTROL_BIT : Se utiliza en [0] para tener funcionamiento normal del programa. Se utiliza en [1] para tener el control directo sobre los cables fícicos del USB.
[3]FULL_SPEED_LINE_POLARITY_BIT : Se utiliza en [0] para polaridad de baja velocidad; esto es, J=0 y K=1. Se utiliza en [1] para polaridad de alta velocidad; esto es, J=1 y K=0.
[4]FULL_SPEED_LINE_RATE_BIT : Se utiliza en [0] para una tasa de transferencia de 1.5Mbps, correspondiente de baja velocidad. Se utiliza en [1] para una tasa de transferencia de 12Mbps, correcpondiente a alta velocidad

  • HOST_TX_SOF_ENABLE_REG(0x03)

Este registro solo utiliza el primer bit [0].
[0]SOF_EN_BIT: Si FULL_SPEED_LINE_POLARITY_BIT se encuentra activado, se utiliza en [1] para habilitar transmision automática de Star Of Frames cada 1ms. Si FULL_SPEED_LINE_POLARITY_BIT se encuentra desactivado, se utiliza en [1] para habilitar transmisión automática de End Of Packets cada 1ms. Se utiliza en [0] para desabilitar la transmision automática de SOF/EOP, permitiendo a los dispositivos USB entrar en estado suspendido.

  • TX_ADDR_REG(0X04)

Este registro utiliza 7 bits, [6:0].
[6:0]DEVICE_ADDRESS : Se rellena con la dirección del dispositivo al que se le va a transmitir. La dirección por defecto de un dispositivo es la cero 0x00.

  • TX_ENDP_REG(0x05)

Este registro utiliza 4 bits, [3:0].
[3:0]ENDP_ADDRESS: Se rellena con el end point del dispositivo al que se le va a transmitir. El end point por defecto de un dispositivo es el cero 0x0.

  • FRAME_NUM_MSB_REG(0x06)
  • FRAME_NUM_LSB_REG(0x07)
  • INTERRUPT_STATUS_REG (0x08)

Este registro utiliza 4 bits, [3:0].
[0]TRANS_DONE_BIT: Automáticamente se encuentra en [1] cuando una transacción es completada, debe limpiarse escribiéndole un [1].
[1]RESUME_INT_BIT :Automáticamente se encuentra en [1] cuando un estado resume es detectado, debe limpiarse escribiéndole un [1].
[2]CONNECTION_EVENT_BIT: Automáticamente se encuentra en [1] cuando se detecta una conexión o desconexion de dispositivo USB, debe limpiarse escribiéndole un [1].
[3]SOF_SENT_BIT :Automáticamente se encuentra en [1] cuando ocurre una transmisión de Star Of Frame, debe limpiarse escribiéndole un [1].

  • INTERRUPT_MASK_REG(0x09)

Este registro utiliza 4 bits, [3:0]. Estos bits corresponden a las posibles interupciones que puede tener el programa.
[0]TRANS_DONE_BIT: Se utiliza en [1] para habilitar interrupción cuando una transacción es completada.
[1]RESUME_INT_BIT : Se utiliza en [1] para habilitar interrupción cuando se detecta un estado resume.
[2]CONNECTION_EVENT_BIT: Se utiliza en [1] para habilitar interrupción cuando ocurre una conexión o desconexión de dispositivo USB.
[3]SOF_SENT_BIT : Se utiliza en [1] para habilitar interrupción cuando se transmite un Star Of Frame.

  • RX_STATUS_REG (0x0a)

Este registro utiliza 8 bits, [7:0]. Estos bits corresponden a avisos e indicaciones importantes sobre la transmision de datos y sobre el estado del dispositivo. Su lectura se hace indispensable en el proceso de enumeración.
[0]CRC_ERROR_BIT: Cuando se encuentra en [1], indica error de tipo Cyclic Redundancy Check en la última transmisión.
[1]BIT_STUFF_ERROR_BIT : Cuando se encuentra en [1], indica error de tipo bit stuff en la última transmisión.
[2]RX_OVERFLOW_BIT : Cuando se encuentra en [1], indica espacio insuficiente en los fifos de recepción, de modo que no se pueden aceptar los datos completos del paquete a recibir. Es sugerido limpiar los fifos de recepción.
[3]RX_TIME_OUT_BIT : Cuando se encuentra en [1] indica que no hay respuesta desde el dispositivo USB .
[4]NAK_RXED_BIT : Esta señal activa indica que el dispositivo se encuentra ocupado, por tanto la solicitud debe ser realizada en otro momento.
[5]STALL_RXED_BIT :La señal de STALL [1] indica que la solicitud fue recibida pero no es soportada por el dispositivo.
[6]ACK_RXED_BIT : Cuando se encuentra en [1], indica que el dispositivo USB recibió el último paquete correctamente.
[7]DATA_SEQUENCE_BIT : si la ultima transacción fue de tipo IN TRANS al terminar el envio de un paquete de datos por parte del dispositivo se indica el numero de la secuencia del ultimo paquete recibido. DATA0=0, DATA1=1

  • RX_PID_REG (0x0b)

Este registro utiliza 3 bits, [3:0].
[3:0]RECEIVE_PID : Según estos cuatro bits se identifica el último paquete recibido.

  • RX_ADDR_REG (0x0c)

Este registro utiliza 7 bits, [6:0].
[6:0]RECEIVE_ADDRESS: Indica la dirección desde donde fue enviado el último paquete recibido.

  • RX_ENDP_REG (0x0d)

Este registro utiliza 4 bits, [3:0].
[6:0]RECEIVE_ENDP: Indica el end point desde donde fue enviado el último paquete recibido.

  • RX_CONNECT_STATE_REG(0x0e)

Este registro utiliza 2 bits, [1:0].
[1:0]RX_LINE_STATE: Indica el estado de conexión de la siguiente manera:
[00]DISCONNECT , no hay disposivito.
[01]LOW_SPEED_CONNECT, conexión de dispositivo de baja velocidad.
[10]FULL_SPEED_CONNECT , conexión de dispositivo de alta velocidad.

  • HOST_SOF_TIMER_MSB_REG(0x0f)

Este registro es la representacion de byte mas significativo del SOF timer que es usado para la formación de Start of Frame por tanto existen 48000 ticks en 1 ms. [7:0]

**HOST_RX_FIFO_BASE (0x20 -0x24)**

Este grupo de registros contiene toda la información sobre los datos recibidos, y almacena cada uno de los paquetes de bytes.

  • FIFO_DATA_REG(0x20). Este registro tendrá un Byte[7:0] que es el resultado de la decodificación de los datos provenientes del device en transacciones de IN TRANS. Para acceder a los demás bytes recibidos por transacción que se encuantran almacenados en los FIFO's, se debe tener en cuenta que cada vez que se lee este registro, automáticamente se incrementa la dirección del mismo; de modo que en la siguiente lectura se leerá el siguiente byte decodificado.
  • FIFO_STATUS_RE(0x21).
  • FIFO_DATA_COUNT_MSB(0x22)

Número de elementos recibidos en el FIFO, más significativo

  • FIFO_DATA_COUNT_LSB(0x23)

Número de elementos recibidos en el FIFO, menos significativo.

  • FIFO_CONTROL_REG(0x24)

Este registro en la posición [0] controla el reset o borrado del RX FIFO, por tanto para borrar el FIFO, se habilitará esta posición [0]=1.

HOST_TX_FIFO_BASE (0x30-0x34)

Este grupo de registros contienen toda la informacion de los datos que se desean transmitir.

  • FIFO_DATA_REG

(0x30) En este registro se deben escribir los bytes a transmitir, sabiendo que se pueden escribir en este campo de a 8bits. [7:0]

  • FIFO_CONTROL_REG

(0x34) El bit menos signicativo de este registro [0], controlara la señal force_empty, la cual se habilitará con un 1 para borrar el TX FIFO.

**HOST_SLAVE_CONTROL_BASE (0xe0 - 0xe1)** Registro de control principal del Código.

  • HOST_SLAVE_CONTROL_REG

(0xe0) Este registro utiliza los dos primeros bits del vector. [0:1]

[0] HOST_MODE . Se debe escribir este bit en 1 para habilitar funcion de HOST_USB. [1] RESET_CORE. Escribir esta señal en 1 para realizar un borrado de todos los registros y variables del sistema, este reset debe tener una duracion de 10 ciclos de reloj.

  • HOST_SLAVE_VERSION_REG(0xe1)

[7:4] VERSION_NUM_MAJOR:

Versión del código. bit mas significativo.

[3:0] VERSION_NUM_MINOR

:Version del código. bit menos significativo.

[edit] SIMULACIONES

Las simulaciones estan divididas en tre grupos: Bus Interface, SIE y HostController.

[edit] SIE (Serial Interface Engine)

[edit] dpMem_dc

La siguiente es la simulación de un Synchronous dual port memory with dual clocks. En este bloque se deben asignar direccion de entrada(addrIn), direccion de salida(addrOut), y dato de entrada(dataIn); posteriormente se habilita la escritura(writeEn), de modo que el dato de entrada se escribe en la salida. Para este código se utilizan buffers. El código y la simulación se ven en las siguientes imágenes.


Dp Mem codigo.png


DpMem dc.png

[edit] Cyclic Redundancy Check CRC

Los CRC son mecánismos mediante los cuales se verifica que la transmisión de datos se realice correctamente. Tenemos dos tipos: CRC para Token Packets y CRC para Data Packets. El proceso de verificación se realiza mediante una operación XOR con el byte en cuestión, obteniendo un resultado que se envía a processRXByte para que este evalue el error

[edit] readUSBWireData

Este paquete tiene como tarea leer dos bits de entrada, guardarlos en 4 FIFO's como van llegando y devolver 2 bits cuando la SIE este lista para recibirlos. Utiliza la metodología de los FIFO's(first out first in), es decir el primero en llegar es el primero en salir. Para esto utiliza una máquina de estados:el primer estado es esperar que se llenen los buffers, la variable bandera para saber que se llenan los buffers es bufferCnt; despues espera a que la SIE este lista para recibir los bits, esto se sabe cuando SIERxRdyIn este en nivel alto, cuando la SIE avisa que esta lista se le envía la información contenida en los buffers, finalmente vuelve a esperar que se llenen los buffers. El código de esta máquina de estados y la simulacion se pueden ver en los siguientes gráficos:


Readusbwire codigo.png


Readusbwire sim.png

[edit] processRxBit

Este paquete tiene como tarea procesar 2 bits de entrada, que vienen desde readUSBWireData, y arrojar 1 byte de salida, que se enviará a processRxByte. Para llevar a cabo este proceso se basa en la siguiente máquina de estados:


Processbit fsm.png

Tenemos un estado Start que inicia después de un reset general en donde se inicializan todas las variables. Inmediatamente se pasa al estado WAIT_BITS, donde se reciben los dos bits desde readUSBWireData para ser procesados. Inicialmente se pasa a un estado IDLE donde se alista el programa para empezar a rellehttp://en.qi-hardware.com/wiki/2010-II/es/Digital2_2010_PaInTESnar un nuevo byte y se devuelve a WAIT_BITS. Posteriormente pasa al estado DATA_RX, donde se evalúan posibles errores y se rellena el byte. Si hay errores estos se procesan en los estados RES_RX y RES_END. Finalmente, cuando se ha llenado todo un byte, este se envía a processRxByte y el programa se vuelve a alistar para procesar uno nuevo.
Para destacar en este procesamiento tenemos el codigo que decodifica los bits de entrada y detecta posibles errores:


Processbit codigo.png

Notamos como si los bits de entrada son iguales a los anteriores el byte se rellena con un "1", si son diferentes, el byte se rellena con un "0". Así hasta llenarlo completamente. También notamos que si, consecutivamente se reciben 6 parejas de bits iguales, 'bitStuffError' tomará el valor de "1" indicándonos un posible error. La simulación de este paquete se presenta acontinuación:


Processbit sim.png

[edit] HostController

[edit] speedctrlmux

Este programa es basicamente un multiplexor que recibe como entrada las parejas de señales senales directCtrlRate, directCtrlPol y sendPacketRate, sendPacketPol, la señal de control se llama sendPacketSel y las salidas son fullSpeedRate y fullSpeedPol. El código y la simulación se ven en las siguientes imágenes.


Sim speedctrlmux cod.png


Sim speedctrlmux.png

[edit] Bus Interface

[edit] wishBoneBI

La tarea de este código es seleccionar, de los datos que le entran, el dato de salida que se le envía al procesador, según la dirección que se le asigne. Además, avisa a cada uno de los paquetes cuando su dato sea seleccionado.


Wishbonebi sim.png

[edit] PROTOCOLO NRZI

El protocolo de comunicación serial NRZI (Non return to zero invert) es el protocolo usado la USB. En este protocolo un uno "1" se presenta manteniendo constante la señal, un cero "0" se representa cambiando el nivel de la señal. Existe un bit de relleno (stuffing bit) para comprobar que se esta manteniendo una comunicación adecuada y depurar errores, este stuffing bit consiste en generar una cambio en la señal cuando esta se mantenga en uno "1" durante seis periodos seguidos.En la siguientes figuras se observan la codificación de datos en NRZI y un ejemplo de bit stuffing.

NRZI data encoding.png


Imagen extraida del documento universal Serial Bus Specification


Bit stuffing.png


Imagen extraida del documento universal Serial Bus Specification
En la Siguiente gráfica se ve la simulación del código desarrollado para el protocolo NRZI. Se uso Xilinx para realizar el código y ISim para la simulación.


NRZI.png

[edit] PROCESO DE ENUMERACION


Diagrama del proceso de enumeración

El proceso de enumeración describe cada uno de los pasos que deben llevar a cabo desde la conexión del dispositivo USB, hasta su identificación. Mediante este proceso se podrá obtener el ID-PRODUCT y el ID-VENDOR, objetivos de este proyecto. El descriptor del dispositivo es un paquete de datos el cual trae consigo información básica del dispositivo tal como la versión de USB soportada, tamaño máximo del paquete, fabricante y referencia del dispositivo como también el numero de configuraciones que puede tener el dispositivo.

Este paquete de datos se encuentra divido en campos que pueden ser de uno o mas bytes, en nuestro proyecto los campos más relevantes son: Campo No. 8, consta de 2 Bytes y contiene la identificación asignada por la corporación USB-IF al fabricante. Campo No. 9, consta de 2 Bytes los cuales contienen el valor de identificación del producto asignado por el fabricante.

[edit] TRANSFERENCIA DE GET_DESCRIPTOR_REQUEST


Descriptor.png
En esta simulación se muestran los principales registros de transmisión y recepción necesarios para realizar para la transacción Get_descriptor_request, esta solicitud se le envia al device con el fin de solicitar el descriptor necesario, en este caso se solicita el Device_descritor, como respuesta a la petición se espera una señal ACK de parte del device que indica que la solicitud del descriptor se hizo correctamente.

[edit] TRANSFERENCIA DE SOLICITUD DE INTRANS


Intrans.png


[edit] PHY


PHY-ISP1105

PHY (physical layer): Se encarga de hacer un puente entre la parte digital y la modulación de la señal o dicho en otras palabras sera quien conectara la SIE (Serial Interface Engine) con las conexiones D+ y D- del dispositivo USB.

[edit] OSCILADOR 48MHZ

Para obtener el reloj de 48Mhz necesario para el funcionamiento del modulo USB se uso el circuito integrado cdcs502 de Texas Instrument, este tiene la capacidad de multiplicar por 4 la frecuencia de un cristal que se le conecte a la entrada, soportando frecuencias máximas de 108MHz, en nuestro caso conectamos un cristal que oscila a 12MHz. La siguiente imagen muestra el diagrama interno del circuito cdcs502.
Diagramainternocdcs502.png

[edit] COMUNICACION POR BUS WISHBONE

La comunicación entre los periféricos y el procesador del sistema se realiza por medio de el bus de datos WishBone, lo primero que se debe realizar es asignar una dirección de memoria a cada periférico, después de esto se crean señales "volatile" para cada periférico que van a servir como registros que se escriben y leen desde el hardware y el software, para así tener el control de los periféricos desde software.


Wishbonecompatible.png


[edit] CRONOGRAMA DE ACTIVIDADES

Cronograma.png

[edit] ANÁLISIS DE COSTOS

En la siguiente tabla se encuentra el costo de diseño y producción de un prototipo.

Descripción Precio
Tarjeta Madre $ 198.000.
Elementos electronicos $ 18.000
Conectores $ 18.000
Fabricación circuito impreso $ 26.000
Diseño, Desarrollo e Implementación[1] $ 22.500.000
TOTAL $ 22.760.000

[1] El desarrollo del prototipo se produjo durante 5 meses, Durante todas las etapas de producción se conto 3 personas a cargo, generando un costo de 4.500.000 mensuales.

En la siguiente tabla se encuentra el costo de diseño y producción de 100 prototipos.

Descripción Precio
Tarjeta Madre $ 198.000.
Elementos electronicos $ 1000.000
Conectores $ 200.000
Fabricación circuito impreso $ 1000.000
Diseño, Desarrollo e Implementación[1] $ 22.500.000
TOTAL $ 24.898.000
Personal tools
Namespaces
Variants
Actions
Navigation
interactive
Toolbox
Print/export