Javipipi
commented
4 weeks ago Hola @mpuntous, El rom_dataout, como se indica en el diagrama del enunciado, viene de la ROM, y corresponde a una línea de 36 bits de largo, el excel no está de ninguna forma conectado al código de Vivado, este es una ayuda para ustedes para que puedan manejar las señales y formar su propio opcode. El flujo del código dado un archivo .txt de instrucciones vendría siendo así:
- Su assembler lee el .txt y lo transforma a binario siguiendo el formato de 16 bits de literal y 20 bits de opcode (que ustedes definieron).
- Su assembler le carga este array a la ROM y se sobreescriben las líneas de esta.
- De la ROM sale una línea, una a una, a la CPU, dentro de la CPU, 16 bits de literal van al MuxB y al Program Counter, y 20 de opcode a la Control Unit.
- Su Control Unit maneja los 20 bits de opcode y pasa las señales necesarias a cada componente que lo requiera para correr la instrucción indicada en la línea de la ROM, entonces si la instrucción fuera
MOV A, 5, tu MuxA debería escoger el registro A, tu MuxB debería escoger el literal y la ALU debería hacer la operación de MOV. - Finalmente, el display debería mostrar el resultado de la operación, siguiendo el ejemplo anterior, tu display debería mostrar 0500.
Ustedes en VIvado deben poder manejar esas señales dada una instrucción. Con respecto al loadPC, esta es una señal que indica que debe hacerse un salto a otra instrucción, sin embargo, cuando se lee un salto condicional (ej: jump carry), este solo debe ejecutarse si las flags lo permiten, estas flags deben pasar de la ALU al registro Status a la Control Unit.
mpuntous
El rom_dataout que va a la control_unit de que consiste? los 20 bits que salen de ahí son los del excel de señales? pero no encajan con la cantidad, los demas como funcionan? el opcode como se debe usar en la control_unit? y el loadPC viene ya como señal o se determina con las flags?