Desarrollo de hardware en FPGA con LED Driver Chip

Durante el proceso de creación del firmware, la etapa de mapa asigna las señales de nivel superior de su firmware a los pines físicos de la FPGA. Esta asignación casi siempre se realiza manualmente al incluir asignaciones de pines en un archivo llamado archivo de restricciones (por el conjunto de herramientas xilinx, al menos). Si no se encuentran restricciones, la herramienta de construcción asignará los pines.

Esencialmente, todas las señales de su módulo de nivel superior terminan siendo pines físicos. Aquí hay un ejemplo de un tablero que estoy diseñando en este momento:

Y este es un extracto del archivo de restricciones de Xilinx:

(el suyo puede verse diferente si está utilizando las herramientas de un proveedor diferente)

NET "DEBUG_CONN_1" LOC = "M7";
NET "DEBUG_CONN_2" LOC = "M8";
NET "DEBUG_CONN_3" LOC = "R4";
NET "DEBUG_CONN_4" LOC = "P4";
NET "DEBUG_CONN_5" LOC = "M6";
NET "DEBUG_CONN_6" LOC = "L6";
NET "DEBUG_CONN_7" LOC = "P3";
NET "DEBUG_CONN_8" LOC = "N4";
NET "DEBUG_CONN_OE" LOC = "M5";

Esto le dice a la herramienta de mapa FPGA qué señales asignar a qué pin.

Y finalmente, un extracto de la entidad de nivel superior:

(esto es VHDL porque eso es lo que uso, pero debería darle la idea correcta)

ENTITY 6slx45fgg484 is
    PORT (
        DEBUG_CONN_1    : OUT STD_LOGIC;
        DEBUG_CONN_2    : OUT STD_LOGIC;
        DEBUG_CONN_3    : OUT STD_LOGIC;
        DEBUG_CONN_4    : OUT STD_LOGIC;
        DEBUG_CONN_5    : OUT STD_LOGIC;
        DEBUG_CONN_6    : OUT STD_LOGIC;
        DEBUG_CONN_7    : OUT STD_LOGIC;
        DEBUG_CONN_8    : OUT STD_LOGIC;
        DEBUG_CONN_OE   : OUT STD_LOGIC;
        .
        .
        .
        );
END 6slx45fgg484;

El archivo de restricciones se utiliza para especificar varios parámetros sobre los pines físicos. Por ejemplo, los estándares de E/S, la terminación y la fuerza de la unidad pueden especificarse en el archivo de restricciones. Además, aquí es donde especifica las velocidades de reloj para el análisis de tiempo y el mapeo de bloques de firmware más grandes, como transceptores incorporados.

Si está interactuando con un dispositivo que usa un reloj para registrar datos dentro o fuera de la FPGA, es posible que deba cambiar los dominios de reloj o registrar tres veces sus señales para convertir las señales en su dominio de trabajo al ingresar, o el dominio del dispositivo a la salida.

En general, si solo está escribiendo código para adelantarse al hardware, puede escribir un módulo donde las señales de entidad de entrada y salida coincidan con las del dispositivo. Cuando llega el hardware, se trata de mapear las señales de su entidad hasta el nivel superior, configurar las restricciones para que coincidan con el hardware, y debería estar listo para comenzar.

Supongo que en sus proyectos anteriores de FPGA, los módulos que estaba escribiendo interactuaban con otros módulos dentro del mismo FPGA. Como tal, tenía que prestar atención a las relaciones de temporización entre las diversas señales de la interfaz.

Interconectar un FPGA a uno o más chips externos, desde un punto de vista funcional, no es diferente. Debe comprender las relaciones de tiempo requeridas y escribir su código para cumplirlas.

La única diferencia real es aprender a conectar los puertos de E/S funcionales de su módulo a los pines físicos de la FPGA y asegurarse de que los controladores y receptores de pines de la FPGA estén configurados correctamente para que coincidan con las características eléctricas de los chips externos. Esta es una de las funciones del "archivo de restricciones" (como sea que lo llame la cadena de herramientas de Lattice) en su proyecto, y habrá una sección en el manual que trata estos aspectos del diseño de FPGA.