Tengo un MCU basado en Cortex-M4 vinculado a un FPGA a través de una interfaz de bus de memoria paralela de 16 bits. En esencia, la FPGA se comporta como una memoria externa asignada al espacio de memoria de la MCU: la MCU presenta una dirección seguida de una palabra de datos (escritura) o la lectura de la palabra presentada por la FPGA (lectura).
Quiero proteger tanto la lectura como la escritura contra errores de transmisión durante el direccionamiento y la escritura/lectura de datos. Sin embargo, no espero muchos errores de bits ya que la distancia entre ambas partes es corta.
Puedo implementar fácilmente la verificación y generación de códigos de paridad, hamming o CRC dentro de la FPGA. Sin embargo, hacer lo mismo (verificar y generar) en uC parece comparativamente más difícil ya que no quiero paralizar el rendimiento. Sin detección de errores, la lectura y escritura de palabras de 16 bits requiere alrededor de 4 a 6 ciclos de procesador y, por lo tanto, es bastante rápida. En consecuencia, no quiero gastar cientos de ciclos en medidas de protección.
Al final estoy buscando un método de detección de errores moderadamente eficiente para datos de 16 bits que se implemente en un uC en la menor cantidad de ciclos posible.
He publicado lo mismo en Stackoverflow . Si sabe cómo vincular correctamente las dos preguntas, hágamelo saber.
Si su tasa de errores de bit es medible pero no tan alta como para que no ayude ningún nivel de lógica de corrección de errores, debe reducir su tasa de comunicaciones en un 1% más o menos, o usar los "mejores" 16 bits de su bus y no molestar a los demás.
La lógica de corrección de errores solo es útil en los casos en que la probabilidad de un error es relativamente baja y la probabilidad de que ocurran dos errores está muy por debajo de la probabilidad de uno, la probabilidad de que ocurran tres errores está muy por debajo de eso, etc. Para una conexión entre un CPU y un FPGA, ya sea que cumpla con las restricciones de tiempo, en las que las causas más probables de errores serán cosas como fallas en la fuente de alimentación (que deberían abordarse mejor mediante mejoras en la fuente de alimentación), perderá significativamente las restricciones de tiempo (en cuyo caso, al menos algunos bits del bus generarán datos incorrectos de manera rutinaria), o estará justo al borde de cumplir con las restricciones de tiempo (en cuyo caso, aumentar los márgenes de tiempo aunque sea un poco puede ayudar enormemente).
Si le preocupaba proteger un cable de datos paralelos que iba entre placas, entonces los datos primarios a proteger probablemente serían los de una comunicación interrumpida (por ejemplo, una que ocurría mientras se desconectaba un conector) que se percibía como legítima. A menos que se requieran transacciones de respuesta muy corta (como podría ser el caso aquí), la mejor manera de protegerse de tales cosas es realizando un CRC u otro código de validación en todas las palabras de una transmisión más larga. Agregar un CRC de dos palabras (32 bits) a una transmisión de 64 palabras generaría menos sobrecarga que agregar un bit de paridad a cada palabra, pero sería mucho más probable que detectara errores de transmisión.
mercado
arne