Journal_alpha

------------------------------------------------------------------------------------------
Explication du banc de register:

    la lecture n'est pas synchroniser avec l'horloge

    > 2 PORT pour ecrire:
        - 1 port pour la destination toutes les instructions qui detiennent
            des destinations. (exe_res, exe_dest, exe_wb)
    
        - 1 port pour certains instructions qui ecrivent dans un registre 
            autre que la destination exemple:  Branch and link (R14<=PC);
            Swap (Rn <= Rm)
            Destiner normalement pour mem, mais c'est possible de l'utiliser
            dans l'exec si necessaire. (mem_res, mem_dest, mem_wb).
            Utile pour mettre le calcul d'adresse avant de notifier a MEM

    > 3 PORT pour lire 
        Le 1er port est prioritaire devant le 2eme
        - 1 port pour op1 => Rn registre 
        - 1 port pour op2 => Rm registre 
        - 1 port otre     => Rs registre
        + certaines instructions demandent jusqu'a 3 lecture de donnes. par 
        exemple: mult_t; swap_t;

    > Important: Dans l'incrementation du pc tenir compte de quand on 
        veut incrementer le pc et ecrite dans le pc
        donc pc <= val + 4 



--------------------------------------------------------------------------------
Explication de DECOD:
    
    > decod interface operands 
        - "op1" & "op2" : Consiste a decoder les operandes.
        - "alu_dest" :Trouver le registre de destination.
        - "alu_wb" : mettre a jour les registres de destination ? (0 ou 1)
        - "flag_wb" : mettre a jour les flags (0 ou 1)

    > reg read (utilisation des port de lectures)
        - "radr1" : adresse a renseigner au port 1, pour les data de "op1" (rdata1)
        - "radr2" : adresse a renseigner au port 2, pour les data de "op2" (rdata2)
        - "radr1" : adresse a renseigner au port 3, pour certaines inst speciales

    > reg Invalid (les register a invalider pour pouvoir ecrire la decu)
        - "inval_exe_adr" : le register destination a invalider
        - "inval_exe" : pour valeur "1", invalide "inval_exe_adr" sinon "0"
        - "inval_mem_adr" : pour une seconde dest, utilser pour les transfert mem 
        - "inval_mem" : "1" invalide "inval_mem_adr" sinon "0"
        - "inval_czn" : conserne les flags c & z & n, "1" invalide sinon "0"
        - "inval_ovr" : invlider l'overflow v, "1" invalide sinon "0"
        --- Remarque:

    > operand validite:
        "operv" : pour savoir si l'Execution peu commencer, se bansant sur rvalid{1,2,3}
                comme le resultat de op1 et op2 par exemple est une lecture sur des registres
                on ne peut lire que quand le registre est valide c-a-d, s'il est invalide il est 
                probablement en cours d'ecriture ou attente d'ecriture.

    > decod to mem interface

    > Shifter command:

    > Alu operand selection 

    > Alu command
    
    > Mtrans reg list
        - "mtrans_mask_shift": pour permetre une mis-a-jour du mtrans_mask a chaque etape, 
            c-a-d que les precedents sont mis a 0. mtrans_mask <= mtrans_mask & mtrans_mask_shift
        - "mtrans_mask": le mask sur les registers a traiter a tout instant
        - "mtrans_nbr": le nombre de registre que reste a etre traiter
        - "mtrans_list": la liste des registre qui reste a traiter
        - "mtrans_rd": prochain register a traiter, le registre de dest ou source
        - "mtrans_1un": quand le multi-transfert n'a qu'un seule registr a traiter

    + Il ya un cycle qui separe MEM et DECOD, ce qui reste interessant.

------------------------------------------------------------------------------------------------
Explication de Exec:
    > ALU 
        - commandes(dec_alu_cmd):
             00 => add | 01 => and | 10 => or | 11 => xor

    > SHIFTER 
        - Rm qui correspond a l'op2 qui est shifter


---------------------------------------------------------------------------------------------------------
Explication sur la machine a etat du DECOD
    Dans le decode il faut satisfaire les instructions selon leur cycle:
        - regop_t   : 1 cycle
        - mult_t    : 1 cycle + m cycle interne
        - branch_t  : 2 cycle
        - mtrans_t  : 15 cycle
        - trans_t   : 1 cycle


    > FETCH: apres demarage Decod envoi une valeur vers Ifetch
        - reste quand la fifo vers Ifetch est pleine
        - quitte vers RUN une valeur PC ecrite dans 
            dec2if (inc_pc <= dec2if_push)

    > RUN: traitements des instructions
        - reste:  "if2dec" vide, "dec2exe" pleine ou predicat invalid, une 
            new valeur PC envoyer vers Ifetch si dec2if n'est pas pleine
        - reste aussi: le predicat est faux, instruction a rejeter
        - reste aussi: le predicat est vrai, instruction a executer
        - quitte: l'instruction est un appel de fonction (vers LINK)
        - quitte: l'instruction est un branchement (vers BRANCH)
            il faut que 
        - quitte: l'instruction est un transfert multiple (vers MTRANS)

    > LINK:
        pris systematiquement: calcul de la nouvelle valeur PC par EXEC 
        (puis vers BRANCH).
        Il faut Remarquer dans le decode d'une instruction le PC est deja a PC+8, a cause
        du prefetch, c-a-d que quand decode deja a PC+8, la fifo if2dec contient PC et
        l'inst PC+4 est entrain d'etre recuperer par IFetch.

    > BRANCH:
        - reste: if2dec est vide
        - quitte: if2dec n'est pas vide(vers RUN)
        + c'est-a-dire, il reste coincer dans jusqu'a ce que le PC soit valide
        
    > MTRANS: 
        - reste: desqu'il reste au moins une donnee a transferer
        - quitte: plus rien a transferer(vers RUN)

    Remarque: 
            - predicat faux: il arrive que les conditions de l'instruction 
                sont faux donc on passe a la suivante sans execution
            - predicat invalid: il arrive que certains registers ne sont pas toute suite 
                disponible exemple un cas de dependance, donc on est obliger d'attendre
                c-a-d rester sur l'etat RUN jusqu'a la disponibilites des registers.
            - predicat vrai: toutes les conditions sont valide, donc executer l'instruction 
                c-a-d envoyer sur EXEC

---------------------------------------------------------------------------------------------------------
Descriptions de instructions
    > traitements de donnees:
        - regop

    > Swap:
        - pas valeur immediat
        <SWP>{cond}{B} Rd,Rm,[Rn] , B = 1 => load byte, B = 0 => load word 
        - swap_t: 
            Rd <= [Rn]
            Rn <= Rm

    > Mutiplication:
        - pas de valeur immediat
        Rd <= Rm * Rs + Rn si A=1 sinon Rd <= Rm * Rs 
        - mla_i: op1 <= Rm; op2 <= Rs; 
            dec_mem_data <=  Rn (puisqu'il est accessible par exec)
        - mul_i: op1 <= Rm; op2 <= Rs;
        - c'est possible de comfondre mla_i & mul_i avec Rn=0 pour mul_i 

        - la multiplication est un process dans DECOD:
            + pour l'instant la seule solution avec ce modele d'architecture
                c-a-d en utilisant l'ALU et le SHIFTER dans EXEC
                on est obliger de faire 32 cycles max. 
            + pour l'ameliorer on est obliger de rajouter un shifter dans
                DECOD pour pouvoir eviter les cycles de se cote,
                pour utiliser l'algo de booth's (https://www.youtube.com/watch?v=QFXaddi-Ag8) 
                par exemple ou autre. 


    > transferts de donnees:
        - trans:
            les complement peuvent etre utilise "comp_op{1,2}"
            avec les pre_index = 0, on prend l'op1 = Rn

            Load: 
            Store:

    > multi transferts de donnees:
        - mtrans:
            Load:
            Store:

------------------------------------------------------------------------
Comment ecrire des Test compiler
    > Le TME3 vlsi umpc est peut etre comme reference
    > (Voir Main/main_tb)
        Dans programme qu'il faut tester sur le processor
        pour savoir s'il a reussi le test ou pas il doit avoir
        des branchement _good et _bad, il doit se mettre sur
        un des branchement pour que le simulateur s'arrete
        les 2 branchment sont connu apres le chargement
        voir(C_model/src/mem.c).
    > On peut compiler un programme en C et le linker avec "sections.lds"

--------------------------
A retenir

    + On fait un pop quand on termine un traitement.
    + quand une instruction est decoder elle commence a s'excuter au 
        prochain cycle.
    + lors d'un traiement candencer avec une horloge, visualiser 
        a l'instant le traiement.
    + IMPORTANT: les dependance Write after Read doivent etre pris en compte
        pour la validite de l'operation



       >  LA FIFO A COrriger