En los sistemas incrustados, solo tiene registros de solo lectura y de escritura. ¿Cómo se distinguen los dos tipos en el netlist producido?
¿Cómo se construye un flop en el que solo puedes escribir y no leer?
En los sistemas incrustados, solo tiene registros de solo lectura y de escritura. ¿Cómo se distinguen los dos tipos en el netlist producido?
¿Cómo se construye un flop en el que solo puedes escribir y no leer?
Se trata de cómo se conectan los registros al bus:
if wb_cyc = '1' and wb_stb = '1' then -- accessing the register
if wb_we = '1' then -- writing to the register?
my_reg <= wb_dat_i; -- update register contents
else -- reading from the register
wb_dat_o <= my_reg; -- return register contents
end if;
end if;
Si deja de lado la parte del hardware que puede leer el registro, entonces su registro es de solo escritura. Del mismo modo, si omite la parte del hardware que puede escribir en el registro, es de solo lectura.
A veces tiene sentido tener solo una "dirección" del flujo de datos. Piense en un DAC o una ruta de datos ADC.
Además, a veces tiene sentido que la misma dirección devuelva algo distinto a los datos que ha escrito. Piense en los microcontroladores más comunes; sus periféricos tienden a tener una única dirección que es un "comando" para las escrituras y un "estado" para las lecturas.
Otro ejemplo serían los indicadores de interrupción: usted lee el registro de interrupción para ver qué periférico interrumpió el programa, luego escribe un '1' en el mismo bit para borrar el indicador de interrupción. Una forma de darse cuenta de esto es la siguiente:
wb_dat_o <= (others => '0');
if wb_cyc = '1' and wb_stb = '1' then -- register access
if wb_we = '1' then -- writing to the register?
clear_int <= wb_dat_i(0);
else -- reading from the register?
clear_int <= '0';
wb_dat_o <= running & int_enabled & int_active;
end if;
end if;
Aquí puede ver que estoy configurando una marca para lo que esté en la posición de bit 0 en el caso de escritura (y no me importa lo que hayan escrito), mientras que en el caso de lectura que estoy construyendo una palabra de estado formada por bits individuales que el periférico está conduciendo.
aparte: también mantengo explícitamente clear_int en cero en el caso de lectura. Es solo una buena práctica de codificación asegurarse de que todas las señales estén asignadas en todas las rutas de código en HDL. En el mejor de los casos, no hacerlo es un código descuidado. En el peor de los casos puedes inferir pestillos. Tenga en cuenta que hago algo similar con wb_dat_o incluso antes de ingresar al caso de acceso al registro.
Tenga en cuenta que estos son solo ejemplos para ilustrar el punto, y que un programa bien escrito se describirá con mayor detalle y detalle. También tenga en cuenta que son las 8 am aquí y todavía no he tomado mi café. :-)
Supongo que está hablando de registrarse en alguna parte periférica, ya sea parte del chip del procesador o conectado de alguna manera.
En un registro de solo lectura, los datos se originan en algún proceso externo (desde el punto de vista del procesador) y en el hardware asociado, como la recepción de datos en serie por parte de un UART. Por lo tanto, ese hardware se conecta a la entrada de te FF y sus salidas se conectan (por ejemplo) al bus del procesador.
Para un registro de solo escritura, la situación es inversa, el procesador se conecta (directa o indirectamente) a las entradas del FF, y las salidas del FF se conectan a algunos circuitos externos. Un ejemplo es un convertidor de digital a analógico.
Una cosa que sugeriría que intente hacer, aunque lamentablemente muchos diseños no lo hacen de manera coherente, es dividir los registros grabables en las categorías "enclavamiento" y "acción", con la expectativa de que una lectura de un registro enclavado siempre devuelve el valor escrito, mientras que una lectura de la dirección de un registro de acciones debe considerarse como leer un registro de solo lectura independiente.
Por ejemplo, suponga que su sistema tiene ocho cierres que detectan eventos externos. Si esos pestillos se encuentran en un registro de 8 bits que puede ser leído o escrito directamente por la CPU, o que se puede establecer de forma asíncrona externamente, entonces si el código de usuario observa que los bits 0 y 2 están activados (lo que significa que el registro lee 0x05) y desea para borrar el bit 0 mientras se deja el bit 2, tratar de escribir 0x04 en el registro tal como algún evento causaría que se activara algún otro bit tendría el desafortunado efecto de borrar el pestillo asociado con ese otro evento, lo que hace que se pierda . Si, en cambio, uno tenía una dirección de "lectura" que informa el estado de los latches, una dirección de "escritura a cero" que permite borrar los bits seleccionados, y posiblemente una dirección de "escritura unos" que permite establecer los bits seleccionados, entonces estos problemas no ocurriría.
Para las cosas que se supone que la CPU debe controlar (en lugar de simplemente tomar nota de - como fue el caso con las banderas de interrupción), pero donde la capacidad de la CPU para controlarlas puede estar limitada por factores externos, uno debe separarse lo que la CPU está solicitando de lo que es capaz de hacer. Por ejemplo, si se supone que una salida de control del motor se apaga de forma asíncrona con una entrada externa de "apagado del motor", esa entrada no debería simplemente borrar el seguro de salida de "control del motor" que estableció la CPU. En su lugar, la CPU debe tener un pestillo que indique si desea que el motor esté encendido y que el pestillo no debe cambiarse por factores externos. Un segundo pestillo activado externamente debe indicar si ha llegado una señal de apagado del motor; la salida del motor debe activarse solo cuando la solicitud de la CPU dice "ir" y el pestillo de "apagado" no se dispara, lo que permite que la CPU tenga "comandos" separados para "iniciar este dispositivo que previamente había solicitado que estuviera apagado, suponiendo que no exista ninguna falla ", y" reconocer / borrar la condición de falla ".
Diseñar hardware para separar lo que la computadora está solicitando en comparación con lo que actualmente se le permite hacer al hardware externo no debería ser difícil, y mantener estas cosas separadas como una cuestión de principio ayudará a evitar errores que pueden ocurrir cuando la CPU --en el proceso de intentar escribir una cosa - accidentalmente escribe otra cosa.