Tratar con la comunicación bidireccional sobre 1 pin

Estoy escribiendo un controlador Verilog para un sensor de temperatura simple conectado a un FPGA. (La hoja de datos del sensor de temperatura está disponible aquí ). Las comunicaciones ocurren a través de un pin, el sdapin, donde el esclavo o maestro envía un byte, que luego es "reconocido" por el otro al final del byte (entre los ciclos de reloj 9 y 1).

Me imagino que la mejor manera de modelar esto es haciendo sdaun inout wire, donde tanto el maestro como el esclavo manejan sdausando una assigndeclaración. No me queda claro cómo se pueden evitar las colisiones.

¿Qué sucede cuando lo mismo inout wirees impulsado tanto por la fuente como por el maestro? ¿Cuál es la mejor manera de modelar los ciclos de confirmación de envío en un pin en Verilog?

Respuestas (2)

En I2C, cuando sea su turno de hablar, el maestro o el esclavo bajarán la línea de datos para un 0 lógico o se convertirán en una entrada de alta impedancia para un 1 lógico.

Cuando se vuelve de alta impedancia, esencialmente hace flotar la línea y permite que la resistencia pull-up levante la línea (lógica uno). Cuando se trata de una entrada de alta impedancia, puede detectar si la línea se está reduciendo; si trató de "escribir" un 1 lógico en este ciclo de reloj, entonces sabemos que ocurrió algún tipo de contención. Tenga en cuenta que este es el único caso que nos importa. Si se produce una contención pero no termina cambiando el flujo de bits resultante, en realidad nos dedicamos a nuestro negocio sin dar ningún error. Si ocurre una contienda, la parte que concede el bus es la que detectó un 0 lógico cuando intentaba apagar un 1 lógico.

No conozco Verilog, pero en VHDL, si estamos usando el tipo STD_LOGIC, podemos asignarlo como "inout" y en un proceso, asignarle el valor 'Z' (alta impedancia) y luego muestrear el pin para un alto o un bajo.

Si está escribiendo un maestro I2C, es su responsabilidad detectar si la línea I2C está en uso, específicamente, buscando condiciones de inicio y fin para señalar el inicio y el final del uso por parte de otro posible maestro.

NOTA: dice interfaz de dos cables en la hoja de datos, estoy bastante seguro de que esto significa I2C, por lo que lo anterior aún debería ser relevante.

La vigilancia de las condiciones del bus en uso solo es necesaria si un maestro va a coexistir con otros dispositivos maestros en el bus. En muchas aplicaciones ese no es el caso. Por otro lado, en algunos dispositivos esclavos I2C el pin SCK es bidireccional; los dispositivos que no están listos por un momento pueden mantener el SCK bajo hasta que estén listos. Para sincronizar cada bit cuando se usa cualquiera de estos dispositivos, el maestro debe liberar SCK, esperar hasta que todos los dispositivos en el bus también lo hayan liberado y luego reafirmarlo. Por cierto, mientras que "dos hilos" generalmente significa "compatible con I2C sin licencia", he visto algunos dispositivos de "dos hilos" que...
Además de esto, también necesita modelar la resistencia pullup, en VHDL sería sda <= 'H', y luego leer la señal usando TO_X01(sda). O implemente una función de cableado y resolución.
@supercat: Sí, eso se conoce comúnmente como "estiramiento del reloj", y crea contención incluso en un entorno de maestro único.
...toma mucho de I2C pero hace algunas cosas extrañas y desagradables que dudo que Philips elija, como un sensor de humedad que requiere que SCK se mantenga bajo durante una lectura y asincrónicamente afirma SDA cuando está listo. También he visto un chip de reloj en tiempo real de dos hilos que ingresa y emite datos LSB primero. Extraño.

Su sensor de temperatura no usa solo 1 cable para comunicarse, usa 2. El cable del reloj es tan importante como el cable de datos para comunicarse correctamente.

El bus I2C es bastante complejo, especialmente si se implementan todas sus campanas y silbatos. Afortunadamente, la mayoría de los chips no implementan todas las capacidades, y es por eso que la documentación a nivel de hoja de datos suele ser inconsistente. Para obtener información completa y definitiva, puede obtener la especificación completa de NXP.

No me queda claro cómo se pueden evitar las colisiones.

Si el sensor de temperatura es el único otro dispositivo en el bus, su FPGA siempre será el maestro en el protocolo de comunicación. Eso significa que usted controla la señal del reloj y siempre sabrá si el esclavo puede conducir el autobús en un momento dado.

Por lo general, escribiría una máquina de estado en su FPGA que administra los datos que entran y salen del dispositivo esclavo, y sabe cuándo enviar datos y cuándo recibirlos.

Tenga en cuenta que algunos dispositivos esclavos también ejercerán el control de la señal del reloj en ciertos momentos específicos de la transacción, como se describe en el estándar. Harán esto para "estirar" los períodos bajos del reloj y darse tiempo para completar una medición o cálculo antes de que el maestro comience a registrar los datos reales. Si su diseño maestro no tiene esto en cuenta, podría causar una "colisión".

¿Qué sucede cuando el mismo cable de entrada y salida es impulsado tanto por la fuente como por el maestro?

Dado que los dispositivos I2C solo pueden conducir bajo, generalmente no dañará ninguno de los chips si hay un conflicto. Cuando desea enviar un '1' lógico, no lleva la línea a un nivel alto, la coloca en un estado de Z alto y deja que una resistencia externa la suba. Si el esclavo conduce un '0' al mismo tiempo, no habrá ningún daño en ninguno de los dispositivos.

¿Cuál es la mejor manera de modelar los ciclos de confirmación de envío en un pin en Verilog?

Su Verilog no "modelará" un ciclo de confirmación de envío. Describirá la lógica que genera las señales correctas desde el dispositivo maestro.

Si desea simular el protocolo antes de comprometerse con el hardware, debe escribir un segundo módulo que tenga otra máquina de estado que responda a las señales del maestro y produzca las señales correctas para el dispositivo esclavo.