[Triestado] [Verilog] tres formas de hacer un Buffer triestado

[Jose Pico]

Hola he realizado un buffer triestado realizado de tres formas distintas, una usando el propio SB_IO de lattice, otra creando un multiplexor mediante un condicional de veriolog y una tercera usando la propia primitiva de verilog llamada "bufif1".

Los he probado y funcionan, si alguien quiere probarlos aquí los dejo.

Hay un cuarto triestado realizado usando un Case, pero este no me funciona, si alguien me puede decir porqué se lo agradecería.

Saludos 

[Juan Perona]

¿Y al final cual es la manera más eficiente de usarlo?

saludos!

[Jose Pico]

 Hola Juan:

 

  Has hecho la pregunta que todos querríamos saber cuando tenemos que elegir algo. JEJEJEJEJEJe

  El problema, es que como muchas veces pasa en esta vida no tengo la respuesta.

  A nivel de Área, creo que los tres ejemplos que hice con ellos construían usando el mismo número de  bloques.

  Mi intención no era crear incertidumbres, solo quería mostrar formas distintas de hacer lo mismo ( un tema de aprendizaje puro y duro).

  Es cierto que el módulo creado directamente usando una instancia del SB_IO de lattice, se ataca directamente el hardware y se crea justo lo que has configurado, quizás este sea el más eficiente, pero como los sintetizadores son muy listos nunca se sabe.

  anímate a probarlos y si averiguas algo bueno o malo no lo cuentas.

  Añado alguno de los ejemplos usando estos triestado.

 Saludos

[jordon...@gmail.com]

Buenos días Jose,  soy Juan Ordoñez;

Para fines didácticos estoy desarrollando un protocolo i2c para obtener datos de una IMU (un balancín con la IceZum Alhambra), obviamente y como se ha comentado en otros temas, llega un momento en el cual el pin de SDA tiene que comportarse como entrada y no como salida. He pensado (y por eso lo de ponerlo por aquí) que eso puede ser un buffer triestado pero debido a mi novatez no se implementarlo muy bien ni como funciona. Mi idea es una señal sda_enable(out) conectada a oe y encargada de decidir cuando la salida dout viene dada por din( la señal sda que yo gobierno y en la que introduzco en su debido momento por ejemplo la direccion del esclavo). Cuando oe =1, din=dout. Cuando oe = 0 entiendo, y de aqui vienen mis dudas, que dout queda totalmente desconectado del circuito, pudiéndolo entonces usar como entrada.

Entonces, para que sirve pin?? Nunca mejor dicho, tengo algún cabo suelto por ahi.

Saludos y muchas gracias¡¡

[Jose Pico]

 Hola compañero:

  Yo no he realizado ningún I2c pero sé que Obijuan realizó un I2c para el ADC de la Alhambra y que se ha usado en alguna aplicación como el ping-pong de Juanma pero no lo he estudiado.

  Algunas otras personas como Matthew realizaron un i2c usando dos pines unidos donde  uno actúa como entrada y otro como salida  pero no sé más.

 El dibujo del triestado puede resultar un poco engañoso.

  pin =  será tu pin físico de salida/entrada de tu FPGA  ( por Ejemplo  el PMOD1 de la IceStick )

  si oe= 1     por "din"  se puede introducir  un dato ( de entrada al módulo triestado )  que saldrá por  "pin", osea:

  

Con oe=1  habilitamos para sacar datos introducidos por "din" por "pin"

Con oe=0 usaremos "pin" para meter datos hacia "dout" .

 Resumiendo :      a "pin" será el pin físico de la FPGA  que será tu pin input/ouput 

                             "din" / "dout"  son las señales por las que enviarás/recibirás datos  de "pin"

  Te adjunto una imagen aclaratoria.

  Saludos 

[Juan Ordoñez]

Era justo lo que necesitaba Jose....muchas gracias de nuevo, en cuanto tenga algo estable lo subiré para que todos podamos disfrutarlo, estoy haciendo un balance robot con la Icezum Alhambra, ya os iré informando. Así da gusto trabajar!!!! 

Saludos!!

--
Has recibido este mensaje porque estás suscrito a un tema del grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/fpga-wars-explorando-el-lado-libre/UwwZfS_LdVM/unsubscribe.
Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a fpga-wars-explorando-el-lado-libre+unsubscribe@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a fpga-wars-explorando-el-lado-li...@googlegroups.com.
Visita este grupo en https://groups.google.com/group/fpga-wars-explorando-el-lado-libre.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/d1adc8ce-d0ce-4d2c-8c75-b266b64faa4b%40googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Jose Pico]

Ànimo!

Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a fpga-wars-explora...@googlegroups.com.

Visita este grupo en https://groups.google.com/group/fpga-wars-explorando-el-lado-libre.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/d1adc8ce-d0ce-4d2c-8c75-b266b64faa4b%40googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

--
Has recibido este mensaje porque estás suscrito a un tema del grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/fpga-wars-explorando-el-lado-libre/UwwZfS_LdVM/unsubscribe.

Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a fpga-wars-explora...@googlegroups.com.

Visita este grupo en https://groups.google.com/group/fpga-wars-explorando-el-lado-libre.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAGrirzBLjAvmZiRuiCXJP%3Dc7Zcb6it2tTfn%2B-_zGCOhG44uwPw%40mail.gmail.com.

[Juanma Rico]

Buenas Juan, por alusiones... :)))

Mi adaptación de la comunicación por I2C del ADC integrado en la icezum Alhambra mediante la máquina de estados que hizo Obijuan y que yo usé en el "screen-pong" es una auténtica chapuza... así de rotundo lo digo... porque lo conozco bien... :)))

Se supone que la definición del buffer triestado (SB_IO) debería funcionar pero no sé porqué, no lo hace. No sé si es la definición, si la síntesis con las herramientas del proyecto icestrom... la verdad, por más que busqué en su día no encontré el motivo de porqué no funciona como debiera, la cuestión es que lo puedes encontrar en el código que intenté encapsular para el "screen-pong"; pero si compruebas un poco más e investigas verás que está en cierta forma "deshabilitada" la escritura... pero lo extraño es que aún así funciona, no sé porqué, pero la inicialización en la que debes escribir en el bus I2C se produce y la subsiguiente lectura también, aún no estando la definición del pin triestado correctamente definido.

Imagino que al tener un maestro y un único esclavo en el bus es por lo que funciona... ya que no se producen colisiones en el bus entre distintos esclavos... no sé, la verdad, es algo que me quedó en el aire y como digo, cada cierto tiempo aparece el tema del triestado en el grupo pero yo, personalmente, no llego a ninguna conclusión que me de ánimos para mejorar el bloque I2C.

También Jesús lo intentó para comunicar con un OLED, pero tampoco quedó claro qué pasaba.

Así que ánimos y si llegas a alguna conclusión... que sepas que hay muchos proyectos pendientes de ese tema... así que tendrás un aliciente extra porque serás un héroe de FPGAwars si lo consigues.

¡Que la fuerza te acompañe!

Saludos
Juan Manuel Rico

[Democrito]

Hola,

Estoy "intentando" abordar el I2C (de una forma algo peculiar), pero con el tema triestado me he quedado atascado. Lo que quiero hacer es lo siguiente:

La entrada del buffer siempre es 0.

Se trata de que la salida quede flotante si OE = 0;

y si OE = 1 entonces en la salida ha de salir un 0.

Como se puede ver no es bi-direccional, es sólo un simple triestado.

La imagen de arriba lo explica todo, el problema es que no sé qué escoger de estos dos buffers (imagen de abajo) que viene por defecto en el último Icestudio(4.0) ni tampoco sé cómo se conecta. He intentado aplicar mi pobre lógica pero no consigo llegar a ninguna conclusión.

Sería el de arriba o el de abajo?

Después me vine a buscar información aquí. He revisado todos los post de este hilo y he visto algunos ejemplos de José Picó. El ideal para mí sería "TriState bufif1.ice".

He mirado por Internet la palabra clave "bufif1" pero al menos hace 5 años había algún problemilla y desconozco si está resuelto. Lo he probado y parece una puerta And, en el sentido de que no veo que quede flotante. Cuando un Led está flotante por regla general se ilumina débilmente. 

Saludos.

[Juan Gonzalez Gomez]

Hola,

Toda la documentación sobre pines E/S con triestado para las ice40 la puedes encontrar aquí :

https://github.com/Obijuan/Cuadernos-tecnicos-FPGAs-libres/wiki/CT.3:-Pines-de-Entrada-Salida

También muchos ejemplos

Los dos bloques I/O son equivalentes. Como en tu caso solo quieres salida, tiene más sentido que uses el que tiene la pata pin por la derecha (pero el otro sería totalmente equivalente) 

Por dout pones un 0. Y por oe el estado que quieres (1 sacas un 0, 0 se queda en alta impedancia. Si quieres lo contrario pones una not conectada a oe). Como no quieres leer como entrada, dejas din al aire

Saludos, Obijuan

--
Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/ec7d76c6-ee35-4704-aca7-f6801d2ff718%40googlegroups.com.

[Democrito]

Muchísimas gracias!

[Juan Gonzalez Gomez]

Exacto! Eso es!  :-)

Saludos, Obijuan

El lun., 26 ago. 2019 a las 16:26, Democrito (<spo...@gmail.com>) escribió:

Muchísimas gracias!

--
Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/e6ccf57d-c93e-4676-9c67-1e41c1c4de21%40googlegroups.com.