Level 1 / Execute

  • Ich hab ein paar Fragen zu den Signalen vom Level 1 bzw zur Execute-Einheit:


    a) welches datenweitergabe-modell liegt den Stages zu Grunde? Bei jedem Takt übernehme ich die Eingaben der vorherigen Stufe in meine lokalen Register (ausser Stall ist gesetzt): A_in -> A_reg; auf diesen registern werden meine Operationen durchgeführt. Landen die Ergebnisse auf den *_next Signalen und werden erst beim nächsten Takt auf *_out übernommen, oder legt die Stage Ihre ergebnisse sofort an den Ausgang (schließlich hat die nächste Stufe ja auch ein Eingabe-Register, oder?).


    b) Das Signal "Stall": Es verhindert einfach dass bei der nächsten Taktflanke neue Werte von der davorgehenden Stage geladen werden. Es verhindert aber nicht, dass meine aktuellen Ergebnisse aus den *_next Registern auf die Ausgänge der nächsten Stage gelegt werden, oder?


    c) Das Signal "Flush": Wirkt das Synchron oder Asynchron (also wie ein Reset)? werden die aktuellen Ausgänge sofort auf NOPs gesetzt, oder erst beim nächsten Takt?


    d) Wenn op.useimm gesetzt ist, wird einfach op.imm statt readdata2 als zweiter Operator für die ALU genutzt. aber wie ist das bei op.useamt ? Es wurde kein op.shamt übergabefeld definiert. kann ich annehmen, dass shamt dann an readdata1 anliegt?


    e) wenn das op.link flag gesetzt ist, wird zusätzlich zur aktuellen (sprung) operation PC+4 in register 31 abgelegt (als rücksprungadresse). wer setzt das register 31 (als rd, oder?) für die memory-unit? macht das Decode oder macht das Execute aufgrund dieses flags?


    f) was genau ist der unterschied zw aluresult und wrdata? im normalfall (ausser link oder cop0 ist gesetzt) sind beide gleich, oder?


    g) wenn branch gesetzt ist, kopiere ich einfach die untersten PC_WIDTH-bits vom aluresult ins new_pc, oder?

  • ad a) Die Pipelinestufe legt die Ergebnisse sofort an die Ausgänge. Wie du richtig erkannt hast, hat die nächste Stufe ja wieder ein Register am Eingang.


    ad b) Es wird einfach der alte Wert in den Registern behalten, den kombinatorischen Teil der Pipelinestufe betrifft das Stalling nicht. Die nächste Stufe stallt ebenfalls, was an den Ausgängen liegt ist also nebensächlich.


    ad c) Asynchrone Signale außer dem Reset sind imho kein sauberes Design. Abgesehen davon würden aber glaube ich beide Varianten funktionieren, wenn mans nur richtig macht.


    ad d) Du kannst annehmen was du willst, und z.B. das imm-Feld für den shamt verwenden, oder ein neues Feld definieren ("You are free to modify these types to optimize your design."). Dass shamt in readdata1 liegt kann man machen, man muss dann aber beim Forwarding aufpassen.


    ad e) Ich würde es in der Decode-Stage machen, vom Prinzip her könnte man es glaube ich aber auch in der Execute-Stage machen.


    ad f) Meistens sind die beiden Signale gleich, bei den Instruktionen BLTZAL etc. gibt es aber zwangsläufig einen Unterschied.


    ad g) Überleg dir was wo bei der Instruktion BEQ anliegt. Der Vergleich und das Berechnen des Sprungziels wird sich nicht beides in der ALU ausgehen.

    Why bother spending time reading up on things? Everybody's an authority, in a free land.