Desarrollo de hardware en FPGA con chip de controlador de LED

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

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

YesteesunextractodelarchivoderestriccionesdeXilinx:

(eltuyopuedeparecerdiferentesiestásusandolasherramientasdeunproveedordiferente)

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 indica a la herramienta de mapas FPGA qué señales se asignan 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 darte 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 usa para especificar varios parámetros sobre los pines físicos. Por ejemplo, los estándares de IO, la terminación y las fortalezas de la unidad pueden especificarse en el archivo de restricciones. Además, aquí es donde se especifican las velocidades de reloj para el análisis de temporización y la asignación de bloques de firmware más grandes, como los transcriptores incorporados.

Si está interactuando con un dispositivo que utiliza un reloj para sincronizar los datos dentro o fuera del 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 en el camino. en, o el dominio del dispositivo en la salida.

En general, si solo está escribiendo un código para anticiparse al hardware, puede escribir un módulo en el que las señales de las entidades de entrada y salida coincidan con las del dispositivo. Cuando llega el hardware, es cuestión de asignar las señales de la entidad al nivel superior, configurar las restricciones para que coincidan con el hardware, y debería estar listo.

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

La interfaz de 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 cómo conectar los puertos de E / S funcionales de su módulo a los pines físicos en el FPGA, y asegurarse de que los controladores y receptores de pines del 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 la cadena de herramientas Lattice lo llame) en su proyecto, y habrá una sección en el manual que trata estos aspectos del diseño de FPGA.