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 sda
pin, 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 sda
un inout wire
, donde tanto el maestro como el esclavo manejan sda
usando una assign
declaración. No me queda claro cómo se pueden evitar las colisiones.
¿Qué sucede cuando lo mismo inout wire
es 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?
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.
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.
Super gato
ben voigt
sda <= 'H'
, y luego leer la señal usandoTO_X01(sda)
. O implemente una función de cableado y resolución.ben voigt
Super gato